Skip to content
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

Metrics related to Http status code #1146

Open
Wonshtrum opened this issue Oct 25, 2024 · 0 comments
Open

Metrics related to Http status code #1146

Wonshtrum opened this issue Oct 25, 2024 · 0 comments

Comments

@Wonshtrum
Copy link
Member

We currently have (on Sozu 1.0.5) two "kind" of metrics on http status codes:

  • http.301.redirection, http.400.errors, http.401.errors and alike
  • http.status.1xx, http.status.2xx and alike
    The first category is only incremented for automatic responses generated by Sozu. The second is incremented for every response, generated or forwarded from a backend. This explains why the former uses explicit error numbers and the latter, aggregated ones.

The naming is not really explicit, so may we change it? Maybe http.generated.301 and http.total.1xx?
Additionally, independently of their origin, some of those metrics are stored:

  • per backend, like http.502.errors and http.status.2xx
  • per cluster, like http.503.errors and http.status.5xx
  • per worker, like http.400.errors and http.status.3xx

We can't store all of them with "backend precision", as some errors are generated prior to this knowledge (400 are typically generated before the cluster is known). Should we aggregate the "more precise" status codes on clusters and workers? To have quick access to how many 2xx responses were served for example (currently we have to look into each backend). Should it be done with more metrics directly? or with an option of the metrics get command? If we choose the former should they be named differently? If the latter, should we specify the exact name of the metric to aggregate, a pattern, or does it aggregate all metrics that can be aggregated?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant