public/rancher-docs
1
0
Fork 0
mirror of https://github.com/rancher/rancher-docs.git synced 2026-05-16 01:53:51 +00:00
Code Issues Packages Projects Releases Wiki Activity

Edit monitoring docs

Browse Source
This commit is contained in:
Catherine Luse
2020-10-09 16:13:59 -07:00
parent e43d6ee0af
commit 9324d81c83
2 changed files with 17 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/rancher/v2.x/en/monitoring-alerting/configuration/_index.md
+11 -20
View File
@@ -5,21 +5,19 @@ weight: 3
This page captures some of the most important options for configuring the custom resources for monitoring.
For information on configuring custom Prometheus metrics and alerting rules, refer to the upstream documentation for the [Prometheus operator.](https://github.com/prometheus-operator/prometheus-operator) Some of the most important custom resources are explained in the Prometheus [design documentation.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/design.md) The Prometheus documentation can help also you set up RBAC, Thanos, or custom configuration.
For information on configuring custom scrape targets and rules for Prometheus, please refer to the upstream documentation for the [Prometheus Operator.](https://github.com/prometheus-operator/prometheus-operator) Some of the most important custom resources are explained in the Prometheus Operator [design documentation.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/design.md) The Prometheus Operator documentation can help also you set up RBAC, Thanos, or custom configuration.
- [About Prometheus Configuration](#about-prometheus-configuration)
- [Configuring Prometheus](#configuring-prometheus)
- [Configuring Targets with ServiceMonitors and PodMonitors](#configuring-targets-with-servicemonitors-and-podmonitors)
- [ServiceMonitors](#servicemonitors)
- [PodMonitors](#podmonitors)
- [Configuring Alerts or Recording Rules with PrometheusRules](#configuring-alerts-or-recording-rules-with-prometheusrules)
- [PrometheusRules](#prometheusrules)
- [Recording Rules](#recording-rules)
- [Alertmanager Config](#alertmanager-config)
- [Trusted CA for Notifiers](#trusted-ca-for-notifiers)
- [Additional Scrape Configurations](#additional-scrape-configurations)
- [Examples](#examples)
# About Prometheus Configuration
# Configuring Prometheus
The primary way that users will be able to customize this feature for specific Monitoring and Alerting use cases is by creating and/or modifying ConfigMaps, Secrets, and Custom Resources pertaining to this deployment.
@@ -29,7 +27,7 @@ Prometheus Operator will automatically update your Prometheus configuration base
There are also certain special types of ConfigMaps/Secrets such as those corresponding to Grafana Dashboards, Grafana Datasources, and Alertmanager Configs that will automatically update your Prometheus configuration via sidecar proxies that observe the live state of those resources within your cluster.
By default, a set of these resources is created within your cluster as part of deploying this chart to set up a basic Monitoring/Alerting stack. We use the ones generated by [kube-prometheus.](https://github.com/prometheus-operator/kube-prometheus) For more information how to configure custom targets, alerts, notifiers, and dashboards after deploying the chart, see below.
By default, a set of these resources (curated by the [kube-prometheus](https://github.com/prometheus-operator/kube-prometheus) project) are deployed onto your cluster as part of installing the Rancher Monitoring Application to set up a basic Monitoring / Alerting stack. For more information how to configure custom targets, alerts, notifiers, and dashboards after deploying the chart, see below.
# Configuring Targets with ServiceMonitors and PodMonitors
@@ -39,18 +37,12 @@ Customizing the scrape configuration used by Prometheus to determine which resou
This CRD declaratively specifies how groups of Kubernetes services should be monitored. Any Services in your cluster that match the labels located within the ServiceMonitor `selector` field will be monitored based on the `endpoints` specified on the ServiceMonitor. For more information on what fields can be specified, please look at the [spec](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#servicemonitor) provided by Prometheus Operator.
For more information about how ServiceMonitors work, refer to the [Prometheus documentation.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/user-guides/running-exporters.md)
For more information about how ServiceMonitors work, refer to the [Prometheus Operator documentation.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/user-guides/running-exporters.md)
### PodMonitors
This CRD declaratively specifies how group of pods should be monitored. Any Pods in your cluster that match the labels located within the PodMonitor `selector` field will be monitored based on the `podMetricsEndpoints` specified on the PodMonitor. For more information on what fields can be specified, please look at the [spec](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#podmonitorspec) provided by Prometheus Operator.
# Configuring Alerts or Recording Rules with PrometheusRules
Customizing the alerts recorded by Prometheus and the configuration of notifications based on those alerts will primarily involve creating/modifying PrometheusRules and the Alertmanager Config Secret.
The Alertmanager Config Secret needs to be a Secret that exists in the `cattle-monitoring` system namespace in order for that to be used. On deploying the Rancher Monitoring application, a default Secret is automatically created if an existing Secret is not specified as part of the `Chart Options`; however, the Secret created on installing the chart will never be modified / removed on an upgrade / uninstall.
### PrometheusRules
This CRD defines a group of Prometheus alerting and/or recording rules.
@@ -58,11 +50,11 @@ This CRD defines a group of Prometheus alerting and/or recording rules.
To add a group of alerting / recording rules, you should create a PrometheusRule CR the defines a RuleGroup with your desired rules, each specifying:
- The name of the new alert / record
- A PromQL expression for the new alert / record (`expr`)
- A PromQL expression for the new alert / record
- Labels that should be attached to the alert / record that identify it (e.g. cluster name or severity)
- Annotations that encode any additional important pieces of information that need to be displayed on the notification for an alert (e.g. summary, description, message, runbook URL, etc.). This field is not required for recording rules.
For more information on what fields can be specified, please look at the [spec.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#prometheusrulespec)
For more information on what fields can be specified, please look at the [Prometheus Operator spec.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#prometheusrulespec)
### Alertmanager Config
@@ -82,6 +74,8 @@ For more information on what fields can be specified in this secret, please look
The full spec for the Alertmanager configuration file and what it takes in can be found [here.](https://prometheus.io/docs/alerting/latest/configuration/#configuration-file)
The notification integrations are configured with the `receiver`, which is documented [here.](https://prometheus.io/docs/alerting/latest/configuration/#receiver)
For more information, refer to the [official Prometheus documentation about configuring routes.](https://www.prometheus.io/docs/alerting/latest/configuration/#route)
# Trusted CA for Notifiers
@@ -98,12 +92,9 @@ If you need to add a trusted CA to your notifier, follow these steps:
If the scrape configuration you want cannot be specified via a ServiceMonitor or PodMonitor at the moment, you can provide an `additionalScrapeConfigSecret` on deploying or upgrading `rancher-monitoring`.
A [scrape_config section](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config) specifies a set of targets and parameters describing how to scrape them. In the general case, one scrape configuration specifies a single job.
If you want to enable Istio in the cluster, you might need to use an additional scrape configuration to ensure you can view traffic, metrics and graphs for resources deployed in other namespaces than only the `istio-system`.
To create an additional scrape configuration, refer to [this page.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/additional-scrape-config.md)
A [scrape_config section](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config) specifies a set of targets and parameters describing how to scrape them. In the general case, one scrape configuration specifies a single job.
An example of where this might be used is with Istio. For more information, see [this section.](https://rancher.com/docs/rancher/v2.x/en/istio/setup/enable-istio-in-cluster/#selectors-scrape-configs)
# Examples
content/rancher/v2.x/en/monitoring-alerting/migrating/_index.md
+6 -4
View File
@@ -3,11 +3,11 @@ title: Migrating to Rancher v2.5 Monitoring
weight: 5
---
If you previously enabled Monitoring, Alerting, or Notifiers in Rancher prior to v2.5, there is no upgrade path for switching to the new monitoring/alerting solution. You will need to disable monitoring/alerting/notifiers in Cluster Manager before deploying the new monitoring solution via Cluster Explorer.
If you previously enabled Monitoring, Alerting, or Notifiers in Rancher prior to v2.5, there is no upgrade path for switching to the new monitoring/alerting solution. You will need to disable monitoring/alerting/notifiers in the same way it was disabled in Rancher v2.4 before deploying the new monitoring solution via Cluster Explorer.
### Legacy Monitoring/Alerting via Cluster Manager
### Monitoring Prior to Rancher v2.5
As of v2.2.0, Rancher's Cluster Manager allowed users to enable Monitoring & Alerting V1 (both powered by [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator)) independently within a cluster. For more information on how to configure Monitoring & Alerting V1, see the [Legacy docs](/rancher/v2.x/en/monitoring-alerting/legacy).
As of v2.2.0, Rancher's Cluster Manager allowed users to enable Monitoring & Alerting V1 (both powered by [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator)) independently within a cluster. For more information on how to configure Monitoring & Alerting V1, see the [docs about monitoring prior to Rancher v2.5](/rancher/v2.x/en/monitoring-alerting/legacy).
When Monitoring is enabled, Monitoring V1 deploys [Prometheus](https://prometheus.io/) and [Grafana](https://grafana.com/docs/grafana/latest/getting-started/what-is-grafana/) onto a cluster to monitor the state of processes of your cluster nodes, Kubernetes components, and software deployments and create custom dashboards to make it easy to visualize collected metrics.
@@ -21,7 +21,9 @@ As of v2.5.0, Rancher's Cluster Explorer now allows users to enable Monitoring &
Unlike in Monitoring & Alerting V1, both features are packaged in a single Helm chart found [here](https://github.com/rancher/charts/blob/main/charts/rancher-monitoring). The behavior of this chart and configurable fields closely matches [kube-prometheus-stack](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack), a Prometheus Community Helm chart, and any deviations from the upstream chart can be found in the [CHANGELOG.md](https://github.com/rancher/charts/blob/main/charts/rancher-monitoring/CHANGELOG.md) maintained with the chart.
If you currently use Monitoring or Alerting V1 and are interested in upgrading to Monitoring & Alerting V2 in Rancher 2.5, please see [Migrating to 2.5.x](/rancher/v2.x/en/monitoring-alerting/2.5.x/migrating/). For more information on how to configure Monitoring & Alerting V2, see the [2.5.x docs](/rancher/v2.x/en/monitoring-alerting/2.5.x).
Monitoring V2 can only be configured on the cluster level. Project-level monitoring and alerting is no longer supported.
For more information on how to configure Monitoring & Alerting V2, see the [docs for monitoring in Rancher v2.5](/rancher/v2.x/en/monitoring-alerting).
### Changes to Role-based Access Control