Cette page a été traduite par l'API Cloud Translation.

Dépannage de l'observabilité

Ce document explique comment identifier les échecs de déploiement et les incidents opérationnels que vous pouvez rencontrer dans l'appliance Google Distributed Cloud (GDC) isolée. Il contient des descriptions de toutes les alertes affichées dans le système pour vous aider à résoudre les problèmes courants liés aux composants de journalisation et de surveillance.

Identifier les composants d'Observability

La plate-forme d'observabilité déploie ses composants dans l'espace de noms obs-system du cluster d'infrastructure de l'organisation.

L'instance Grafana de l'opérateur d'infrastructure (IO) permet d'accéder aux métriques au niveau de l'organisation pour surveiller les composants de l'infrastructure tels que l'utilisation du processeur et la consommation de stockage. Il donne également accès aux journaux d'audit et opérationnels. Il donne également accès aux alertes, aux journaux et aux métriques des composants exploitables de GDC.

Les piles de surveillance et de journalisation GDC utilisent des solutions Open Source dans la plate-forme d'observabilité. Ces composants collectent les journaux et les métriques des pods Kubernetes, des machines bare metal, des commutateurs réseau, du stockage et des services gérés.

Le tableau suivant décrit tous les composants qui intègrent la plate-forme Observability :

Composant	Description
`Prometheus`	Prometheus est une base de données de séries temporelles permettant de collecter et de stocker des métriques, et d'évaluer des alertes. Prometheus stocke les métriques dans l'instance Cortex du cluster d'infrastructure de l'organisation pour le stockage à long terme. Prometheus ajoute des libellés sous forme de paires clé/valeur et collecte des métriques à partir des nœuds, des pods, des machines physiques, des commutateurs réseau et des appliances de stockage Kubernetes.
`Alertmanager`	Alertmanager est un système de gestion défini par l'utilisateur qui envoie des alertes lorsque des journaux ou des métriques indiquent que des composants du système sont en panne ou ne fonctionnent pas normalement. Il gère le routage, la désactivation et l'agrégation des alertes Prometheus.
`Loki`	Loki est une base de données de séries temporelles qui stocke et agrège les journaux provenant de différentes sources. Il indexe les journaux pour permettre des requêtes efficaces.
`Grafana`	Grafana fournit une interface utilisateur (UI) permettant d'afficher les métriques collectées par Prometheus et d'interroger les journaux d'audit et opérationnels des instances Loki correspondantes. L'UI vous permet de visualiser des tableaux de bord de métriques et d'alertes.
`Fluent Bit`	Fluent Bit est un processeur qui extrait les journaux de différents composants ou emplacements et les envoie dans Loki. Il s'exécute sur chaque nœud de tous les clusters.

Identifier les échecs de déploiement

Si votre déploiement est en cours d'exécution et opérationnel, les composants sont à l'état READY.

Suivez les étapes ci-dessous pour identifier les échecs de déploiement :

Confirmez l'état actuel d'un composant :
```
kubectl get -n obs-system TYPE/COMPONENT
```
Remplacez les éléments suivants :
- TYPE : type de composant
- COMPONENT : nom du composant
Un résultat semblable aux lignes suivantes doit s'afficher :
```
NAME       READY  AGE
COMPONENT  1/1    23h
```
Si le composant est opérationnel, la colonne READY du résultat affiche la valeur N/N. Si la colonne READY n'affiche aucune valeur, cela ne signifie pas nécessairement que l'opération a échoué. Le service peut avoir besoin de plus de temps pour traiter la demande.
Vérifiez les pods de chaque composant :
```
kubectl get pods -n obs-system | awk 'NR==1 | /COMPONENT/'
```
Remplacez COMPONENT par le nom du composant.

Un résultat semblable aux lignes suivantes doit s'afficher :
```
NAME       READY  STATUS   RESTARTS  AGE
COMPONENT  1/1    Running  0         23h
```
Vérifiez que la colonne READY affiche la valeur N/N, que la colonne STATUS affiche la valeur Running et que le nombre de RESTARTS ne dépasse pas la valeur 2.

