Add metrics to count requests buffered to temporary file

[frittentheke]

Currently NGINX logs a warning for requests that are bigger than the configured client in-memory buffer (https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/#client-body-buffer-size):

[warn] 128#128: *5837 a client request body is buffered to a temporary file /tmp/nginx/client-body/0000000097, client: 10.xx.xx.xx, server: xxxx, request: "POST /api/v1/endpoint HTTP/2.0", host: "xxx", referrer: "h [...]

While logging this per request is already really helpful to find potential optimizations, having these events counted as a Prometheus metric would be even more helpful, as this is usually used by users and allows for correlation (e.g. buffered vs. non-buffered requests, ...).

[k8s-ci-robot]

This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[longwuyuan]

There are no resources like developer time available to add new features. Apologies for that. The reasons have been announced and available for listening on the recorded community meetings posted to youtube.

On a different note, if there is optional enabling of such a feature, we could consider a PR. But the real problem here is that you make no comments on the problems it will create. There will be too much data. In technical terms I saw someone use the words like "cardinality explosion", to refer to such situations.

[github-actions]

This is stale, but we won't close it automatically, just bare in mind the maintainers may be busy with other tasks and will reach your issue ASAP. If you have any question or request to prioritize this, please reach #ingress-nginx-dev on Kubernetes Slack.

[frittentheke]

On a different note, if there is optional enabling of such a feature, we could consider a PR. But the real problem here is that you make no comments on the problems it will create. There will be too much data. In technical terms I saw someone use the words like "cardinality explosion", to refer to such situations.

@longwuyuan cardinality simply depends on the granularity of the metric. So if you want it by NGINX instance, by Ingress or even split by more features. I was simply asking to have this as a global metric to make it easier to notice the need to look into the access logs for large requests and to make adjustments accordingly.

[github-actions]

This is stale, but we won't close it automatically, just bare in mind the maintainers may be busy with other tasks and will reach your issue ASAP. If you have any question or request to prioritize this, please reach #ingress-nginx-dev on Kubernetes Slack.