Cette page explique en détail comment interroger et visualiser les alertes ouvertes à l'aide de la console GDC et de l'outil curl pour le point de terminaison Cortex afin d'identifier les problèmes et de les résoudre.
Après avoir créé des règles d'alerte basées sur les journaux et les métriques des environnements d'appliance Google Distributed Cloud (GDC) isolés, vous pouvez commencer à surveiller les alertes ouvertes de votre projet. Vous pouvez visualiser et filtrer les alertes déclenchées par les événements système dans la console GDC, ou y accéder directement depuis Cortex à l'aide de l'outil curl pour un script et une automatisation flexibles.
Vous pouvez accéder aux alertes ouvertes de l'une des deux manières suivantes :
- Console GDC : visualisez les données d'alerte dans des panneaux intégrés contenant des informations telles que le nombre d'alertes pour une source de données spécifique, le niveau de gravité, la durée, l'état, le message et les libellés. La console GDC fournit une interface conviviale pour filtrer et analyser les alertes provenant des composants de votre système.
- Point de terminaison Cortex Alertmanager : pour les cas d'utilisation plus avancés, interrogez directement l'instance Cortex de votre projet à l'aide de l'outil
curlsur une ligne de commande. Cortex stocke les alertes Alertmanager de votre projet et fournit un point de terminaison HTTP pour l'accès programmatique. Cet accès vous permet d'exporter des données, d'automatiser des tâches, de configurer des tâches cron et de créer des intégrations personnalisées.
Avant de commencer
Pour obtenir les autorisations nécessaires pour interroger et visualiser les alertes, demandez à votre administrateur IAM de projet de vous accorder l'un des rôles Alertmanager Project Cortex associés dans l'espace de noms de votre projet. Selon le niveau d'accès et les autorisations dont vous avez besoin, vous pouvez obtenir des rôles d'éditeur ou de lecteur pour cette ressource dans un projet.
Pour obtenir les autorisations nécessaires pour exporter des journaux, demandez à l'administrateur IAM du projet de vous accorder le rôle Lecteur Grafana du projet (project-grafana-viewer). Ce processus de contrôle des accès basé sur les rôles vous permet d'accéder aux visualisations de données en toute sécurité. Pour en savoir plus sur ces rôles, consultez Préparer les autorisations IAM.
Point de terminaison Grafana
Pour l'Application Operator (AO) :
Ouvrez l'URL suivante pour accéder au point de terminaison de votre projet :
https://GDC_URL/PROJECT_NAMESPACE/grafana
Remplacez les éléments suivants :
- GDC_URL : URL de votre organisation dans GDC.
- PROJECT_NAMESPACE : espace de noms de votre projet.
L'UI du projet contient des tableaux de bord par défaut tels que le tableau de bord Alertes – Vue d'ensemble, qui fournit des informations sur les alertes. L'interrogation des alertes depuis l'interface utilisateur vous permet de récupérer visuellement les informations sur les alertes de votre projet et d'obtenir une vue intégrée des ressources pour identifier et résoudre rapidement les problèmes.
Pour les administrateurs de plate-forme :
Ouvrez l'URL suivante pour accéder au point de terminaison de votre projet platform-obs :
https://GDC_URL/platform-obs/grafana
Remplacez GDC_URL par l'URL de votre organisation dans GDC.
L'interface utilisateur (UI) de l'instance de surveillance du système contient des tableaux de bord par défaut, tels que le tableau de bord Alertes – Vue d'ensemble, qui fournit des informations sur les alertes concernant l'observabilité des données. L'interrogation des alertes depuis l'interface utilisateur vous permet de récupérer visuellement les informations sur les alertes de votre projet et d'obtenir une vue intégrée des ressources pour identifier et résoudre rapidement les problèmes.
Figure 1 : Tableau de bord Alertes – Vue d'ensemble dans l'interface utilisateur Grafana.
Afficher et filtrer les alertes ouvertes
Sélectionnez l'une des méthodes suivantes pour interroger et filtrer les alertes ouvertes de l'espace de noms de votre projet :
Console
Affichez les alertes ouvertes dans un projet depuis la console GDC :
- Connectez-vous à la console GDC.
- Dans la console GDC, sélectionnez votre projet.
- Dans le menu de navigation, sélectionnez Opérations > Alertes.
- Sélectionnez l'onglet Alertes.
- Affichez la liste des alertes.
- Dans la section Alertes ouvertes, cliquez sur Filtrer pour n'afficher que les alertes ouvertes. Vous pouvez également filtrer les alertes par d'autres noms ou valeurs de propriété.
- Cliquez sur le nom d'une alerte pour afficher ses détails.
Point de terminaison Cortex
Cette section explique comment accéder aux alertes à l'aide de votre point de terminaison Cortex Alertmanager.
Identifier votre point de terminaison Cortex
L'URL suivante correspond au point de terminaison de l'instance Cortex de votre projet :
https://GDC_URL/PROJECT_NAMESPACE/cortex/alertmanager/
Remplacez les éléments suivants :
GDC_URL: URL de votre organisation dans GDC.PROJECT_NAMESPACE: espace de noms de votre projet.Par exemple, le point de terminaison Cortex pour le projet
platform-obsdans l'organisationorg-1esthttps://org-1/platform-obs/cortex/alertmanager/.
Authentifier la requête curl
- Téléchargez et installez la gdcloud CLI.
Définissez la propriété gdcloud
core/organization_console_url:gdcloud config set core/organization_console_url https://GDC_URLSe connecter avec le fournisseur d'identité configuré :
gdcloud auth loginUtilisez votre nom d'utilisateur et votre mot de passe pour vous authentifier et vous connecter.
Une fois la connexion établie, vous pouvez utiliser l'en-tête d'autorisation dans votre requête cURL à l'aide de la commande
gdcloud auth print-identity-token. Pour en savoir plus, consultez gdcloud auth.
Appeler le point de terminaison Cortex
Pour accéder au point de terminaison Cortex à l'aide de l'outil curl, procédez comme suit :
- Authentifiez la requête
curl. Utilisez
curlpour appeler le point de terminaison Cortex et étendre l'URL à l'aide de la spécification standard de l'API Alertmanager (https://prometheus.io/docs/prometheus/latest/querying/api/#alertmanagers) pour interroger les alertes.Voici un exemple de requête
curl:curl https://GDC_URL/PROJECT_NAME/cortex/alertmanager/api/v1/alertmanagers \ -H "Authorization: Bearer $(gdcloud auth print-identity-token \ --audiences=https://GDC_URL)"Vous obtenez le résultat suivant après l'exécution de la commande. La réponse de l'API est au format JSON.
Alertmanager
Alertmanager vous permet de surveiller les notifications d'alerte des applications clientes. Vous pouvez inspecter et mettre sous silence les alertes à l'aide d'Alertmanager, et les filtrer ou les regrouper :
Figure 2. Option de menu permettant d'interroger les journaux d'audit à partir d'Alertmanager.
Règles d'alerte prédéfinies
Le tableau suivant répertorie les règles d'alerte préinstallées dans Prometheus :
| Nom | Description |
|---|---|
| KubeAPIDown (critique) | KubeAPI a disparu de la détection de cible Prometheus pendant 15 minutes. |
| KubeClientErrors (avertissement) | Le taux d'erreurs client sur le serveur d'API Kubernetes est supérieur à 0,01 pendant 15 minutes. |
| KubeClientErrors (critique) | Le taux d'erreurs client sur le serveur d'API Kubernetes est supérieur à 0,1 pendant 15 minutes. |
| KubePodCrashLooping (avertissement) | Le pod plante en boucle depuis plus de 15 minutes. |
| KubePodNotReady (avertissement) | Le pod est en état non opérationnel depuis plus de 15 minutes. |
| KubePersistentVolumeFillingUp (critique) | Espace libre en octets d'un objet PersistentVolume revendiqué inférieur à 0,03. |
| KubePersistentVolumeFillingUp (avertissement) | Espace libre en octets d'un PersistentVolume revendiqué inférieur à 0,15. |
| KubePersistentVolumeErrors (critique) | Le volume persistant demeure en phase d'échec ou d'attente pendant cinq minutes. |
| KubeNodeNotReady (avertissement) | Le nœud n'a pas été opérationnel pendant plus de 15 minutes. |
| KubeNodeCPUUsageHigh (critique) | L'utilisation du processeur du nœud est supérieure à 80 %. |
| KubeNodeMemoryUsageHigh (critique) | L'utilisation de la mémoire du nœud est supérieure à 80 %. |
| NodeFilesystemSpaceFillingUp (avertissement) | L'utilisation du système de fichiers du nœud est supérieure à 60 %. |
| NodeFilesystemSpaceFillingUp (critique) | L'utilisation du système de fichiers du nœud est supérieure à 85 %. |
| CertManagerCertExpirySoon (avertissement) | Un certificat arrive à expiration dans 21 jours. |
| CertManagerCertNotReady (critique) | Un certificat n'est pas utilisable pour diffuser le trafic au bout de 10 minutes. |
| CertManagerHittingRateLimits (critique) | Une limite de débit a été atteinte lors de la création et du renouvellement des certificats pendant cinq minutes. |
| DeploymentNotReady (critique) | Un déploiement sur le cluster d'administrateur de l'organisation est en état non opérationnel depuis plus de 15 minutes. |
Exemple d'alertemanagerConfigurationConfigmaps
La syntaxe des configurations dans les ConfigMaps listés par alertmanagerConfigurationConfigmaps doit respecter https://prometheus.io/docs/alerting/latest/configuration/.
apiVersion: observability.gdc.goog/v1alpha1
kind: ObservabilityPipeline
metadata:
# Choose namespace that matches the project's namespace
namespace: kube-system
name: observability-config
# Configure Alertmanager
alerting:
# Storage size for alerting data within organization
# Permission: PA
localStorageSize: 1Gi
# Permission: PA & AO
# alertmanager config must be under the key "alertmanager.yml" in the configMap
alertmanagerConfig: <configmap-for-alertmanager-config>
# Permission: PA
volumes:
- <volume referenced in volumeMounts>
# Permission: PA
volumeMounts:
- <volumeMount referenced in alertmanagerConfig>
Exemple de configuration de règle
# Configures either an alert or a target record for precomputation
apiVersion: monitoring.gdc.goog/v1alpha1
kind: MonitoringRule
metadata:
# Choose namespace that contains the metrics that rules are based on
# Note: alert/record will be produced in the same namespace
namespace: g-fleetns-a
name: alerting-config
spec:
# Rule evaluation interval
interval: <duration>
# Configure limit for number of alerts (0: no limit)
# Optional, Default: 0 (no limit)
limit: <int>
# Configure record rules
recordRules:
# Define which timeseries to write to (must be a valid metric name)
- record: <string>
# Define PromQL expression to evaluate for this rule
expr: <string>
# Define labels to add or overwrite
# Optional, Map of {key, value} pairs
labels:
<labelname>: <labelvalue>
# Configure alert rules
alertRules:
# Define alert name
- alert: <string>
# Define PromQL expression to evaluate for this rule
# https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/
expr: <string>
# Define when an active alert moves from pending to firing
# Optional, Default: 0s
for: <duration>
# Define labels to add or overwrite
# Required, Map of {key, value} pairs
# Required labels:
# severity: [error, critical, warning, info]
# code:
# resource: component/service/hardware related to alert
# additional labels are optional
labels:
severity: <enum: [error, critical, warning, info]>
code:
resource: <Short name of the related operable component>
<labelname>: <tmpl_string>
# Define annotations to add
# Optional, Map of {key, value} pairs
# Recommended annotations:
# message: value of Message field in UI
# expression: value of Rule field in UI
# runbookurl: URL for link in Actions to take field in UI
annotations:
<labelname>: <tmpl_string>
# Configures either an alert or a target record for precomputation
apiVersion: logging.gdc.goog/v1alpha1
kind: LoggingRule
metadata:
# Choose namespace that contains the logs that rules are based on
# Note: alert/record will be produced in the same namespace
namespace: g-fleetns-a
name: alerting-config
spec:
# Choose which log source to base alerts on (Operational/Audit/Security Logs)
# Optional, Default: Operational
source: <string>
# Rule evaluation interval
interval: <duration>
# Configure limit for number of alerts (0: no limit)
# Optional, Default: 0 (no limit)
limit: <int>
# Configure record rules
recordRules:
# Define which timeseries to write to (must be a valid metric name)
- record: <string>
# Define LogQL expression to evaluate for this rule
# https://grafana.com/docs/loki/latest/rules/
expr: <string>
# Define labels to add or overwrite
# Optional, Map of {key, value} pairs
labels:
<labelname>: <labelvalue>
# Configure alert rules
alertRules:
# Define alert name
- alert: <string>
# Define LogQL expression to evaluate for this rule
expr: <string>
# Define when an active alert moves from pending to firing
# Optional, Default: 0s
for: <duration>
# Define labels to add or overwrite
# Required, Map of {key, value} pairs
# Required labels:
# severity: [error, critical, warning, info]
# code:
# resource: component/service/hardware related to alert
# additional labels are optional
labels:
severity: <enum: [error, critical, warning, info]>
code:
resource: <Short name of the related operable component>
<labelname>: <tmpl_string>
# Define annotations to add
# Optional, Map of {key, value} pairs
# Recommended annotations:
# message: value of Message field in UI
# expression: value of Rule field in UI
# runbookurl: URL for link in Actions to take field in UI
annotations:
<labelname>: <tmpl_string>
Interroger les alertes à partir de l'API HTTP
La plate-forme Observabilité expose un point de terminaison d'API HTTP pour interroger et lire les métriques, les alertes et d'autres données de séries temporelles de votre projet pour la surveillance du système.Configurez des tâches automatisées, adaptez les réponses et créez des intégrations en fonction de votre cas d'utilisation à l'aide des alertes de requête directement depuis l'API HTTP Observability. Par exemple, insérez la sortie dans une autre commande, exportez les détails au format texte ou configurez une job Cron Linux. Vous pouvez appeler l'API HTTP d'observabilité à partir de l'interface de ligne de commande (CLI) ou d'un navigateur Web, et obtenir le résultat au format JSON.
Cette section explique comment appeler le point de terminaison de l'API HTTP d'observabilité à partir de la CLI à l'aide de la spécification de l'APIpour interroger les alertes.
Configurez des tâches automatisées, adaptez les réponses et créez des intégrations en fonction de votre cas d'utilisation à l'aide des alertes de requête directement depuis l'API HTTP Observability. Par exemple, insérez la sortie dans une autre commande, exportez les détails au format texte ou configurez une job Cron Linux. Vous pouvez appeler l'API HTTP d'observabilité à partir de l'interface de ligne de commande (CLI) ou d'un navigateur Web, et obtenir le résultat au format JSON.
Cette section explique comment appeler le point de terminaison de l'API HTTP d'observabilité à partir de la CLI à l'aide de la spécification de l'API Alertmanager pour interroger les métriques.
Avant de commencer
Pour obtenir les autorisations nécessaires pour accéder au point de terminaison de l'API HTTP Observability, demandez à l'administrateur IAM de votre projet de vous attribuer le rôle Lecteur Alertmanager Project Cortex (project-cortex-alertmanager-viewer) dans l'espace de noms de votre projet.
L'administrateur IAM du projet peut vous accorder l'accès en créant une liaison de rôle :
a. Administrateur racine de l'opérateur d'infrastructure (IO) : Project Cortex Alertmanager Viewer
kubectl --kubeconfig $HOME/root-admin-kubeconfig create rolebinding
io-cortex-alertmanager-viewer-binding -n infra-obs
--user=fop-infrastructure-operator@example.com
--role=project-cortex-alertmanager-viewer
b. Administrateur de plate-forme (PA) Administrateur racine : Project Cortex Alertmanager Viewer
kubectl --kubeconfig $HOME/root-admin-kubeconfig create rolebinding
pa-cortex-alertmanager-viewer-binding -n platform-obs
--user=fop-platform-admin@example.com
--role=project-cortex-alertmanager-viewer
c. Administrateur racine de l'opérateur d'application (AO) : lecteur Alertmanager Project Cortex : Projet : $AO_PROJECT Nom d'utilisateur AO : $AO_USER
kubectl --kubeconfig $HOME/root-admin-kubeconfig create rolebinding
project-cortex-alertmanager-viewer-binding -n $AO_PROJECT
--user=$AO_USER
--role=project-cortex-alertmanager-viewer
Une fois l'association de rôle créée, vous pouvez accéder à Alertmanager correspondant avec votre nom d'utilisateur.
Valider la liaison de rôle
kubectl --kubeconfig $HOME/org-1-admin-kubeconfig get rolebinding -n platform-obs
Pour savoir comment définir des liaisons de rôle à partir de la console GDC, consultez Accorder l'accès aux ressources.
Point de terminaison Cortex
L'URL suivante est le point de terminaison Cortex permettant d'accéder aux alertes :
https://GDC_URL/PROJECT_NAME/cortex/alertmanager/
Remplacez les éléments suivants :
- GDC_URL : URL de votre organisation dans GDC.
- PROJECT_NAME : le nom de votre projet
Appeler le point de terminaison de l'API
Pour accéder au point de terminaison de l'API Cortex depuis l&#CLI et interroger les alertes, procédez comme suit :
- Assurez-vous de remplir les conditions préalables.
- Ouvrez la CLI.
Utilisez l'outil
curlpour appeler l'URL du point de terminaison Cortex et étendre l'URL à l'aide de la norme https://prometheus.io/docs/prometheus/latest/querying/api/#alertmanagers pour interroger les alertes. Exemple :curl https://console.org-1.zone1.google.gdch.test/alice/cortex/alertmanager/api/v1/alertmanagers
Vous obtenez le résultat dans la CLI après la commande. Le format de réponse de l'API est JSON.