Questa pagina è stata tradotta dall'API Cloud Translation.

Risoluzione dei problemi di osservabilità

Questo documento descrive come identificare gli errori di deployment e gli incidenti operativi che potresti riscontrare nell'appliance air-gap di Google Distributed Cloud (GDC) e contiene descrizioni di tutti gli avvisi visualizzati nel sistema per aiutarti a risolvere i problemi comuni con i componenti di logging e monitoraggio.

Identificare i componenti di Observability

La piattaforma di osservabilità esegue il deployment dei suoi componenti nello spazio dei nomi obs-system nel cluster dell'infrastruttura dell'organizzazione.

L'istanza Grafana dell'operatore dell'infrastruttura (IO) fornisce l'accesso alle metriche a livello di organizzazione per monitorare i componenti dell'infrastruttura, come l'utilizzo della CPU e il consumo di spazio di archiviazione. Fornisce inoltre l'accesso ai log operativi e di controllo. Inoltre, consente l'accesso ad avvisi, log e metriche dei componenti operabili di GDC.

Gli stack di monitoraggio e logging di GDC utilizzano soluzioni open source come parte della piattaforma di osservabilità. Questi componenti raccolgono log e metriche da pod Kubernetes, macchine bare metal, switch di rete, spazio di archiviazione e servizi gestiti.

La tabella seguente contiene una descrizione di tutti i componenti che integrano la piattaforma di osservabilità:

Componente	Descrizione
`Prometheus`	Prometheus è un database di serie temporali per la raccolta e l'archiviazione di metriche e la valutazione degli avvisi. Prometheus archivia le metriche nell'istanza Cortex del cluster di infrastruttura dell'organizzazione per l'archiviazione a lungo termine. Prometheus aggiunge etichette come coppie chiave-valore e raccoglie metriche da nodi Kubernetes, pod, macchine bare metal, switch di rete e appliance di archiviazione.
`Alertmanager`	Alertmanager è un sistema di gestione definito dall'utente che invia avvisi quando i log o le metriche indicano che i componenti di sistema non funzionano o non operano normalmente. Gestisce il routing, la disattivazione e l'aggregazione degli avvisi di Prometheus.
`Loki`	Loki è un database di serie temporali che archivia e aggrega i log provenienti da varie origini. Indicizza i log per eseguire query in modo efficiente.
`Grafana`	Grafana fornisce un'interfaccia utente per visualizzare le metriche raccolte da Prometheus ed eseguire query sui log di controllo e operativi dalle istanze Loki corrispondenti. L'interfaccia utente ti consente di visualizzare le dashboard di metriche e avvisi.
`Fluent Bit`	Fluent Bit è un processore che estrae i log da vari componenti o posizioni e li invia a Loki. Viene eseguito su ogni nodo di tutti i cluster.

Identificare gli errori di deployment

Se il deployment è in esecuzione e integro, i componenti vengono eseguiti nello stato READY.

Segui questi passaggi per identificare gli errori di deployment:

Conferma lo stato attuale di un componente:
```
kubectl get -n obs-system TYPE/COMPONENT
```
Sostituisci quanto segue:
- TYPE: il tipo di componente
- COMPONENT: il nome del componente
Viene restituito un output simile al seguente:
```
NAME       READY  AGE
COMPONENT  1/1    23h
```
Se il componente è integro, la colonna READY dell'output mostra N/N come valore. Se la colonna READY non mostra un valore, non indica necessariamente un errore. Il servizio potrebbe richiedere più tempo per l'elaborazione.
Controlla i pod in ogni componente:
```
kubectl get pods -n obs-system | awk 'NR==1 | /COMPONENT/'
```
Sostituisci COMPONENT con il nome del componente.

Viene restituito un output simile al seguente:
```
NAME       READY  STATUS   RESTARTS  AGE
COMPONENT  1/1    Running  0         23h
```
Verifica che la colonna READY mostri N/N come valore, che la colonna STATUS mostri un valore Running e che il numero di RESTARTS non superi il valore 2.

Un numero elevato di riavvii indica i seguenti sintomi:
- I pod non vanno a buon fine e Kubernetes li riavvia.
- La colonna STATUS mostra il valore CrashLoopBackoff.
Per risolvere lo stato di errore, visualizza i log dei pod.