Un nombre élevé de redémarrages indique les symptômes suivants :
- Les pods échouent et Kubernetes les redémarre.
- La colonne STATUS affiche la valeur CrashLoopBackoff.
Pour résoudre l'état d'échec, affichez les journaux des pods.

Si un pod est à l'état PENDING, cela indique un ou plusieurs des symptômes suivants :
- Le pod attend l'accès au réseau pour télécharger le conteneur nécessaire.
- Un problème de configuration empêche le démarrage du pod. Par exemple, une valeur Secret requise par le pod est manquante.
- Votre cluster Kubernetes manque de ressources pour planifier le pod, ce qui se produit si de nombreuses applications sont exécutées sur le cluster.
Déterminez la cause d'un état PENDING :
```
kubectl describe -n obs-system pod/POD_NAME
```
Remplacez POD_NAME par le nom du pod qui affiche l'état PENDING.

Le résultat affiche plus de détails sur le pod.

Accédez à la section Events de la sortie pour afficher un tableau listant les événements récents du pod et un résumé de la cause de l'état PENDING.

La sortie suivante montre un exemple de section Events pour un objet StatefulSet Grafana :

Events:
  Type    Reason            Age                From                    Message
  ----    ------            ----               ----                    -------
  Normal  SuccessfulCreate  13s (x3 over 12d)  statefulset-controller  create Pod grafana-0 in StatefulSet grafana successful

Si aucun événement ne se produit dans votre pod ou dans une autre ressource pendant une période prolongée, le résultat suivant s'affiche :

  Events:         <none>

Vérifier que la pile de journalisation de l'observabilité est en cours d'exécution

Suivez les étapes ci-dessous pour vérifier que la pile de journalisation est en cours d'exécution :

Vérifiez que le side-car Istio est injecté dans toutes les instances ou tous les pods Loki. Vérifiez que tous les pods Fluent Bit nommés anthos-audit-logs-forwarder-SUFFIX et anthos-log-forwarder-SUFFIX ont le side-car Istio injecté.
Vérifiez que toutes les instances Loki s'exécutent sans erreur dans le cluster d'infrastructure de l'organisation.
Vérifiez l'état des objets anthos-audit-logs-forwarder et anthos-log-forwarder DaemonSet pour vous assurer que toutes les instances s'exécutent sur tous les nœuds sans erreur.
Vérifiez que vous obtenez les journaux opérationnels des conteneurs kube-apiserver-SUFFIX et les journaux d'audit du serveur d'API Kubernetes pour les cinq dernières minutes dans tous les clusters. Pour ce faire, exécutez les requêtes suivantes dans l'instance Grafana :
- Journaux opérationnels : sum (count_over_time({service_name="apiserver"} [5m])) by (cluster, fluentbit_pod)
- Journaux d'audit : sum (count_over_time({cluster=~".+"} [5m])) by (cluster, node)
Vous devez obtenir des valeurs non nulles pour tous les nœuds du plan de contrôle dans le cluster d'infrastructure de l'organisation.

Vérifier que la pile de surveillance de l'observabilité est en cours d'exécution

Suivez les étapes ci-dessous pour vérifier que la pile de surveillance est en cours d'exécution :

Vérifiez que les instances Grafana sont en cours d'exécution dans le cluster d'infrastructure de l'organisation. Les pods grafana-0 doivent s'exécuter sans erreur dans les espaces de noms suivants :
- obs-system
- infra-obs-obs-system
- platform-obs-obs-system
Remarque : D'autres espaces de noms PROJECT_NAMESPACE-obs-system peuvent exécuter des instances Grafana. Les instances varient selon le cluster.

Assurez-vous que tous les composants de surveillance se trouvent dans le maillage de services Istio. Suivez les étapes de la section Identifier les échecs de déploiement. Chacun des pods suivants doit indiquer que tous les conteneurs sont prêts dans la colonne READY. Par exemple, une valeur de 3/3 signifie que trois conteneurs sur trois sont prêts. De plus, les pods doivent disposer d'un conteneur istio-proxy. Si les pods ne répondent pas à ces conditions, redémarrez-les :

