Comment fonctionne la surveillance

Prometheus Operator observe la création de ServiceMonitors, PodMonitors et PrometheusRules. Lorsque les ressources de configuration de Prometheus sont créées, Prometheus Operator appelle l’API Prometheus pour synchroniser la nouvelle configuration. Comme le montre le diagramme à la fin de cette section, Prometheus Operator agit comme intermédiaire entre Prometheus et Kubernetes, appelant l’API Prometheus pour synchroniser Prometheus avec les ressources liées à la surveillance dans Kubernetes.

ServiceMonitors et PodMonitors spécifient de manière déclarative les cibles, telles que les Services et les Pods, qui doivent être surveillées.

Les PrometheusRules permettent aux utilisateurs de définir des règles pour déterminer quelles métriques ou requêtes de base de données de séries temporelles doivent déclencher des alertes. Les règles sont évaluées à intervalles réguliers.

Une fois que Prometheus détermine qu’une alerte doit être déclenchée, les alertes sont transférées à Alertmanager.

Après avoir collecté des métriques auprès des exportateurs, Prometheus stocke les séries temporelles dans une base de données de séries temporelles locale sur disque. Prometheus s’intègre optionnellement à des systèmes distants, mais rancher-monitoring utilise un stockage local pour la base de données de séries temporelles.

Une fois stockées, les utilisateurs peuvent interroger cette TSDB en utilisant PromQL, le langage de requête pour Prometheus.

Les requêtes PromQL peuvent être visualisées de deux manières :

Les règles définissent des requêtes que Prometheus doit exécuter régulièrement evaluationInterval pour effectuer certaines actions, telles que déclencher une alerte (règles d’alerte) ou précalculer une requête basée sur d’autres existant dans sa TSDB (règles d’enregistrement). Ces règles sont encodées dans des ressources personnalisées PrometheusRules. Lorsque des ressources personnalisées PrometheusRule sont créées ou mises à jour, l’Opérateur Prometheus observe le changement et appelle l’API Prometheus pour synchroniser l’ensemble des règles que Prometheus évalue actuellement à intervalles réguliers.

Une PrometheusRule vous permet de définir un ou plusieurs RuleGroups. Chaque RuleGroup se compose d’un ensemble d’objets Rule qui peuvent chacun représenter soit une règle d’alerte, soit une règle d’enregistrement avec les champs suivants :

Lors de l’évaluation d’une règle, Prometheus exécute la requête PromQL fournie, ajoute les étiquettes fournies et exécute l’action appropriée pour la règle. Si la règle déclenche une alerte, Prometheus ajoute également les annotations fournies. Par exemple, une règle d’alerte qui ajoute team: front-end comme étiquette à la requête PromQL fournie ajoutera cette étiquette à l’alerte déclenchée, ce qui permettra à Alertmanager de transmettre l’alerte au bon destinataire.

Prometheus ne maintient pas l’état des alertes actives. Il déclenche des alertes de manière répétée à chaque intervalle d’évaluation, s’appuyant sur Alertmanager pour regrouper et filtrer les alertes en notifications significatives.

La constante evaluation_interval définit la fréquence à laquelle Prometheus évalue ses règles d’alerte par rapport à la base de données de séries temporelles. Semblable au scrape_interval, le evaluation_interval a également une valeur par défaut d’une minute.

Les règles sont contenues dans un ensemble de fichiers de règles. Les fichiers de règles incluent à la fois des règles d’alerte et des règles d’enregistrement, mais seules les règles d’alerte entraînent le déclenchement d’alertes après leur évaluation.

Pour les règles d’enregistrement, Prometheus exécute une requête, puis la stocke en tant que série temporelle. Cette série temporelle synthétique est utile pour stocker les résultats d’une requête coûteuse ou chronophage afin qu’elle puisse être interrogée plus rapidement à l’avenir.

Les règles d’alerte sont plus couramment utilisées. Chaque fois qu’une règle d’alerte renvoie un nombre positif, Prometheus déclenche une alerte.

Le fichier de règles ajoute des étiquettes et des annotations aux alertes avant de les déclencher, en fonction du cas d’utilisation :

Lorsque les alertingDrivers sont installés, cela crée un Service qui peut être utilisé comme l’URL du récepteur pour Teams ou SMS, en fonction de la configuration de l’alertingDriver. L’URL dans le récepteur pointe vers les alertingDrivers ; ainsi, l’Alertmanager envoie d’abord l’alerte à l’alertingDriver, puis l’alertingDriver transfère ou envoie l’alerte à la destination appropriée.

L’Alertmanager coordonne où les alertes sont envoyées. Il vous permet de regrouper les alertes en fonction des étiquettes et de les déclencher en fonction de la correspondance de certaines étiquettes. Une route de niveau supérieur accepte toutes les alertes. À partir de là, l’Alertmanager continue de router les alertes vers les récepteurs en fonction de la correspondance avec les conditions de la prochaine route.

Bien que les formulaires de l’interface utilisateur de Rancher ne permettent d’éditer qu’un arbre de routage de deux niveaux, vous pouvez configurer des structures de routage plus profondément imbriquées en modifiant le Secret d’Alertmanager.

