{{ template "chart.header" . }} {{ template "chart.deprecationWarning" . }} {{ template "chart.badgesSection" . }} {{ template "chart.description" . }} {{ template "chart.homepageLine" . }} This chart deploys the Cluster Metrics feature of the Kubernetes Observability Helm chart, which uses allow lists to limit the metrics needed. An allow list is a set of metric names that will be kept, while any metrics not on the list will be dropped. With [metrics tuning](#metrics-tuning--allow-lists), you can further customize which metrics are collected. ## How it works This chart includes the ability to collect metrics from the following: * The Kubernetes cluster itself * Sources like the Kubelet and cAdvisor * Common supporting services like [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) and [Node Exporter](https://github.com/prometheus/node_exporter) * Systems to capture additional data like Kepler ### Metrics sources The Cluster Metrics feature of the Kubernetes Observability Helm chart includes the following metric systems and their default allow lists: | Metric source | Gathers information about | Allow list | |------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | API Server | Kubernetes API Server | NA | | [cAdvisor](https://github.com/google/cadvisor) | Containers on each node | [default-allow-lists/cadvisor.yaml](./default-allow-lists/cadvisor.yaml) | | [Kepler](https://sustainable-computing.io/) | Kubernetes cluster | [default-allow-lists/kepler.yaml](./default-allow-lists/kepler.yaml) | | Kube Controller Manager | Kubernetes Controller Manager | NA | | Kube Proxy | Kube Proxy | NA | | Kube Scheduler | Kube Scheduler | NA | | Kubelet | Kubernetes information on each node | [default-allow-lists/kubelet.yaml](./default-allow-lists/kubelet.yaml) | | [kube-state-metrics](https://github.com/kubernetes/kube-state-metrics) | Kubernetes | | | resources inside the cluster | [default-allow-lists/kube-state-metrics.yaml](./default-allow-lists/kube-state-metrics.yaml) | | | [Node Exporter](https://github.com/prometheus/node_exporter) | Linux Kubernetes nodes | [default-allow-lists/node-exporter.yaml](./default-allow-lists/node-exporter.yaml), [default-allow-lists/node-exporter-integration.yaml](./default-allow-lists/node-exporter-integration.yaml) | | [Windows Exporter](https://github.com/prometheus-community/windows_exporter) | Windows Kubernetes nodes | [default-allow-lists/windows-exporter.yaml](./default-allow-lists/windows-exporter.yaml) | ## Metrics tuning and allow lists For any metric source, you can adjust the amount of metrics being scraped and their labels to limit the number of metrics delivered to your destinations. Many of the metric sources have a default allow list. The allow list for a metric source is designed to return a useful, but minimal set of metrics for typical use cases. Some metrics sources have an integration allow list, which contains even more metrics for diving into the details of the source itself. To control metrics with allow lists or label filters, use the `metricsTuning` section in the values file. ```yaml : metricsTuning: useDefaultAllowList: # Use the allow list for this metric source useIntegrationAllowList: # Use the integration allow list for this metric source includeMetrics: [] # Metrics to be kept excludeMetrics: [] # Metrics to be dropped ``` The behavior of the combination of these settings is shown in this table: | Allow list | includeMetrics | excludeMetrics | Result | |------------|------------------|--------------------------|-----------------------------------------------------------------------------------------------------------------------------------------| | true | `[]` | `[]` | Use the allow list metric list | | false | `[]` | `[]` | No filter, keep all metrics | | true | `[my_metric]` | `[]` | Use the allow list metric list with an additional metric | | false | `[my_metric_.*]` | `[]` | *Only* keep metrics that start with `my_metric_` | | true | `[]` | `[my_metric_.*]` | Use the allow list metric filter, but exclude anything that starts with `my_metric_` | | false | `[]` | `[my_metric_.*]` | Keep all metrics except anything that starts with `my_metric_` | | true | `[my_metric_.*]` | `[other_metric_.*]` | Use the allow list metric filter, and keep anything that starts with `my_metric_`, but remove anything that starts with `other_metric_` | | false | `[my_metric_.*]` | `[my_metric_not_needed]` | *Only* keep metrics that start with `my_metric_`, but remove any that are named `my_metric_not_needed` | ## Relabeling rules You can also use relabeling rules to take any action on the metrics allow list, such as to filter based on a label. To do so, use `extraMetricProcessingRules` section in the values file to add arbitrary relabeling rules. ## Testing This chart contains unit tests to verify the generated configuration. The hidden value `deployAsConfigMap` will render the generated configuration into a ConfigMap object. While this ConfigMap is not used during regular operation, you can use it to show the outcome of a given values file. The unit tests use this ConfigMap to create an object with the configuration that can be asserted against. To run the tests, use `helm test`. Be sure perform actual integration testing in a live environment in the main [k8s-monitoring](../..) chart. {{ template "chart.maintainersSection" . }} {{ template "chart.sourcesSection" . }} {{ template "chart.requirementsSection" . }} {{ template "chart.valuesSection" . }}