Nom du pod	Nombre de conteneurs prêts
`cortex-`	`2/2`
`cortex-etcd-0`	`2/2`
`cortex-proxy-server-`	`2/2`
`cortex-tenant-`	`2/2`
`meta-blackbox-exporter-`	`2/2`
`meta-grafana-0`	`3/3`
`meta-grafana-proxy-server-`	`2/2`
`meta-prometheus-0`	`4/4`
`cortex-alertmanager-`	`2/2`
`cortex-compactor-`	`2/2`
`cortex-distributor-`	`2/2`
`cortex-etcd-0`	`2/2`
`cortex-ingester-`	`2/2`
`cortex-querier-`	`2/2`
`cortex-query-frontend-`	`2/2`
`cortex-query-scheduler-`	`2/2`
`cortex-ruler-`	`2/2`
`cortex-store-gateway-`	`2/2`
`cortex-tenant-`	`2/2`
`grafana-proxy-server-`	`2/2`
`meta-blackbox-exporter-`	`2/2`
`meta-grafana-0`	`3/3`
`meta-grafana-proxy-server-*`	`2/2`
`meta-prometheus-0`	`4/4`

Assurez-vous que Cortex s'exécute sans erreur.

Récupérer les journaux Observability

Le tableau suivant contient les commandes que vous devez exécuter pour récupérer les journaux de chacun des composants déployés par la plate-forme Observability.

Composant	Commande de récupération des journaux
`grafana`	`kubectl logs -n obs-system statefulset/grafana`
`anthos-prometheus-k8s`	`kubectl logs -n obs-system statefulset/anthos-prometheus-k8s`
`alertmanager`	`kubectl logs -n obs-system statefulset/alertmanager`
`ops-logs-loki-io`	`kubectl logs -n obs-system statefulset/ops-logs-loki-io`
`ops-logs-loki-io-read`	`kubectl logs -n obs-system statefulset/ops-logs-loki-io-read`
`ops-logs-loki-all`	`kubectl logs -n obs-system statefulset/ops-logs-loki-all`
`ops-logs-loki-all-read`	`kubectl logs -n obs-system statefulset/ops-logs-loki-all-read`
`audit-logs-loki-io`	`kubectl logs -n obs-system statefulset/audit-logs-loki-io`
`audit-logs-loki-io-read`	`kubectl logs -n obs-system statefulset/audit-logs-loki-io-read`
`audit-logs-loki-pa`	`kubectl logs -n obs-system statefulset/audit-logs-loki-pa`
`audit-logs-loki-pa-read`	`kubectl logs -n obs-system statefulset/audit-logs-loki-pa-read`
`audit-logs-loki-all`	`kubectl logs -n obs-system statefulset/audit-logs-loki-all`
`audit-logs-loki-all-read`	`kubectl logs -n obs-system statefulset/audit-logs-loki-all-read`
`anthos-log-forwarder`	`kubectl logs -n obs-system daemonset/anthos-log-forwarder`
`anthos-audit-logs-forwarder`	`kubectl logs -n obs-system daemonset/anthos-audit-logs-forwarder`
`oplogs-forwarder`	`kubectl logs -n obs-system daemonset/oplogs-forwarder`
`logmon-operator`	`kubectl logs -n obs-system deployment/logmon-operator`

Pour afficher les journaux de l'instance précédente d'un composant, ajoutez l'indicateur -p à la fin de chaque commande. L'ajout de l'indicateur -p vous permet d'examiner les journaux d'une instance précédente ayant échoué au lieu de l'instance en cours d'exécution.

Afficher la configuration

La pile d'observabilité utilise des ressources personnalisées de l'API Kubernetes pour configurer les pipelines de surveillance et de journalisation.

La ressource personnalisée LoggingPipeline est déployée dans le cluster d'infrastructure de l'organisation et configure les instances Loki.

Les commandes suivantes affichent les actions disponibles que vous pouvez effectuer sur le pipeline de journalisation :

Affichez la configuration actuelle de votre déploiement de pipeline de journalisation :
```
kubectl get loggingpipeline -n obs-system default -o yaml
```
Modifiez la configuration du déploiement de votre pipeline de journalisation :
```
kubectl edit loggingpipeline -n obs-system default
```