Se un pod si trova nello stato PENDING, questo stato indica uno o più dei seguenti sintomi:
- Il pod è in attesa dell'accesso alla rete per scaricare il container necessario.
- Un problema di configurazione impedisce l'avvio del pod. Ad esempio, manca un valore Secret richiesto dal pod.
- Il cluster Kubernetes ha esaurito le risorse per pianificare il pod, il che si verifica se nel cluster sono in esecuzione molte applicazioni.
Determinare la causa di uno stato PENDING:
```
kubectl describe -n obs-system pod/POD_NAME
```
Sostituisci POD_NAME con il nome del pod che mostra lo stato PENDING.

L'output mostra ulteriori dettagli sul pod.

Vai alla sezione Events dell'output per visualizzare una tabella che elenca gli eventi recenti del pod e un riepilogo della causa dello stato PENDING.

L'output seguente mostra una sezione Events di esempio per un oggetto StatefulSet di Grafana:

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

Se non ci sono eventi nel pod o in qualsiasi altra risorsa per un periodo di tempo prolungato, viene visualizzato il seguente output:

  Events:         <none>

Controlla che lo stack di logging di Observability sia in esecuzione

Segui questi passaggi per verificare che lo stack di logging sia in esecuzione:

Verifica che tutte le istanze o i pod Loki abbiano il sidecar Istio inserito. Verifica che tutti i pod Fluent Bit denominati anthos-audit-logs-forwarder-SUFFIX e anthos-log-forwarder-SUFFIX abbiano il sidecar Istio inserito.
Verifica che tutte le istanze Loki siano in esecuzione senza errori nel cluster dell'infrastruttura dell'organizzazione.
Controlla lo stato degli oggetti anthos-audit-logs-forwarder e anthos-log-forwarder DaemonSet per verificare che tutte le istanze siano in esecuzione in tutti i nodi senza errori.
Verifica di ricevere i log operativi dai container kube-apiserver-SUFFIX e gli audit log dal server API Kubernetes degli ultimi cinque minuti in tutti i cluster. Per farlo, esegui le seguenti query nell'istanza Grafana:
- Log operativi: sum (count_over_time({service_name="apiserver"} [5m])) by (cluster, fluentbit_pod)
- Audit log: sum (count_over_time({cluster=~".+"} [5m])) by (cluster, node)
Devi ottenere valori diversi da zero per tutti i nodi del control plane nel cluster di infrastruttura dell'organizzazione.

Verifica che lo stack di monitoraggio dell'osservabilità sia in esecuzione

Segui questi passaggi per verificare che lo stack di monitoraggio sia in esecuzione:

Controlla che le istanze Grafana siano in esecuzione nel cluster dell'infrastruttura dell'organizzazione. I pod grafana-0 devono essere eseguiti senza errori nei seguenti spazi dei nomi:
- obs-system
- infra-obs-obs-system
- platform-obs-obs-system
Nota: altri spazi dei nomi PROJECT_NAMESPACE-obs-system potrebbero eseguire istanze Grafana. Le istanze variano in base al cluster.

Assicurati che tutti i componenti di monitoraggio si trovino nel service mesh Istio. Segui i passaggi della sezione Identificare gli errori di deployment. Ciascuno dei seguenti pod deve mostrare che tutti i container sono pronti nella colonna READY. Ad esempio, un valore 3/3 indica che tre container su tre sono pronti. Inoltre, i pod devono avere un container istio-proxy. Se i pod non soddisfano queste condizioni, riavviali:

Nome pod	Numero di container pronti
`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`

Assicurati che Cortex sia in esecuzione senza errori.

Recuperare i log di Observability

La tabella seguente contiene i comandi che devi eseguire per recuperare i log di ciascuno dei componenti distribuiti dalla piattaforma di osservabilità.

Componente	Comando di recupero dei log
`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`

Per visualizzare i log dell'istanza precedente di un componente, aggiungi il flag -p alla fine di ogni comando. L'aggiunta del flag -p ti consente di esaminare i log di un'istanza precedente non riuscita anziché l'istanza in esecuzione corrente.

Visualizzare la configurazione

Lo stack di osservabilità utilizza risorse personalizzate dell'API Kubernetes per configurare le pipeline di monitoraggio e logging.

