Questa pagina fornisce istruzioni dettagliate su come eseguire query e visualizzare gli avvisi aperti utilizzando sia la console GDC sia lo strumento curl per l'endpoint Cortex per acquisire consapevolezza dei problemi e risolverli.
Dopo aver creato regole di avviso
in base a log e metriche degli ambienti appliance isolati da internet di Google Distributed Cloud (GDC), puoi iniziare a monitorare gli avvisi aperti dal tuo progetto. Puoi visualizzare e filtrare gli avvisi attivati dagli eventi di sistema nella console GDC o accedervi direttamente da Cortex utilizzando lo strumento curl per script e automazione flessibili.
Puoi accedere agli avvisi aperti in uno dei due modi seguenti:
- Console GDC: visualizza i dati di avviso in pannelli integrati contenenti informazioni come il numero di avvisi per un'origine dati specifica, il livello di gravità, la durata, lo stato, il messaggio e le etichette. La console GDC fornisce un'interfaccia facile da usare per filtrare e analizzare gli avvisi dei componenti del sistema.
- Endpoint Cortex Alertmanager: per casi d'uso più avanzati, esegui query direttamente sull'istanza Cortex del tuo progetto utilizzando lo strumento
curlsu una riga di comando. Cortex archivia gli avvisi di Alertmanager del tuo progetto e fornisce un endpoint HTTP per l'accesso programmatico. Questo accesso ti consente di esportare dati, automatizzare attività, configurare cron job e creare integrazioni personalizzate.
Prima di iniziare
Per ottenere le autorizzazioni necessarie per eseguire query e visualizzare gli avvisi, chiedi all'amministratore IAM del progetto di concederti uno dei ruoli Project Cortex Alertmanager associati nello spazio dei nomi del progetto. A seconda del livello di accesso e delle autorizzazioni di cui hai bisogno, potresti ottenere ruoli di editor o visualizzatore per questa risorsa in un progetto.
Per ottenere le autorizzazioni necessarie per esportare i log, chiedi all'amministratore IAM del progetto di concederti il ruolo Project Grafana Viewer (project-grafana-viewer). Questa procedura di controllo dell'accesso basato sui ruoli ti consente di accedere alle visualizzazioni dei dati in modo sicuro. Per saperne di più su questi ruoli, consulta Prepara le autorizzazioni IAM.
La seguente tabella riepiloga i requisiti di Role per PA and AO persona.
| Utente tipo | Oggetto | Cluster | Ruolo | Spazio dei nomi | Gruppo/utente | Configurazione |
|---|---|---|---|---|---|---|
| PA | alertmanager | org-admin | project-cortex-alertmanager-viewer |
platform-obs | Gruppo | 1 |
| PA | alertmanager | org-admin | project-cortex-alertmanager-viewer |
platform-obs | Utente | 2 |
| AO | alertmanager | org-admin | project-cortex-alertmanager-viewer |
PROJECT_NAMESPACE | Gruppo | 1 |
| AO | alertmanager | org-admin | project-cortex-alertmanager-viewer |
PROJECT_NAMESPACE | Utente | 2 |
Sostituisci le seguenti variabili in modo appropriato:
| Variabile | Descrizione |
|---|---|
KUBECONFIG |
Avrai bisogno del kubeconfig per il cluster specifico che contiene NAMESPACE in cui verrà applicato questo RoleBinding. |
RULE_NAME |
Il nome univoco di questa risorsa RoleBinding all'interno dello spazio dei nomi. Ad esempio, pa-cortex-alertmanager-viewer. |
NAMESPACE |
Lo spazio dei nomi Kubernetes in cui verrà creato e applicato questo RoleBinding. Cerca la colonna Namespace nella tabella precedente. |
EMAIL_ADDRESS |
L'identificatore dell'utente a cui viene concesso il ruolo. Spesso si tratta di un indirizzo email. Ad esempio, platform-administrator@example.com. |
ROLE |
Il nome del Role che contiene le autorizzazioni che vuoi concedere all'utente. Cerca i ruoli disponibili nella tabella precedente |
GROUP_NAME |
Il nome del Group a cui appartiene l'utente PA/AO. Ad esempio, pa-group. |
ZONE |
Nome della zona |
Configurazione 1
Questa configurazione concede le autorizzazioni a un gruppo di utenti per accedere agli avvisi PA/AO nel cluster org. Dopo aver configurato questa impostazione, consulta la sezione console di questo documento per visualizzare gli avvisi nella console GDC.
Comando kubectl
Questo è il formato generico del comando:
kubectl --kubeconfig `KUBECONFIG` create rolebinding `RULE_NAME` -n `NAMESPACE` --group=`GROUP_NAME` --role=project-cortex-alertmanager-viewerEsempio:
kubectl --kubeconfig <path-to-kubeconfig> create rolebinding project-cortex-alertmanager-viewer-binding --role=project-cortex-alertmanager-viewer --group=my-team --namespace=platform-obsFile YAML
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: RULE_NAME namespace: NAMESPACE subjects: - kind: Group name: GROUP_NAME apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: project-cortex-alertmanager-viewer apiGroup: rbac.authorization.k8s.io
Configurazione 2
Questa configurazione concede le autorizzazioni a un utente per accedere agli avvisi PA/AO nel cluster org. Dopo aver configurato questa impostazione, consulta la sezione Console di questo documento per visualizzare gli avvisi nella console GDC.
Comando kubectl
Questo è il formato generico del comando:
kubectl --kubeconfig `KUBECONFIG` create rolebinding `RULE_NAME` -n `NAMESPACE` --user=`EMAIL_ADDRESS` --role=project-cortex-alertmanager-viewerEsempio:
kubectl --kubeconfig <path-to-kubeconfig> create rolebinding project-cortex-alertmanager-viewer-binding --role=project-cortex-alertmanager-viewer --user=my-email@example.com --namespace=platform-obsPercorso file IAC
/infrastructure/zonal/zones/`ZONE`/org-admin/rolebindings/`EMAIL_ADDRESS`/<YAML_FILE>File YAML
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: RULE_NAME namespace: NAMESPACE subjects: - kind: User name: EMAIL_ADDRESS apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: project-cortex-alertmanager-viewer apiGroup: rbac.authorization.k8s.ioPer saperne di più su questi ruoli, consulta Prepara le autorizzazioni IAM.
Endpoint Grafana
Per l'operatore dell'applicazione (AO):
Apri il seguente URL per accedere all'endpoint del tuo progetto:
https://GDC_URL/PROJECT_NAMESPACE/grafana
Sostituisci quanto segue:
- GDC_URL: l'URL della tua organizzazione in GDC.
- PROJECT_NAMESPACE: lo spazio dei nomi del progetto.
L'interfaccia utente del progetto contiene dashboard predefinite come la dashboard Avvisi - Panoramica con informazioni sugli avvisi. L'interrogazione degli avvisi dalla UI consente di recuperare visivamente le informazioni sugli avvisi dal progetto e di ottenere una visualizzazione integrata delle risorse per la consapevolezza e la rapida risoluzione dei problemi.
Per l'amministratore della piattaforma:
Apri il seguente URL per accedere all'endpoint del tuo progetto platform-obs:
https://GDC_URL/platform-obs/grafana
Sostituisci GDC_URL con l'URL della tua organizzazione in GDC.
L'interfaccia utente (UI) dell'istanza di monitoraggio del sistema contiene dashboard predefinite come la dashboard Avvisi - Panoramica con informazioni sugli avvisi per l'osservabilità dei dati. L'interrogazione degli avvisi dalla UI consente di recuperare visivamente le informazioni sugli avvisi dal progetto e di ottenere una visualizzazione integrata delle risorse per la consapevolezza e la rapida risoluzione dei problemi.
Figura 1. La dashboard Avvisi - Panoramica nell'interfaccia utente di Grafana.
Visualizzare e filtrare gli avvisi aperti
Seleziona uno dei seguenti metodi per eseguire query e filtrare gli avvisi aperti dallo spazio dei nomi del progetto:
Console
Visualizza gli avvisi aperti in un progetto dalla console GDC:
- Accedi alla console GDC.
- Nella console GDC, seleziona il progetto.
- Nel menu di navigazione, seleziona Operazioni > Avvisi.
- Seleziona la scheda Avvisi.
- Visualizza l'elenco degli avvisi.
- Nella sezione Avvisi aperti, fai clic su Filtra per visualizzare solo gli avvisi aperti. Puoi anche filtrare gli avvisi in base ad altri nomi o valori delle proprietà.
- Fai clic sul nome di un avviso per visualizzarne i dettagli.
Endpoint Cortex
Questa sezione descrive come accedere agli avvisi utilizzando l'endpoint Cortex Alertmanager.
Identifica l'endpoint Cortex
Il seguente URL è l'endpoint dell'istanza Cortex del tuo progetto:
https://GDC_URL/PROJECT_NAMESPACE/cortex/alertmanager/
Sostituisci quanto segue:
GDC_URL: l'URL della tua organizzazione in GDC.PROJECT_NAMESPACE: lo spazio dei nomi del progetto.Ad esempio, l'endpoint Cortex per il progetto
platform-obsnell'organizzazioneorg-1èhttps://org-1/platform-obs/cortex/alertmanager/.
Autentica la richiesta curl
- Scarica e installa l'interfaccia a riga di comando gcloud.
Imposta la proprietà gdcloud
core/organization_console_url:gdcloud config set core/organization_console_url https://GDC_URLAccedi con il provider di identità configurato:
gdcloud auth loginUtilizza il tuo nome utente e la tua password per autenticarti e accedere.
Una volta eseguito l'accesso, puoi utilizzare l'intestazione di autorizzazione nella richiesta cURL tramite il comando
gdcloud auth print-identity-token. Per maggiori informazioni, consulta gdcloud auth.
Chiama l'endpoint Cortex
Completa i seguenti passaggi per raggiungere l'endpoint Cortex utilizzando lo strumento curl:
- Autentica la richiesta
curl. Utilizza
curlper chiamare l'endpoint Cortex ed estendi l'URL utilizzando la specifica API Alertmanager standard (https://prometheus.io/docs/prometheus/latest/querying/api/#alertmanagers) per eseguire query sugli avvisi.Di seguito è riportato un esempio di richiesta
curl:curl https://GDC_URL/PROJECT_NAME/cortex/alertmanager/api/v1/alertmanagers \ -H "Authorization: Bearer $(gdcloud auth print-identity-token \ --audiences=https://GDC_URL)"Ottieni l'output seguente al comando. La risposta dell'API è in formato JSON.
Alertmanager
Alertmanager ti consente di monitorare le notifiche di avviso dalle applicazioni client. Puoi ispezionare e silenziare gli avvisi utilizzando Alertmanager e filtrare o raggruppare gli avvisi:
Figura 2. Opzione di menu per eseguire query sui log di controllo da Alertmanager.
Policy di avviso predefinite
La tabella seguente elenca le regole di avviso preinstallate in Prometheus:
| Nome | Descrizione |
|---|---|
| KubeAPIDown (critico) | KubeAPI è scomparso dal rilevamento dei target di Prometheus per 15 minuti. |
| KubeClientErrors (avviso) | Il rapporto tra errori client del server API Kubernetes e richieste è > 0,01 per 15 minuti. |
| KubeClientErrors (critico) | Rapporto errori client del server API Kubernetes > 0,1 per 15 minuti. |
| KubePodCrashLooping (avviso) | Il pod è in uno stato di loop di arresto anomalo da più di 15 minuti. |
| KubePodNotReady (avviso) | Il pod è in uno stato non pronto da più di 15 minuti. |
| KubePersistentVolumeFillingUp (critico) | Byte disponibili di un PersistentVolume richiesto < 0,03. |
| KubePersistentVolumeFillingUp (avviso) | Byte liberi di un PersistentVolume richiesto < 0,15. |
| KubePersistentVolumeErrors (critico) | Il volume permanente si trova nella fase Non riuscito o In attesa per cinque minuti. |
| KubeNodeNotReady (avviso) | Il nodo non è pronto da più di 15 minuti. |
| KubeNodeCPUUsageHigh (critico) | L'utilizzo della CPU del nodo è > 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 scade tra 21 giorni. |
| CertManagerCertNotReady (critico) | Un certificato non è pronto a gestire il traffico dopo 10 minuti. |
| CertManagerHittingRateLimits (critico) | È stato raggiunto un limite di frequenza per la creazione e il rinnovo dei certificati per cinque minuti. |
| DeploymentNotReady (critico). | Un deployment sul cluster di amministrazione dell'organizzazione è in stato non pronto da più di 15 minuti. |
Esempio di alertmanagerConfigurationConfigmaps
La sintassi delle configurazioni in ConfigMaps elencate da alertmanagerConfigurationConfigmaps deve seguire 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>
Configurazione di esempio della regola
# 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>
Avvisi di query dall'API HTTP
La piattaforma di osservabilità espone un endpoint API HTTP per l'esecuzione di query e la lettura di metriche, avvisi e altri dati delle serie temporali dal tuo progetto per il monitoraggio del sistema.Esegui query sugli avvisi direttamente dall'API HTTP di osservabilità per configurare attività automatizzate, adattare le risposte e creare integrazioni in base al tuo caso d'uso. Ad esempio, inserisci l'output in un altro comando, esporta i dettagli in formati di file di testo o configura un cron job Linux. Puoi chiamare l'API HTTP di Observability dall'interfaccia a riga di comando (CLI) o da un browser web e ottenere il risultato in formato JSON.
Questa sezione spiega come chiamare l'endpoint API HTTP di osservabilità dalla CLI utilizzando la specifica dell'API per eseguire query sugli avvisi.
Esegui query sugli avvisi direttamente dall'API HTTP di osservabilità per configurare attività automatizzate, adattare le risposte e creare integrazioni in base al tuo caso d'uso. Ad esempio, inserisci l'output in un altro comando, esporta i dettagli in formati di file di testo o configura un cron job Linux. Puoi chiamare l'API HTTP di Observability dall'interfaccia a riga di comando (CLI) o da un browser web e ottenere il risultato in formato JSON.
Questa sezione spiega come chiamare l'endpoint API HTTP di osservabilità dalla CLI utilizzando la specifica dell'API Alertmanager per eseguire query sulle metriche.
Prima di iniziare
Per ottenere le autorizzazioni necessarie per accedere all'endpoint API HTTP di Observability, chiedi all'amministratore IAM del progetto di concederti il ruolo Project Cortex Alertmanager Viewer (project-cortex-alertmanager-viewer) nello spazio dei nomi del progetto.
L'amministratore IAM del progetto può concederti l'accesso creando un'associazione di ruoli:
a. Amministratore root operatore dell'infrastruttura (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. Amministratore della piattaforma (PA) - Amministratore principale - 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. Amministratore principale operatore dell'applicazione (AO) - Visualizzatore Alertmanager di Project Cortex: Progetto: $AO_PROJECT Nome utente 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
Una volta creato il binding del ruolo, puoi accedere al corrispondente Alertmanager con il tuo nome utente di accesso.
Verifica l'associazione del ruolo
kubectl --kubeconfig $HOME/org-1-admin-kubeconfig get rolebinding -n platform-obs
Per informazioni sull'impostazione dei binding dei ruoli dalla console GDC, vedi Concedere l'accesso alle risorse.
Endpoint Cortex
Il seguente URL è l'endpoint Cortex per accedere agli avvisi:
https://GDC_URL/PROJECT_NAME/cortex/alertmanager/
Sostituisci quanto segue:
- GDC_URL: l'URL della tua organizzazione in GDC.
- PROJECT_NAME: il nome del progetto
Chiama l'endpoint API
Segui questi passaggi per raggiungere l'endpoint dell'API Cortex dalla CLI ed eseguire query sugli avvisi:
- Assicurati di soddisfare i prerequisiti.
- Apri la CLI.
Utilizza lo strumento
curlper chiamare l'URL dell'endpoint Cortex ed estendere l'URL utilizzando lo standard https://prometheus.io/docs/prometheus/latest/querying/api/#alertmanagers per eseguire query sugli avvisi. Ad esempio:curl https://console.org-1.zone1.google.gdch.test/alice/cortex/alertmanager/api/v1/alertmanagers
Ottieni l'output nella CLI dopo il comando. Il formato della risposta dell'API è JSON.