GDC utilise un opérateur de journalisation et de surveillance nommé logmon-operator pour gérer le déploiement des composants d'observabilité tels que Prometheus et Fluent Bit. L'API du composant logmon-operator est la définition de ressource personnalisée logmon. La définition de ressource personnalisée logmon indique à logmon-operator comment configurer l'observabilité pour votre déploiement. Cette définition de ressource personnalisée inclut les propriétés des volumes permettant de stocker vos métriques, les règles d'alerte pour Alertmanager, les configurations Prometheus permettant de collecter les métriques et les configurations Grafana pour les tableaux de bord.

Les commandes suivantes affichent les actions disponibles que vous pouvez effectuer sur la définition de ressource personnalisée logmon :

Affichez la configuration actuelle de votre déploiement Observability :
```
kubectl get logmon -n obs-system logmon-default -o yaml
```
Modifiez la configuration de votre déploiement Observability :
```
kubectl edit logmon -n obs-system logmon-default
```

Le résultat de l'exécution de l'une ou l'autre de ces commandes peut faire référence à plusieurs objets ConfigMap Kubernetes pour une configuration plus poussée. Par exemple, vous pouvez configurer des règles Alertmanager dans un objet ConfigMap distinct, référencé dans la définition de ressource personnalisée logmon par son nom. Vous pouvez modifier et afficher la configuration Alertmanager via la définition de ressource personnalisée logmon nommée gpc-alertmanager-config.

Pour afficher la configuration d'Alertmanager, exécutez la commande suivante :

kubectl get configmap -n obs-system gpc-alertmanager-config -o yaml

Problèmes courants

Cette section présente les problèmes courants que vous pouvez rencontrer lors du déploiement de la plate-forme d'observabilité.

Vous n'avez pas accès à Grafana

Par défaut, Grafana n'est pas exposé aux machines externes à votre cluster Kubernetes. Pour accéder temporairement à l'interface Grafana depuis l'extérieur du cluster d'infrastructure de l'organisation, vous pouvez transférer le port Service vers localhost. Pour transférer le port Service, exécutez la commande suivante :

kubectl port-forward -n gpc-system service/grafana 33000\:3000

Dans votre navigateur Web, accédez à http://localhost:33000 pour afficher le tableau de bord Grafana de votre déploiement. Pour mettre fin au processus, appuyez sur les touches Ctrl+C.

Grafana fonctionne lentement

Si Grafana fonctionne lentement, cela signifie :

Les requêtes envoyées à Prometheus ou Loki renvoient trop de données.
Les requêtes renvoient plus de données qu'il n'est raisonnable d'afficher sur un seul graphique.

Pour résoudre les problèmes de lenteur dans Grafana, vérifiez les requêtes dans vos tableaux de bord Grafana personnalisés. Si les requêtes renvoient plus de données qu'il n'est raisonnable d'afficher sur un seul graphique, envisagez de réduire la quantité de données affichées pour améliorer les performances du tableau de bord.

Le tableau de bord Grafana n'affiche aucune métrique ni aucun journal

Si Grafana n'affiche aucune métrique ni aucun journal, cela peut être dû aux raisons suivantes :

Les sources de données Grafana ne sont pas correctement définies.
Le système présente des problèmes de connectivité avec les sources de données de surveillance ou de journalisation.
Le système ne collecte pas de métriques ni de journaux.

Pour afficher les journaux et les métriques, procédez comme suit :

Dans l'interface utilisateur Grafana, cliquez sur Paramètres du tableau de bord.
Sélectionnez Sources de données.
Sur la page Sources de données, assurez-vous que les sources suivantes s'affichent :

Nom	Organisation	URL
`Audit Logs`	`All`	`http://audit-logs-loki-io-read.obs-system.svc:3100`
`Operational Logs`	`Root`	`http://ops-logs-loki-io-read.obs-system.svc:3100`
`Operational Logs`	`Org`	`http://ops-logs-loki-all-read.obs-system.svc:3100`
`prometheus`		`http://anthos-prometheus-k8s.obs-system.svc:9090`

Si ces sources de données sont manquantes, cela signifie que la pile Observability n'a pas réussi à configurer correctement Grafana.

Si vous avez correctement configuré les sources de données, mais qu'aucune donnée ne s'affiche, cela peut indiquer un problème avec les objets Service qui collectent des métriques ou des journaux pour alimenter Prometheus ou Loki.

Lorsque Prometheus collecte des métriques, il suit un modèle pull pour interroger périodiquement vos objets Service afin d'obtenir des métriques et stocker les valeurs trouvées. Pour que Prometheus puisse découvrir vos objets Service pour la collecte de métriques, les conditions suivantes doivent être remplies :

Tous les pods des objets Service sont annotés avec 'monitoring.gke.io/scrape: "true"'.

Remarque : Si votre service est un déploiement ou un objet StatefulSet, ajoutez l'annotation au service pour que Kubernetes la propage à vos pods.
Le format de métrique Prometheus expose les métriques de pod via HTTP. Par défaut, Prometheus recherche ces métriques au point de terminaison http://POD_NAME:80/metrics. Si nécessaire, vous pouvez remplacer le port, le point de terminaison et le schéma à l'aide d'annotations.

Fluent Bit collecte les journaux et est conçu pour s'exécuter sur chaque nœud de vos clusters Kubernetes. Fluent Bit envoie les journaux à Loki pour un stockage à long terme.

Si aucun journal n'est présent dans Grafana, essayez les solutions de contournement suivantes :

Vérifiez les journaux des instances Loki pour vous assurer qu'elles s'exécutent sans erreur.
Si les instances Loki s'exécutent correctement, mais que les journaux n'apparaissent pas, vérifiez les journaux dans Fluent Bit pour vous assurer que le service fonctionne comme prévu. Pour savoir comment extraire les journaux, consultez Récupérer les journaux Observability.

Alertmanager n'ouvre pas les alertes

Si Alertmanager ne parvient pas à ouvrir les alertes, suivez les étapes ci-dessous :

Dans votre objet configMap au sein de l'espace de noms gpc-system, assurez-vous que le libellé logmon: system_metrics existe.
Vérifiez que la section de données configMap inclut une clé nommée alertmanager.yml. La valeur de la clé alertmanager.yml doit correspondre aux règles d'alerte contenues dans votre fichier de configuration Alertmanager valide.
Assurez-vous que la définition de ressource personnalisée logmon nommée logmon-default dans l'espace de noms gpc-system contient une référence à l'objet configMap. La définition de ressource personnalisée logmon-default doit contenir le nom de l'objet configMap, comme indiqué dans l'exemple suivant :
```
apiVersion: addons.gke.io/v1
kind: Logmon
spec:
  system_metrics:
    outputs:
      default_prometheus:
        deployment:
          components:
            alertmanager:
              alertmanagerConfigurationConfigmaps:
                - alerts-config
```
La valeur alerts-config dans l'exemple correspond au nom de votre objet configMap.

Alertmanager n'envoie pas d'alertes aux canaux de notification configurés

Une erreur de configuration peut vous empêcher de recevoir des notifications dans le logiciel externe que vous avez configuré comme canal de notification (Slack, par exemple), même si Alertmanager génère des alertes dans l'instance Grafana.

Pour recevoir des alertes dans votre logiciel externe, procédez comme suit :

Vérifiez que les valeurs de votre fichier de configuration Alertmanager sont correctement mises en forme. Lorsque Alertmanager déclenche une alerte, il interroge un webhook sur le logiciel externe.
Assurez-vous que les URL de webhook qui se connectent au logiciel externe sont correctes. Si les URL sont correctes, assurez-vous que le logiciel est configuré pour accepter les webhooks. Vous devrez peut-être générer une clé API pour accéder à l'API du service externe, ou votre clé API actuelle peut avoir expiré et vous devez la renouveler.
Si le service externe se trouve en dehors de votre déploiement d'appliance GDC isolée, assurez-vous que les règles de sortie de votre cluster d'infrastructure d'organisation sont configurées. Cette configuration permet à Alertmanager d'envoyer des requêtes à un service en dehors du réseau Kubernetes interne. Si vous ne validez pas les règles de sortie, Alertmanager risque de ne pas trouver le logiciel externe.

Vous ne pouvez pas voir les métriques de votre charge de travail à portée de projet