La risorsa personalizzata LoggingPipeline viene implementata nel cluster dell'infrastruttura dell'organizzazione e configura le istanze Loki.

I seguenti comandi mostrano le azioni disponibili che puoi eseguire sulla pipeline di logging:

Visualizza la configurazione attuale del deployment della pipeline di logging:
```
kubectl get loggingpipeline -n obs-system default -o yaml
```
Modifica la configurazione del deployment della pipeline di logging:
```
kubectl edit loggingpipeline -n obs-system default
```

GDC utilizza un operatore di logging e monitoraggio denominato logmon-operator per gestire il deployment di componenti di osservabilità come Prometheus e Fluent Bit. L'API del componente logmon-operator è la definizione di risorsa personalizzata logmon. La definizione di risorsa personalizzata logmon indica a logmon-operator come configurare l'osservabilità per il deployment. Questa definizione di risorsa personalizzata include le proprietà dei volumi per archiviare le metriche, le regole di avviso per Alertmanager, le configurazioni di Prometheus per raccogliere le metriche e le configurazioni di Grafana per le dashboard.

I seguenti comandi mostrano le azioni disponibili che puoi eseguire sulla definizione di risorsa personalizzata logmon:

Visualizza la configurazione attuale del deployment di Observability:
```
kubectl get logmon -n obs-system logmon-default -o yaml
```
Modifica la configurazione del deployment di Observability:
```
kubectl edit logmon -n obs-system logmon-default
```

L'output dell'esecuzione di uno dei due comandi potrebbe fare riferimento a più oggetti Kubernetes ConfigMap per un'ulteriore configurazione. Ad esempio, puoi configurare le regole di Alertmanager in un oggetto ConfigMap separato, a cui viene fatto riferimento nella definizione di risorsa personalizzata logmon in base al nome. Puoi modificare e visualizzare la configurazione di Alertmanager tramite la definizione di risorsa personalizzata logmon denominata gpc-alertmanager-config.

Per visualizzare la configurazione di Alertmanager, esegui:

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

Problemi comuni

Questa sezione contiene i problemi comuni che potresti riscontrare durante il deployment della piattaforma di osservabilità.

Non puoi accedere a Grafana

Per impostazione predefinita, Grafana non è esposto a macchine esterne al cluster Kubernetes. Per accedere temporaneamente all'interfaccia Grafana dall'esterno del cluster di infrastruttura dell'organizzazione, puoi eseguire il port forwarding di Service su localhost. Per inoltrare la porta Service, esegui:

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

Nel browser web, vai a http://localhost:33000 per visualizzare la dashboard Grafana per il tuo deployment. Per terminare la procedura, premi i tasti Ctrl+C.

Grafana funziona lentamente

L'esecuzione lenta di Grafana indica quanto segue:

Le query a Prometheus o Loki restituiscono una quantità eccessiva di dati.
Le query restituiscono più dati di quelli che è ragionevole visualizzare in un singolo grafico.

Per risolvere i problemi di lentezza in Grafana, controlla le query nei tuoi pannelli personalizzati di Grafana. Se le query restituiscono più dati di quanto sia ragionevole visualizzare in un singolo grafico, valuta la possibilità di ridurre la quantità di dati mostrati per migliorare le prestazioni del dashboard.

La dashboard di Grafana non mostra metriche o log

Se Grafana non mostra metriche o log, i motivi potrebbero essere i seguenti:

Le origini dati di Grafana non sono impostate correttamente.
Il sistema presenta problemi di connettività con le origini dati di monitoraggio o di logging.
Il sistema non raccoglie metriche o log.

Per visualizzare i log e le metriche:

Nell'interfaccia utente di Grafana, fai clic su Impostazioni dashboard.
Seleziona Origini dati.
Nella pagina Origini dati, assicurati di visualizzare le seguenti origini:

Nome	Organizzazione	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`

La mancanza di queste origini dati indica che lo stack di osservabilità non è riuscito a configurare Grafana correttamente.

Se hai configurato correttamente le origini dati, ma non vengono visualizzati dati, questo potrebbe indicare un problema con gli oggetti Service che raccolgono metriche o log da inserire in Prometheus o Loki.

Man mano che Prometheus raccoglie le metriche, segue un modello pull per eseguire periodicamente query sui tuoi oggetti Service per le metriche e memorizzare i valori trovati. Affinché Prometheus possa rilevare gli oggetti Service per la raccolta delle metriche, devono essere soddisfatte le seguenti condizioni:

Tutti i pod per gli oggetti Service sono annotati con 'monitoring.gke.io/scrape: "true"'.

Nota :se il tuo servizio è un deployment o un oggetto StatefulSet, aggiungi l'annotazione al servizio per consentire a Kubernetes di propagarla ai tuoi pod.
Il formato delle metriche Prometheus espone le metriche dei pod tramite HTTP. Per impostazione predefinita, Prometheus cerca queste metriche nell'endpoint http://POD_NAME:80/metrics. Se necessario, puoi ignorare la porta, l'endpoint e lo schema tramite le annotazioni.

Fluent Bit raccoglie i log ed è progettato per essere eseguito su ogni nodo dei cluster Kubernetes. Fluent Bit invia i log a Loki per l'archiviazione a lungo termine.

Se non sono presenti log in Grafana, prova le seguenti soluzioni alternative:

Controlla i log delle istanze Loki per assicurarti che vengano eseguite senza errori.
Se le istanze Loki sono in esecuzione correttamente, ma i log non vengono visualizzati, controlla i log in Fluent Bit per assicurarti che il servizio funzioni come previsto. Per scoprire come estrarre i log, consulta Recuperare i log di Observability.

Alertmanager non apre avvisi

Se Alertmanager non riesce ad aprire gli avvisi, segui questi passaggi:

Nell'oggetto configMap all'interno dello spazio dei nomi gpc-system, assicurati che esista l'etichetta logmon: system_metrics.
Verifica che la sezione dei dati configMap includa una chiave denominata alertmanager.yml. Il valore della chiave alertmanager.yml deve essere le regole di avviso contenute nel file di configurazione Alertmanager valido.
Assicurati che la definizione di risorsa personalizzata logmon denominata logmon-default nello spazio dei nomi gpc-system contenga un riferimento all'oggetto configMap. La definizione di risorsa personalizzata logmon-default deve contenere il nome dell'oggetto configMap, come mostrato nell'esempio seguente:
```
apiVersion: addons.gke.io/v1
kind: Logmon
spec:
  system_metrics:
    outputs:
      default_prometheus:
        deployment:
          components:
            alertmanager:
              alertmanagerConfigurationConfigmaps:
                - alerts-config
