kubernetes-sigs/prometheus-adapter
1
0
Fork 1
mirror of https://github.com/kubernetes-sigs/prometheus-adapter.git synced 2026-04-05 17:27:51 +00:00
Code Issues Projects Releases Packages Activity Actions

[docs] Add walkthrough

Browse source 
This adds a walkthrough to the docs covering setting up Prometheus and
the adapter, as well as autoscaling a sample application on custom
metrics.
This commit is contained in:
Solly Ross 2017-08-11 17:42:15 -04:00
parent b6602e1724
commit 4e99936e4f
3 changed files with 569 additions and 40 deletions
Download patch file Download diff file Expand all files Collapse all files

58
README.md
View file

@ -37,55 +37,33 @@ adapter talks to Prometheus and the main Kubernetes cluster:
Presentation
------------
The adapter gathers the names of available metrics from Prometheus at the
specified interval. Only metrics of the following forms are considered:
The adapter gathers the names of available metrics from Prometheus
a regular interval (see [Configuration](#configuration) above), and then
only exposes metrics that follow specific forms.
- "container" metrics (cAdvisor container metrics): series with a name
starting with `container_`, as well as non-empty `namespace` and
`pod_name` labels.
In general:
- "namespaced" metrics (metrics describing namespaced Kubernetes objects):
series with non-empty namespace labels (which don't start with
`container_`).
- Metrics must have the `namespace` label to be considered.
*Note*: Currently, metrics on non-namespaced objects (besides namespaces
themselves) are not supported.
- For each label on a metric, if that label name corresponds to
a Kubernetes resource (like `pod` or `service`), the metric will be
associated with that resource.
Metrics in Prometheus are converted in the custom-metrics-API metrics as
follows:
- Metrics ending in `_total` are assumed to be cumulative, and will be
exposed without the suffix as a rate metric.
1. The metric name and type are decided:
- For container metrics, the `container_` prefix is removed
- If the metric has the `_total` suffix, it is marked as a counter
metric, and the suffix is removed
- If the metric has the `_seconds_total` suffix, it is marked as
a seconds counter metric, and the suffix is removed.
- If the metric has none of the above suffixes, is is marked as a gauge
metric, and the metric name is used as-is
2. Relevant resources are associated with the metric:
- container metrics are associated with pods only
- for non-container metrics, each label on the series is considered. If
that label represents a resource (without the group) available on the
server, the metric is associated with that resource. A metric may be
associated with multiple resources.
When retrieving counter and seconds-counter metrics, the adapter requests
the metrics as a rate over the configured amount of time. For metrics
with multiple associated resources, the adapter requests the metric
aggregated over all non-requested metrics.
The adapter does not consider resources consumed by the "POD" container,
which exists as part of all Kubernetes pods running in Docker simply
supports the existance of the pod's shared network namespace.
Detailed information can be found under [docs/format.md](docs/format.md).
Example
-------
@luxas has an excellent example deployment of Prometheus, this adapter,
and a demo pod which serves a metric `http_requests_total`, which becomes
the custom metrics API metric `pods/http_requests`. It also autoscales on
that metric using the `autoscaling/v2alpha1` HorizontalPodAutoscaler.
A brief walkthrough exists in [docs/walkthrough.md](docs/walkthrough.md).
Additionally, [@luxas](https://github.com/luxas) has an excellent example
deployment of Prometheus, this adapter, and a demo pod which serves
a metric `http_requests_total`, which becomes the custom metrics API
metric `pods/http_requests`. It also autoscales on that metric using the
`autoscaling/v2alpha1` HorizontalPodAutoscaler.
It can be found at https://github.com/luxas/kubeadm-workshop. Pay special
attention to: