search

envoyproxy / nighthawk

L7 (HTTP/HTTPS/HTTP2/HTTP3) performance characterization tool
Apache License 2.0
361 stars 81 forks source link

Improve logging #242

Open oschaaf opened 4 years ago

oschaaf commented 4 years ago

Warnings and errors emitted via ‘ENVOY_LOG’ calls will be written to stderr; however that doesn’t serve gRPC clients well. For those, perhaps a separate log stream over gRPC could be useful to forward what now is written to stderr.

mum4k commented 4 years ago

Instead of forwarding the logs across the gRPC boundary, we should review the cases where ENVOY_LOG is used and ensure that users have enough data to debug executions and that all warnings are just warnings, not hard errors.

High level rules:

  1. review existing use cases of ENVOY_LOG and ensure that execution terminates on all hard errors and the error message is forwarded across the gRPC channel itself.
  2. introduce a unique identifier to each execution that will be included in all logged messages.
  3. investigate options for logging into files, currently the logs from the server go to stderr only and thus could perish. How is this done in other projects? How can users access and analyze the logs when running Nighthawk in various cloud deployments?
  4. analyze existing WARNING logs, map the more important ones to meaningful error counters that do get reported after each execution. Define a failure predicate for the run that will fail the run on too many of these. This trigger the end user to start a debugging effort and will keep them informed.