-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simple "Error 13" message improvement #666
Changes from all commits
8ea442d
5ac755a
b8c25a5
1c19c68
7050686
0776563
16fd8f6
c383010
6e1a483
4ef1140
4111bf4
871a959
1fd77c1
edc36b2
4d0364e
aed6d94
d9ae87d
a05a6f5
8cd4d21
d814a96
5f5a885
7e20a78
9048267
306c0ec
d33f543
442cca9
677b783
cefb366
f3684df
5463051
46e0e25
f634642
3c39faa
b9c8f2b
5fc4db4
64e7852
12807f1
e8e960f
6306b4e
1ece783
70705e9
e576bc1
1fca528
ed32856
eecf00d
13179fb
3eb89e6
fae60ad
9fec200
9d1cf53
cfad844
bdde910
8100376
694fda6
1df6137
2b9e1e8
a6da150
4b8ba84
eaa20de
aedd520
4ec202a
f42c374
be5c0fa
7da182a
d3e5545
2f44065
190a691
74de764
c2baebd
da83218
e78adac
f79c078
7e6a810
8f163b4
39a68ad
a27dfbb
3a171ee
5520728
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -42,7 +42,18 @@ void ServiceImpl::handleExecutionRequest(const nighthawk::client::ExecutionReque | |
response.mutable_error_detail()->set_code(grpc::StatusCode::INTERNAL); | ||
// TODO(https://github.com/envoyproxy/nighthawk/issues/181): wire through error descriptions, so | ||
// we can do better here. | ||
response.mutable_error_detail()->set_message("Unknown failure"); | ||
response.mutable_error_detail()->set_message( | ||
"Unknown failure. See Nighthawk Service logs. Make sure the URI is well formed and the DNS " | ||
"name resolves (if applicable). Check the output for problematic counter values. The " | ||
"default Nighthawk failure predicates report failure if (1) Nighthawk could not connect to " | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I know there was a lot of churn in this investigation, so please feel free to push back. Were we unable to identify where the predicates are resulting in failures? This feels like it'd be much better if we could instead log at the point of a predicate failing what predicate was failing and what its value was set to. Is that not possible? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Termination predicates are based on counters which don't seem to store their own names. See termination_predicate_impl.h. We could log the first time each counter was incremented in benchmark_client_impl.cc, without knowing whether it will trigger a failure predicate. Logging in either place could impact performance unless we add logic to bypass logging on subsequent times. The user would have to check the log for the detailed info since it would take more code to propagate the information to the point where we return from the service. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There is There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. agree that we can go forward without fixing this in this PR. Creating an issue for improving termination predicates (with logging or something) sounds like a good idea to me. |
||
"the target (see 'benchmark.pool_connection_failure' counter; check the address and port " | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Regardless of whether or not we make the above change, can we create a TODO/issue a bug for moving this to a documentation location for common trouble areas (similar to our internal playbooks)? This whole log feels like it really belongs in a markdown document rather than in a log statement. (Afterwards, we can instead recommend that people reference our troubleshooting document, instead of including everything in this log statement) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Opened #668. |
||
"number, and try explicitly setting --address-family v4 or v6, especially when using DNS; " | ||
"instead of localhost try 127.0.0.1 or ::1 explicitly), (2) the protocol was not supported " | ||
"by the target (see 'benchmark.stream_resets' counter; check http/https in the URI, --h2), " | ||
"(3) the target returned a 4xx or 5xx HTTP response code (see 'benchmark.http_4xx' and " | ||
"'benchmark.http_5xx' counters; check the URI path and the server config), or (4) a custom " | ||
"gRPC RequestSource failed. To relax expectations, set explicit failure predicates in the " | ||
"benchmark request."); | ||
} | ||
*(response.mutable_output()) = output_collector.toProto(); | ||
process.shutdown(); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(optional) How do you feel about splitting this into two log statements - one error log "Terminated early because of a failure predicate" and a second log (info/debug/verbose/something) with all of these extra details?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.