In terms of endpoint location I was thinking of just extending: https://orchestrator.example.com/debug/metrics. An explicit API endpoint also works.

I tend to think in MySQL terms. So the 2 a / b look good.

I think additionally it’s useful to also record the latency of each call and sum it over time. Similar to MySQL’s P_S.<some_table>.SUM_TIMER_WAIT.

This can then be plotted and you can generate the delta over time and this helps give an idea of whether all calls (as you can collect the counters over time in a similar way) latency changes over time. Right now we have no insight into orchestrator load. We call the API quite frequently as orchestrator is integrated into our tooling so being able to see metrics on the different api endpoints and their behaviour over time would be useful.

I’d see this as: endpoint / response code / { count, latency, success/ failure indicator }

Hi ,

If I understand correctly, what is requested is:

1. add a new endpoint that provides metrics in form of JSON

2. needed metrics are:

   1. array of httpresponse codes

      1. httresponse code : count

   2. array of all endpoints

      1. endpointN : success count

      2. endpointN: failures count

I’m not sure about total latency gauge and max latency value. Do you mean two global metrics or two per endpoint?

Additionally, how to calculate total latency gauge? Average of all previous requests, average of N previous requests?

Hi

Thank you for the report and feedback.

I guess endpoint code is at:

• web:

• http:

Ideally this can be handled by wrapping the endpoint registration in something that can collect these metrics.

Also adding a total latency gauge would be useful as would a max_latency value.