Suivez les étapes ci-dessous pour appliquer une solution de contournement et obtenir des métriques à partir de votre charge de travail :

Assurez-vous que la ressource personnalisée MonitoringTarget est à l'état Ready.
Pour scraper votre charge de travail, vous devez déclarer toutes les informations cibles spécifiées dans MonitoringTarget dans la spécification de pod des charges de travail. Par exemple, si vous déclarez que les métriques sont disponibles sur le port 8080, le pod de charge de travail doit déclarer à Kubernetes que le port 8080 est ouvert. Sinon, Prometheus ignore la charge de travail.
Prometheus exécute plusieurs partitions, ce qui signifie que tous les pods Prometheus ne sont pas censés extraire votre pod. Vous pouvez identifier le numéro de partition dans le nom de chaque pod Prometheus. Par exemple, primary-prometheus-shard0-replica0-0 fait partie du shard 0. Recherchez le pod à partir duquel vous souhaitez extraire des données dans chaque shard Prometheus :
1. Transférez le port du pod primary-prometheus-shardSHARD_NUMBER-replica0-0 de Prometheus dans l'espace de noms obs-system pour accéder à l'interface utilisateur de Prometheus. Remplacez SHARD_NUMBER dans le nom du pod par des nombres croissants chaque fois que vous vérifiez un nouveau shard.
2. Accédez à l'interface utilisateur Prometheus dans votre navigateur Web et suivez ces étapes :
  1. Cliquez sur État > Cibles.
  2. Assurez-vous que le pod que vous souhaitez extraire figure dans la liste. Si ce n'est pas le cas, vérifiez le prochain fragment. S'il n'y a plus de partitions à vérifier, revalidez que Prometheus dispose de suffisamment d'informations pour les découvrir.
3. Vérifiez que le pod primary-prometheus-shardSHARD_NUMBER-replica0-0 de Prometheus enregistre des erreurs dans l'espace de noms obs-system.
Vérifiez les erreurs dans les journaux des pods cortex-tenant dans l'espace de noms obs-system.

Aucun tableau de bord n'a été créé

Suivez les étapes ci-dessous pour appliquer une solution de contournement et découvrir pourquoi un tableau de bord n'a pas été créé :

Vérifiez l'état de la ressource personnalisée Dashboard pour détecter d'éventuelles erreurs. La ressource personnalisée doit avoir un état Ready.
Assurez-vous de vérifier la bonne instance Grafana. Par exemple, si vous avez déployé le tableau de bord dans l'espace de noms de votre projet nommé my-namespace, il doit se trouver dans l'instance Grafana au point de terminaison https://GDCH_URL/my-namespace/grafana.
Vérifiez les journaux de fleet-admin-controller dans l'espace de noms gpc-system. Recherchez les erreurs liées au tableau de bord en saisissant son nom dans les journaux. Si vous trouvez des erreurs, cela signifie que le fichier JSON de votre objet configMap n'est pas au bon format. Vous devez le corriger.
Consultez les journaux Grafana dans l'espace de noms PROJECT_NAME-obs-system pour rechercher d'éventuelles erreurs. Les tableaux de bord interrogent l'API REST Grafana. Par conséquent, Grafana doit fonctionner pour qu'un tableau de bord puisse être créé.

Votre alerte ne s'ouvre pas

Suivez les étapes ci-dessous pour appliquer une solution de contournement et découvrir pourquoi une alerte ne s'ouvre pas :

Assurez-vous que Cortex et Loki sont tous deux en mode de stockage dans un bucket. Les règles ne fonctionnent que si le backend est associé à un stockage de bucket.
Vérifiez que l'état des ressources personnalisées MonitoringRule et LoggingRule est Ready.
Vérifiez les conditions d'alerte suivantes :
- Expressions PromQL et LogQL : comparez toutes les fonctions que vous utilisez à la documentation Créer des règles d'alerte pour vous assurer que vos règles sont configurées comme vous le souhaitez. Assurez-vous que les expressions renvoient une valeur true ou false.
- Durée : le champ for de la ressource personnalisée définit la durée pendant laquelle une condition doit être vraie. Le champ interval définit la fréquence d'évaluation de la condition. Vérifiez les valeurs de ces champs les unes par rapport aux autres et assurez-vous que vos conditions sont logiques.
Consultez l'interface utilisateur Grafana pour voir si l'alerte est ouverte sur la page Alerts (Alertes).
Si Grafana indique que l'alerte est ouverte, vérifiez vos canaux de notification et assurez-vous qu'Alertmanager peut les contacter pour générer l'alerte.