En modifiant les formulaires dans l’interface utilisateur de Rancher, vous pouvez configurer une ressource Récepteur avec toutes les informations nécessaires à l’Alertmanager pour envoyer des alertes à votre système de notification.

En modifiant le YAML personnalisé dans la configuration d’Alertmanager ou de Récepteur, vous pouvez également envoyer des alertes à plusieurs systèmes de notification. Pour plus d’informations, consultez la section sur la configuration de Récepteurs.

Par défaut, un ensemble de ressources sélectionnées par le projet kube-prometheus est déployé sur votre cluster dans le cadre de l’installation de l’application de surveillance Rancher pour configurer une pile de surveillance/alerte de base.

Les ressources qui sont déployées sur votre cluster pour soutenir cette solution se trouvent dans le chart Helm rancher-monitoring, qui suit de près le chart Helm kube-prometheus-stack en amont maintenu par la communauté Prometheus avec certains changements suivis dans le CHANGELOG.md.

La surveillance V2 déploie trois exportateurs par défaut qui fournissent des métriques supplémentaires que Prometheus peut stocker :

Les ServiceMonitors et PodMonitors vont interroger ces exportateurs, comme défini ici. Prometheus stocke ces métriques, et vous pouvez interroger les résultats via l’interface utilisateur de Prometheus ou Grafana.

Voir la section architecture pour plus d’informations sur les règles d’enregistrement, les règles d’alerte et Alertmanager.

Lorsque l’application de surveillance est installée, vous pourrez modifier les composants suivants dans l’interface utilisateur de Rancher :

PushProx permet à Prometheus d’extraire des métriques à travers une frontière réseau, ce qui empêche les utilisateurs d’avoir à exposer des ports de métriques pour les composants internes de Kubernetes sur chaque nœud d’un cluster Kubernetes.

Étant donné que les métriques pour les composants Kubernetes sont généralement exposées sur le réseau hôte des nœuds dans le cluster, PushProx déploie un DaemonSet de clients qui se trouvent sur le réseau hôte de chaque nœud et établissent une connexion sortante vers un seul proxy qui se trouve sur l’API Kubernetes. Prometheus peut ensuite être configuré pour proxy les requêtes de scraping à travers le proxy vers chaque client, ce qui lui permet d’extraire des métriques des composants internes de Kubernetes sans nécessiter l’ouverture de ports de nœud entrants.

Consultez Scraping Metrics with PushProx pour plus d’informations.

ServiceMonitors et PodMonitors définissent des cibles destinées à être interrogées par Prometheus. La ressource personnalisée Prometheus indique à Prometheus quels ServiceMonitors ou PodMonitors il doit utiliser pour savoir d’où interroger les métriques.

L’Opérateur Prometheus observe les ServiceMonitors et PodMonitors. Lorsqu’il observe qu’ils sont créés ou mis à jour, il appelle l’API Prometheus pour mettre à jour la configuration de scraping dans la ressource personnalisée Prometheus et la maintenir synchronisée avec la configuration de scraping dans les ServiceMonitors ou PodMonitors. Cette configuration de scraping indique à Prometheus depuis quels points de terminaison scraper les métriques et comment il étiquettera les métriques de ces points de terminaison.

Prometheus scrappe toutes les métriques définies dans sa configuration de scraping à chaque scrape_interval, ce qui correspond à une minute par défaut.

La configuration de scraping peut être vue comme faisant partie de la ressource personnalisée de Prometheus qui est exposée dans l’interface utilisateur de Rancher.

Le déploiement ou StatefulSet de Prometheus scrappe les métriques, et la configuration de Prometheus est contrôlée par les ressources personnalisées de Prometheus. L’Opérateur Prometheus surveille les ressources Prometheus et Alertmanager, et lorsqu’elles sont créées, l’Opérateur Prometheus crée un déploiement ou StatefulSet pour Prometheus ou Alertmanager avec la configuration définie par l’utilisateur.

Lorsque l’Opérateur Prometheus observe la création de ServiceMonitors, PodMonitors et PrometheusRules, il sait que la configuration de scraping doit être mise à jour dans Prometheus. Il met à jour Prometheus en commençant par mettre à jour les fichiers de configuration et de règles dans les volumes du déploiement ou StatefulSet de Prometheus. Ensuite, il appelle l’API de Prometheus pour synchroniser la nouvelle configuration, ce qui entraîne la modification en place du déploiement ou StatefulSet de Prometheus.

Prometheus scrappe les métriques des déploiements connus sous le nom de exporters, qui exportent les données de séries temporelles dans un format que Prometheus peut ingérer. Dans Prometheus, les séries temporelles consistent en des flux de valeurs horodatées appartenant à la même métrique et au même ensemble de dimensions étiquetées.

Certains composants internes de Kubernetes sont scrappés via un proxy déployé dans le cadre de Monitoring V2 appelé PushProx. Pour des informations détaillées sur PushProx, référez-vous ici et à la section architecture ci-dessus.

Les composants Kubernetes suivants sont directement scrappés par Prometheus :

Les métriques sont collectées différemment en fonction de la distribution Kubernetes. Pour de l’aide avec la terminologie, référez-vous ici. Pour plus de détails, consultez le tableau ci-dessous :