From d171e049bfbeb917022deff115bd4dc8dc80d385 Mon Sep 17 00:00:00 2001 From: Lucas Thiesen Date: Tue, 23 May 2023 15:55:20 +0200 Subject: [PATCH] Update documentation with new metric name Signed-off-by: Lucas Thiesen --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 3cbd4b17..741ff33c 100644 --- a/README.md +++ b/README.md @@ -402,12 +402,12 @@ the `backend` label under `matchLabels` for the metric. The ingress annotation where the backend weights can be obtained can be specified through the flag `--skipper-backends-annotation`. -## Hostname RPS collector +## External RPS collector -The Hostname collector, like Skipper collector, is a simple wrapper around the Prometheus collector to +The External RPS collector, like Skipper collector, is a simple wrapper around the Prometheus collector to make it easy to define an HPA for scaling based on the RPS measured for a given hostname. When [skipper](https://github.com/zalando/skipper) is used as the ingress -implementation in your cluster everything should work automatically, in case another reverse proxy is used as ingress, like [Nginx](https://github.com/kubernetes/ingress-nginx) for example, its necessary to configure which prometheus metric should be used through `--hostname-rps-metric-name ` flag. Assuming `skipper-ingress` is being used or the appropriate metric name is passed using the flag mentioned previously this collector provides the correct Prometheus queries out of the +implementation in your cluster everything should work automatically, in case another reverse proxy is used as ingress, like [Nginx](https://github.com/kubernetes/ingress-nginx) for example, its necessary to configure which prometheus metric should be used through `--external-rps-metric-name ` flag. Assuming `skipper-ingress` is being used or the appropriate metric name is passed using the flag mentioned previously this collector provides the correct Prometheus queries out of the box so users don't have to define those manually. ### Supported metrics @@ -421,7 +421,7 @@ box so users don't have to define those manually. This is an example of an HPA that will scale based on `requests-per-second` for the RPS measured in the hostnames called: `www.example1.com` and `www.example2.com`; and weighted by 42%. ```yaml -apiVersion: autoscaling/v2beta2 +apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: myapp-hpa @@ -449,7 +449,7 @@ spec: ``` ### Multiple hostnames per metric -This metric supports a relation of n:1 with metrics. The way it works is the measured RPS is the sum of the RPS rate of each of the specified hostnames. This value is further modified by the weight parameter explained bellow. +This metric supports a relation of n:1 between hostnames and metrics. The way it works is the measured RPS is the sum of the RPS rate of each of the specified hostnames. This value is further modified by the weight parameter explained bellow. ### Metric weighting based on backend