Les journaux attendus ne sont pas disponibles

Si vous ne voyez pas les journaux opérationnels de votre composant, suivez les étapes ci-dessous :

Vérifiez si votre composant est en cours d'exécution et s'il génère des journaux.
Vérifiez si les journaux de vos composants doivent être collectés en tant que fonctionnalité intégrée. Si ce n'est pas le cas, assurez-vous que la ressource personnalisée LoggingTarget est déployée avec une spécification valide et avec un état Ready.

Suivez les étapes ci-dessous si vous ne voyez pas les journaux d'audit de votre composant :

Si votre composant écrit des journaux dans un fichier, assurez-vous que le fichier existe réellement dans le système de fichiers du nœud sur le chemin d'accès /var/log/audit/SERVICE_NAME/NAMESPACE/ACCESS_LEVEL/audit.log.
Vérifiez que le pod anthos-audit-logs-forwarder-SUFFIX sur le même nœud ne comporte aucune erreur.
Si votre composant utilise un point de terminaison syslog pour recevoir les journaux, assurez-vous que la ressource personnalisée AuditLoggingTarget est déployée avec une spécification valide et avec un état Ready.

Identifier les règles d'alerte prédéfinies

Cette section contient des informations sur les règles d'alerte prédéfinies qui existent dans les composants d'observabilité pour vous avertir des défaillances du système.

Règles d'alerte prédéfinies dans Loki

Le tableau suivant fournit les règles d'alerte préinstallées dans Loki pour les échecs de journalisation d'audit :

Règles d'alerte préinstallées dans Loki pour les échecs de journalisation d'audit
Nom	Type	Description
`FluentBitAuditLoggingWriteFailure`	Critique	Fluent Bit n'a pas réussi à transférer les journaux d'audit au cours des cinq dernières minutes.
`LokiAuditLoggingWriteFailure`	Critique	Loki n'a pas réussi à écrire les journaux d'audit dans le stockage backend.

Lorsqu'une ou plusieurs de ces alertes s'affichent, cela signifie que le système a perdu au moins un enregistrement d'audit.

Règles d'alerte prédéfinies dans Prometheus

Le tableau suivant fournit les règles d'alerte préinstallées dans Prometheus pour les composants Kubernetes :

Règles d'alerte préinstallées dans Prometheus
Nom	Type	Description
`KubeAPIDown`	Critique	L'API Kube a disparu de la découverte de cibles 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 du client du serveur d'API Kubernetes est supérieur à 0,1 depuis 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	L'espace libre en octets d'un objet `PersistentVolume` revendiqué est inférieur à 0,03.
`KubePersistentVolumeFillingUp`	Avertissement	L'espace libre en octets d'un objet `PersistentVolume` revendiqué est inférieur à 0,15.
`KubePersistentVolumeErrors`	Critique	Le volume persistant est en phase `Failed` ou `Pending` depuis cinq minutes.
`KubeNodeNotReady`	Avertissement	Le nœud n'est pas opérationnel depuis 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	Vous avez atteint une limite de débit lors de la création ou du renouvellement de certificats pendant cinq minutes.
`DeploymentNotReady`	Critique	Un déploiement sur le cluster d'infrastructure de l'organisation est en état non opérationnel depuis plus de 15 minutes.
`StatefulSetNotReady`	Critique	Un objet `StatefulSet` sur le cluster d'infrastructure de l'organisation est en état non opérationnel depuis plus de 15 minutes.
`AuditLogsForwarderDown`	Critique	Le DaemonSet `anthos-audit-logs-forwarder` est hors service depuis plus de 15 minutes.
`AuditLogsLokiDown`	Critique	Le StatefulSet `audit-logs-loki` est en état non opérationnel depuis plus de 15 minutes.