Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Risoluzione dei problemi di osservabilità

Questo documento fornisce procedure di risoluzione dei problemi e descrizioni di riferimento degli avvisi di sistema predefiniti per aiutarti a identificare gli errori di deployment e risolvere gli incidenti operativi con i componenti di logging e monitoraggio nell'appliance Google Distributed Cloud con air gap. Puoi utilizzare queste procedure e definizioni di avvisi per verificare che gli stack di logging e monitoraggio siano in esecuzione, ispezionare le configurazioni della pipeline e risolvere i problemi dei componenti.

Identifica 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 dello spazio di archiviazione. Inoltre, fornisce l'accesso ai log operativi e di controllo. Inoltre, consente di accedere ad avvisi, log e metriche dei componenti operativi 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 dell'infrastruttura dell'organizzazione per l'archiviazione a lungo termine. Prometheus aggiunge etichette sotto forma di 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 del 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 (UI) per visualizzare le metriche raccolte da Prometheus ed eseguire query sui log di controllo e operativi dalle istanze Loki corrispondenti. La UI 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.

Identifica 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 visualizzato 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 significa necessariamente che si sia verificato 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 visualizzato 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 un valore di 2.

Un numero elevato di riavvii indica i seguenti sintomi:
- I pod non funzionano 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 è in 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.
Determina 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 sono presenti eventi nel pod o in un'altra risorsa per un periodo di tempo prolungato, viene visualizzato il seguente output:
```
  Events:         <none>
```

Verifica 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 in tutte le istanze o i pod Loki sia stata eseguita l'iniezione sidecar di Istio. 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 di 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 per gli 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 dell'infrastruttura dell'organizzazione.

Verifica che lo stack di monitoraggio di Observability sia in esecuzione

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

Verifica 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 di Grafana. Le istanze variano in base al cluster.

Assicurati che tutti i componenti di monitoraggio si trovino nel mesh di servizi Istio. Segui i passaggi della sezione Identifica gli errori di deployment. Per ognuno dei seguenti pod, tutti i container devono essere 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.

Recupera i log di Observability

La tabella seguente contiene i comandi che devi eseguire per recuperare i log per ciascuno dei componenti di cui la piattaforma di osservabilità esegue il deployment.

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 consente di esaminare i log di un'istanza precedente che ha avuto esito negativo anziché dell'istanza attualmente in esecuzione.

Visualizza la configurazione

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

Il deployment della risorsa personalizzata LoggingPipeline viene eseguito nel cluster dell'infrastruttura dell'organizzazione e configura le istanze di 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 dei componenti di osservabilità, come Prometheus e Fluent Bit. L'API per il 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 tuo 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 per nome nella definizione della risorsa personalizzata logmon. 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 tuo cluster Kubernetes. Per accedere temporaneamente all'interfaccia di Grafana dall'esterno del cluster dell'infrastruttura dell'organizzazione, puoi eseguire il port forwarding di Service a localhost. Per eseguire il port forwarding di Service, esegui:

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

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

Grafana funziona lentamente

Se Grafana è lento, significa che:

Le query a Prometheus o Loki restituiscono dati eccessivi.
Le query restituiscono più dati di quanti sia ragionevole visualizzare su un singolo grafico.

Per risolvere i problemi di velocità ridotta in Grafana, controlla le query sulle dashboard Grafana personalizzate. Se le query restituiscono più dati di quelli che è ragionevole visualizzare in un singolo grafico, valuta la possibilità di ridurre la quantità di dati mostrati per migliorare le prestazioni della 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 Grafana non sono impostate correttamente.
Il sistema presenta problemi di connettività alle origini dati di monitoraggio o logging.
Il sistema non raccoglie metriche o log.

Per visualizzare i log e le metriche, segui questi passaggi:

Nell'interfaccia utente di Grafana, fai clic su Dashboard settings (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`

L'assenza di queste origini dati indica che lo stack di osservabilità non è riuscito a configurare correttamente Grafana.

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