```
Il valore alerts-config nell'esempio è il nome dell'oggetto configMap.

Alertmanager non invia avvisi ai canali di notifica configurati

Un errore di configurazione potrebbe impedirti di ricevere notifiche nel software esterno che hai configurato come canale di notifica, ad esempio Slack, anche se Alertmanager genera avvisi nell'istanza Grafana.

Per ricevere avvisi nel tuo software esterno:

Verifica che i valori nel file di configurazione di Alertmanager siano formattati correttamente. Quando Alertmanager attiva un avviso, esegue una query su un webhook nel software esterno.
Assicurati che gli URL webhook che si connettono al software esterno siano corretti. Se gli URL sono corretti, assicurati che il software sia configurato per accettare i webhook. Potresti dover generare una chiave API per accedere all'API del servizio esterno oppure la tua chiave API attuale potrebbe essere scaduta e devi aggiornarla.
Se il servizio esterno si trova al di fuori del deployment dell'appliance GDC air-gap, assicurati che il cluster dell'infrastruttura dell'organizzazione abbia configurato le regole di uscita. Questa configurazione consente ad Alertmanager di inviare richieste a un servizio al di fuori della rete Kubernetes interna. La mancata verifica delle regole di uscita potrebbe impedire ad Alertmanager di trovare il software esterno.

Non puoi visualizzare le metriche del tuo workload con ambito progetto

Segui i passaggi riportati di seguito per applicare una soluzione alternativa e ottenere le metriche dal tuo workload:

Assicurati che la risorsa personalizzata MonitoringTarget abbia lo stato Ready.
Per eseguire lo scraping del workload, devi dichiarare tutte le informazioni di destinazione specificate per MonitoringTarget nella specifica del pod dei workload. Ad esempio, se dichiari che le metriche sono disponibili sulla porta 8080, il pod del workload deve dichiarare a Kubernetes che la porta 8080 è aperta. In caso contrario, Prometheus ignora il carico di lavoro.
Prometheus esegue più shard, il che significa che non tutti i pod Prometheus devono eseguire lo scraping del tuo pod. Puoi identificare il numero di shard nel nome di ogni pod Prometheus. Ad esempio, primary-prometheus-shard0-replica0-0 fa parte dello shard 0. Controlla il pod da cui vuoi eseguire lo scraping da ogni shard Prometheus:
1. Inoltra la porta del pod primary-prometheus-shardSHARD_NUMBER-replica0-0 di Prometheus nello spazio dei nomi obs-system per accedere alla UI di Prometheus. Sostituisci SHARD_NUMBER nel nome del pod con numeri crescenti ogni volta che controlli un nuovo shard.
2. Vai all'interfaccia utente di Prometheus nel browser web e segui questi passaggi:
  1. Fai clic su Stato > Target.
  2. Assicurati che il pod che vuoi estrarre sia presente nell'elenco. In caso contrario, controlla il successivo shard. Se non ci sono altri shard da controllare, verifica nuovamente che Prometheus disponga di informazioni sufficienti per rilevarlo.
3. Verifica che il pod primary-prometheus-shardSHARD_NUMBER-replica0-0 di Prometheus registri errori nello spazio dei nomi obs-system.
Verifica gli errori nei log del pod cortex-tenant nello spazio dei nomi obs-system.

Non è stata creata una dashboard

Segui questi passaggi per applicare una soluzione alternativa e scoprire perché una dashboard non viene creata:

Esamina lo stato della risorsa personalizzata Dashboard per verificare la presenza di errori. La risorsa personalizzata deve avere lo stato Ready.
Assicurati di controllare l'istanza Grafana corretta. Ad esempio, se hai eseguito il deployment della dashboard nello spazio dei nomi del progetto denominato my-namespace, la dashboard deve trovarsi nell'istanza Grafana all'endpoint https://GDCH_URL/my-namespace/grafana.
Controlla i log di fleet-admin-controller nello spazio dei nomi gpc-system. Cerca eventuali errori relativi alla dashboard cercando il nome della dashboard nei log. Se trovi errori, il file JSON nell'oggetto configMap ha un formato errato e devi correggerlo.
Controlla i log di Grafana nello spazio dei nomi PROJECT_NAME-obs-system per verificare la presenza di errori. Le dashboard eseguono query sull'API REST di Grafana, quindi Grafana deve funzionare per poter creare una dashboard.

L'avviso non si apre

Segui questi passaggi per applicare una soluzione alternativa e scoprire perché un avviso non si apre:

Assicurati che Cortex e Loki siano entrambi in modalità di archiviazione nel bucket. Le regole non funzionano a meno che il backend non sia supportato dall'archiviazione bucket.
Verifica che lo stato delle risorse personalizzate MonitoringRule e LoggingRule sia Ready.
Controlla le seguenti condizioni di avviso:
- Espressioni PromQL e LogQL: confronta tutte le funzioni che utilizzi con la documentazione Creare regole di avviso per assicurarti che le regole siano configurate come desideri. Assicurati che le espressioni restituiscano un valore true o false.
- Durata: il campo for della risorsa personalizzata definisce per quanto tempo una condizione deve essere vera. Il campo interval definisce la frequenza di valutazione della condizione. Controlla i valori di questi campi e assicurati che le condizioni siano logiche.
Controlla l'interfaccia utente di Grafana per vedere se l'avviso è aperto utilizzando la pagina Avvisi.
Se Grafana mostra che l'avviso è aperto, controlla i canali di notifica e assicurati che Alertmanager possa contattarli per generare l'avviso.

I log previsti non sono disponibili

Segui i passaggi riportati di seguito se non vedi i log operativi del componente:

Controlla se il componente è in esecuzione e produce log.
Verifica se i log dei componenti devono essere raccolti come funzionalità integrata. In caso contrario, assicurati di aver eseguito il deployment della risorsa personalizzata LoggingTarget con una specifica valida e con uno stato Ready.

Se non vedi audit log del tuo componente, segui questi passaggi:

Se il componente scrive i log in un file, assicurati che il file esista effettivamente nel file system del nodo nel percorso /var/log/audit/SERVICE_NAME/NAMESPACE/ACCESS_LEVEL/audit.log.
Verifica che il pod anthos-audit-logs-forwarder-SUFFIX sullo stesso nodo non contenga errori.
Se il tuo componente utilizza un endpoint syslog per ricevere i log, assicurati di aver eseguito il deployment della risorsa personalizzata AuditLoggingTarget con una specifica valida e con uno stato Ready.

Identificare le regole di avviso predefinite

Questa sezione contiene informazioni sulle regole di avviso predefinite esistenti nei componenti di osservabilità per avvisarti in caso di errori di sistema.

Regole di avviso predefinite in Loki

La tabella seguente fornisce le regole di avviso preinstallate in Loki per gli errori di logging di controllo:

Regole di avviso preinstallate in Loki per gli errori di audit logging
Nome	Tipo	Descrizione
`FluentBitAuditLoggingWriteFailure`	Critico	Fluent Bit non è riuscito a inoltrare i log di controllo negli ultimi cinque minuti.
`LokiAuditLoggingWriteFailure`	Critico	Loki non è riuscito a scrivere i log di controllo nell'archivio di backend.

Quando viene visualizzato uno o più di questi avvisi, il sistema ha perso almeno un record di controllo.

Regole di avviso predefinite in Prometheus

La seguente tabella fornisce le regole di avviso preinstallate in Prometheus per i componenti Kubernetes:

Regole di avviso preinstallate in Prometheus
Nome	Tipo	Descrizione
`KubeAPIDown`	Critico	L'API Kube è scomparsa dal rilevamento dei target Prometheus per 15 minuti.
`KubeClientErrors`	Avviso	Il rapporto di errori del client del server API Kubernetes è superiore a 0,01 da 15 minuti.
`KubeClientErrors`	Critico	Il rapporto di errori del client del server API Kubernetes è superiore a 0,1 da 15 minuti.
`KubePodCrashLooping`	Avviso	Il pod è in uno stato di crash loop da più di 15 minuti.
`KubePodNotReady`	Avviso	Il pod è in stato non pronto da più di 15 minuti.
`KubePersistentVolumeFillingUp`	Critico	I byte gratuiti di un oggetto `PersistentVolume` rivendicato sono inferiori a 0,03.
`KubePersistentVolumeFillingUp`	Avviso	I byte gratuiti di un oggetto `PersistentVolume` rivendicato sono inferiori a 0,15.
`KubePersistentVolumeErrors`	Critico	Il volume permanente è in fase `Failed` o `Pending` da cinque minuti.
`KubeNodeNotReady`	Avviso	Il nodo non è pronto da più di 15 minuti.
`KubeNodeCPUUsageHigh`	Critico	L'utilizzo della CPU del nodo è superiore all'80%.
`KubeNodeMemoryUsageHigh`	Critico	L'utilizzo della memoria del nodo è superiore all'80%.
`NodeFilesystemSpaceFillingUp`	Avviso	L'utilizzo del file system del nodo è superiore al 60%.
`NodeFilesystemSpaceFillingUp`	Critico	L'utilizzo del file system del nodo è superiore all'85%.
`CertManagerCertExpirySoon`	Avviso	Un certificato scade tra 21 giorni.
`CertManagerCertNotReady`	Critico	Un certificato non è pronto per gestire il traffico dopo 10 minuti.
`CertManagerHittingRateLimits`	Critico	Hai raggiunto un limite di frequenza durante la creazione o il rinnovo dei certificati per cinque minuti.
`DeploymentNotReady`	Critico	Un deployment nel cluster dell'infrastruttura dell'organizzazione è in stato non pronto da più di 15 minuti.
`StatefulSetNotReady`	Critico	Un oggetto `StatefulSet` nel cluster dell'infrastruttura dell'organizzazione è in stato non pronto da più di 15 minuti.
`AuditLogsForwarderDown`	Critico	Il DaemonSet `anthos-audit-logs-forwarder` non è disponibile da più di 15 minuti.
`AuditLogsLokiDown`	Critico	Lo StatefulSet `audit-logs-loki` è in stato non pronto da più di 15 minuti.