You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat/metrics : add new metrics for measuring skipper latency (#3506)
This change involves adding a new metric to measure the overall skipper
latency of a request. i.e., the time taken by a request in skipper
itself, so this does not include time taken for serving for the response
to client and the time taken for the backend round trip.
skipper latency = serve duration - response duration - backend duration
---------
Signed-off-by: speruri <surya.srikar.peruri@zalando.de>
Co-authored-by: speruri <surya.srikar.peruri@zalando.de>
flag.BoolVar(&cfg.ServeMethodMetric, "serve-method-metric", true, "enables the HTTP method as a domain of the total serve time metric. It affects both route and host split metrics")
410
412
flag.BoolVar(&cfg.ServeStatusCodeMetric, "serve-status-code-metric", true, "enables the HTTP response status code as a domain of the total serve time metric. It affects both route and host split metrics")
411
413
flag.BoolVar(&cfg.BackendHostMetrics, "backend-host-metrics", false, "enables reporting total serve time metrics for each backend")
414
+
flag.BoolVar(&cfg.ProxyRequestMetrics, "proxy-request-metrics", false, "enables reporting latency / time spent in handling the request part of the proxy operation i.e., the duration from entry till before the backend round trip")
415
+
flag.BoolVar(&cfg.ProxyResponseMetrics, "proxy-response-metrics", false, "enables reporting latency / time spent in handling the reponse part of the proxy operation i.e., the duration from after the backend round trip till the response is served")
412
416
flag.BoolVar(&cfg.AllFiltersMetrics, "all-filters-metrics", false, "enables reporting combined filter metrics for each route")
413
417
flag.BoolVar(&cfg.CombinedResponseMetrics, "combined-response-metrics", false, "enables reporting combined response time metrics")
414
418
flag.BoolVar(&cfg.RouteResponseMetrics, "route-response-metrics", false, "enables reporting response time metrics for each route")
@@ -225,6 +226,85 @@ To monitor skipper we recommend the following queries:
225
226
226
227
You may add static metrics labels like `version` using Prometheus [relabeling feature](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config).
227
228
229
+
### Proxy Metrics
230
+
231
+
Skipper Proxy Metrics provides information about the time spent by skipper in processing a request i.e., the time spent by a request inside skipper (this excludes the response application of filters to a req/res, the backend roundtrip and serving the response). The total proxy metrics are enabled by default and these metrics can be used to build KPIs / SLOs, so as to understand and monitor the performance of skipper.
232
+
233
+
The Proxy Metrics exludes the filter processing as this is dependent on which filters the user decides to use for a particular route. The backend round trip time depends on the backend application and the operation being performed. And the serve response depends on the client. These are operations are not in control of skipper and are hence excluded to solely monitor the performance of Skipper.
234
+
235
+
These metrics are exposed in /metrics, the example json structure looks like this:
236
+
237
+
```json
238
+
{
239
+
"timers" : {
240
+
"skipper.proxy.total": {
241
+
"15m.rate": 0.2,
242
+
"1m.rate": 0.2,
243
+
"5m.rate": 0.2,
244
+
"75%": 288375,
245
+
"95%": 288375,
246
+
"99%": 288375,
247
+
"99.9%": 288375,
248
+
"count": 1,
249
+
"max": 288375,
250
+
"mean": 288375,
251
+
"mean.rate": 0.7268368234069077,
252
+
"median": 288375,
253
+
"min": 288375,
254
+
"stddev": 0
255
+
},
256
+
}
257
+
}
258
+
```
259
+
260
+
The proxy metrics can also be fetched in more detail, i.e., splits the proxy total metrics to get the proxy request metrics and proxy response metrics. The Proxy Request Metrics provides the duration / time taken from the start of ServeHTTP till the backend round trip. The Proxy Response Metrics provides the duration / time taken from after the backend round trip till the response is served.
261
+
262
+
-proxy-request-metrics
263
+
enbales the collection proxy request metrics
264
+
-proxy-response-metrics
265
+
enables the collection proxy response metrics
266
+
267
+
If enabled these metrics are also exposed in /metrics, and the example json structure would like the following:
268
+
269
+
```json
270
+
{
271
+
"timers": {
272
+
"skipper.proxy.request": {
273
+
"15m.rate": 0.2,
274
+
"1m.rate": 0.2,
275
+
"5m.rate": 0.2,
276
+
"75%": 0,
277
+
"95%": 0,
278
+
"99%": 0,
279
+
"99.9%": 0,
280
+
"count": 1,
281
+
"max": 0,
282
+
"mean": 0,
283
+
"mean.rate": 0.7268396413261223,
284
+
"median": 0,
285
+
"min": 0,
286
+
"stddev": 0
287
+
},
288
+
"skipper.proxy.response": {
289
+
"15m.rate": 0.2,
290
+
"1m.rate": 0.2,
291
+
"5m.rate": 0.2,
292
+
"75%": 288375,
293
+
"95%": 288375,
294
+
"99%": 288375,
295
+
"99.9%": 288375,
296
+
"count": 1,
297
+
"max": 288375,
298
+
"mean": 288375,
299
+
"mean.rate": 0.7268397290232465,
300
+
"median": 288375,
301
+
"min": 288375,
302
+
"stddev": 0
303
+
},
304
+
}
305
+
}
306
+
```
307
+
228
308
### Connection metrics
229
309
230
310
This option will enable known loadbalancer connections metrics, like
0 commit comments