Prometheus raccoglie le metriche seguendo un modello di pull per eseguire periodicamente query sugli oggetti Service per rilevare le metriche e archiviare i valori trovati. Affinché Prometheus possa rilevare gli oggetti Service per la raccolta delle metriche, deve essere soddisfatta la seguente condizione:

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 in modo che Kubernetes la propaghi ai pod.
Il formato delle metriche di 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 eseguire l'override di porta, endpoint e schema tramite annotazioni.

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

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

Controlla i log delle istanze Loki per assicurarti che vengano eseguite senza errori.
Se le istanze di Loki funzionano 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 Recupera i log di Observability.

Alertmanager non apre gli 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 l'etichetta logmon: system_metrics esista.
Verifica che la sezione dei dati configMap includa una chiave denominata alertmanager.yml. Il valore della chiave alertmanager.yml deve essere costituito dalle regole di avviso contenute nel file di configurazione di 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 della 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 software esterno, segui questi passaggi:

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 o la tua chiave API attuale potrebbe essere scaduta e devi aggiornarla.
Se il servizio esterno non fa parte del deployment dell'appliance GDC con air gap, assicurati che il cluster dell'infrastruttura della tua organizzazione abbia configurato le regole in uscita. Questa configurazione consente ad Alertmanager di inviare richieste a un servizio esterno alla rete Kubernetes interna. La mancata verifica delle regole in uscita potrebbe impedire ad Alertmanager di trovare il software esterno.

Non puoi visualizzare le metriche del workload con ambito di progetto

Segui questi passaggi 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 sul target 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 workload.
Prometheus esegue più shard, il che significa che non tutti i pod Prometheus dovrebbero 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 di Prometheus:
1. Esegui il port forwarding 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 alla UI di Prometheus nel browser web e segui questi passaggi:
  1. Fai clic su Stato > Target.
  2. Assicurati che il pod di cui vuoi eseguire lo scraping sia presente nell'elenco. In caso contrario, controlla lo shard successivo. 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 gli errori nello spazio dei nomi obs-system.
Verifica che il pod cortex-tenant registri gli errori nello spazio dei nomi obs-system.

Non è stata creata una dashboard

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

Esamina lo stato della risorsa personalizzata Dashboard per verificare la presenza di eventuali 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 nell'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 eventuali errori. Le dashboard eseguono query sull'API REST di Grafana, quindi Grafana deve essere in funzione 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 bucket. Le regole non funzionano a meno che il backend non sia supportato dallo spazio di archiviazione del 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 Crea regole di avviso per assicurarti che le regole siano configurate come vuoi. 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 con cui valutare la condizione. Confronta 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 Alerts (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

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

Controlla se il componente è in esecuzione e genera 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 gli 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 presenti errori.
Se il 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.

Identifica le regole di avviso predefinite

Questa sezione contiene informazioni sulle regole di avviso predefinite esistenti nei componenti di Observability per informarti 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 audit logging:

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

Quando vengono visualizzati uno o più di questi avvisi, significa che il sistema ha perso almeno un audit record.

Regole di avviso predefinite in Prometheus

La tabella seguente 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 di Prometheus per 15 minuti.
`KubeClientErrors`	Avviso	Il rapporto di errori del client del server API Kubernetes è stato superiore a 0,01 per 15 minuti.
`KubeClientErrors`	Critico	Il rapporto di errori del client del server API Kubernetes è stato superiore a 0,1 per 15 minuti.
`KubePodCrashLooping`	Avviso	Il pod è in stato di loop di arresto anomalo da più di 15 minuti.
`KubePodNotReady`	Avviso	Il pod è in stato non pronto da più di 15 minuti.
`KubePersistentVolumeFillingUp`	Critico	I byte liberi di un oggetto `PersistentVolume` rivendicato sono inferiori a 0,03.
`KubePersistentVolumeFillingUp`	Avviso	I byte liberi 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	La memoria utilizzata dal 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 scadrà 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 sul 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` è inattivo da più di 15 minuti.
`AuditLogsLokiDown`	Critico	Lo StatefulSet `audit-logs-loki` è in stato non pronto da più di 15 minuti.