Features Diagnostics & Metrics - mekomidev/yagura GitHub Wiki
This feature is currently work-in-progress and is not yet available. Any APIs described here are not final
When starting the application with the environment variable YAGURA_OUTPUT_METRICS=true
, it will output all of the measured metrics in realtime to stdout
in JSON format.
If the application does any logging (either through a Logger
service or the JS console
class) it will be encapsulated in a JSON object too.
The output metric data includes:
- Per-event metrics
- Size in bytes
- Processing time
- Per-layer metrics (per second)
- Event count
- Events processed/forwarded/rejected
- Bytes in/out
- App metrics (per second)
- Event count
- Events processed/forwarded/rejected
- Bytes in/out
- Event loop delay
- Event loop utilization
- Heap size
- Logs
- Timestamp
- Log level
- Message content
Even more metrics can be provided by aggregating them via tools such as Prometheus or yagura-cli
(WIP).
Metric objects
TBD
Kubernetes support
By specifying the environment variable YAGURA_EXPOSE_PROBES=true
, the application will start an HTTP server on port 31044
(unless specified differently via the YAGURA_PROBE_PORT
variable).
The server will respond to requests on the following paths:
/live
This route will always just return HTTP status 200
. If it doesn't, it means that the app is either down (thus acting as a simple healthcheck) or the event loop is too packed to respond before the request times out.
/ready
This route checks whether the event loop delay is smaller than the readiness threshold (defaults to 2000
milliseconds) and if so, returns HTTP status 200
, otherwise returning HTTP status 503
.
An alternative readiness threshold can be defined via the YAGURA_READY_THRESHOLD
environment variable.
Note: it is generally good practice for a HTTP service to automatically return a 503 code whenever it is under too much pressure. Consider using readiness-checking middleware in the topmost layer of your scaffold.
Prometheus support
TBD