Empower engineers with a default pipeline of nginx RED metrics to Datadog from your cluster.
We like k8s and we use nginx a lot, we'll likely use it even more as a part of Cloud Endpoints.
This container offers default log parser that will take typical nginx log stats and turn them into dogstats.
It matches the following nginx log format, which should be included in a modified cloud endpoint container when I publish it.
log_format timed_combined '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'$request_time $upstream_response_time $pipe';
Pipe is not yet implemented.
Each metric will be annotated with a set of tags including both kubernetes metadata as well as request information.
Below is a table of collected metrics and tags
The majority of metrics below are collected from nginx log module provided information
| Name | Description |
|---|---|
| nginx.request_time.{avg,count,max,median} | statistics about request processing time in seconds with a milliseconds resolution; time elapsed between the first bytes were read from the client and the log write after the last bytes were sent to the client |
| nginx.server_zone.responses.2xx | number of 2xx HTTP response code responses |
| nginx.server_zone.responses.3xx | number of 3xx HTTP response code responses |
| nginx.server_zone.responses.4xx | number of 4xx HTTP response code responses |
| nginx.server_zone.responses.5xx | number of 5xx HTTP response code responses |
| nginx.upstream_response_time.{avg,count,max,median, 95percentile} | statistics about time spent on receiving the response from the upstream server; the time is kept in seconds with millisecond resolution. You may find this a better measure of your proxied application's latency performance. nginx.request_time will also include client request time. As a result, slow clients will add latency not attributed to your proxied application |
Tags can be used to group metrics on order to drill down to the source of a metric
| Name | Description |
|---|---|
| status_code | precise HTTP response code |
| path | the HTTP request path. see path_aliases notes below |
| namespace | kubernetes provided namespace |
| kube_namespace | (same as above) |
| container_name | kubernetes provided container name |
| pod_name | kubernetes provided container name in {namespace}/{pod-name} format |
| kube_* | labels provided by kubernetes will be provided as tags of the form kube_{label-name} with the kubernetes label value as the tag value |
| gce_zone | if hosted in gce, the name of the zone the application is hosted in |
| aws_region | if hosted in aws, the anem of the region the application is hosted in |
| cloud_provider | either gcp or aws |
Many applications expose endpoints with paths containing dynamic segments representing resource identifiers. You
may find it useful to collapse these into an single alias to reduce metric path tag cardinality.
You can do so by volume mounting a yaml configuration file
$ docker run -v $PWD/nginx_dogstats.yaml:/opt/nginx_dogstats.yaml ...
This file expects a key named path_aliases which binds to a list of path
patterns and alias names. Below is an example
path_aliases:
- "^/cupcakes/.+$" : "/cupcakes/{id}"
Given the above a request with a path /cupcakes/123 would yield a path tag of /cupcakes/{id}
There's a component test on the artifact. Simply, it spins up a mock-statsd server to record what we attempt to send it then validates the results against an existing expected output.
This project isn't meant to deploy, only publish, but we have included some examples of how you could deploy it.