Non viene visualizzato un collegamento ipertestuale/connessione tra il volume persistente Kubernetes e il dispositivo di storage back-end corrispondente. Il volume persistente Kubernetes viene configurato utilizzando il nome host del server di storage.

Seguire la procedura per disinstallare l'agente Telegraf esistente, quindi reinstallare l'agente Telegraf più recente. È necessario utilizzare Telegraf versione 2.0 o successiva e lo storage del cluster Kubernetes deve essere monitorato attivamente da Cloud Insights.

Nei registri vengono visualizzati messaggi simili a quelli riportati di seguito:

E0901 15:21:39,962145 1 Reflector.go:178] k8s.io/kube-state-metrics/internal/store/builder.go:352: Impossibile elencare *v1.MutatingWebhookConfigurazione: Il server non ha trovato la risorsa richiesta
E0901 15:21:43,168161 1 Reflector.go:178] k8s.io/kube-state-metrics/internal/store/builder.go:352: Impossibile elencare *v1.Lease: Il server non ha trovato la risorsa richiesta (get leases.Coordination.k8s.io)
ecc.

Questi messaggi possono verificarsi se si utilizza kube-state-metrics versione 2.0.0 o superiore con versioni di Kubernetes inferiori alla 1.20.


Per ottenere la versione di Kubernetes:

kubectl version

Per ottenere la versione kube-state-metrics:

kubectl get deploy/kube-state-metrics -o jsonpath='{..image}'

Per evitare che questi messaggi si verifichino, gli utenti possono modificare la distribuzione delle metriche dello stato-kube per disabilitare i seguenti leasing:

mutatingwebhookconfigurations
validatingwebhookconfigurations
volumeattachments resources

In particolare, possono utilizzare il seguente argomento CLI:

resources=certificatesigningrequires,configmaps,cronjob,daemonset, deployments,endpoints,horizontalpodautoscalers,ingresses,job,limitrange, namespace,networkpolicy,node,persistentvolumeclaims

L'elenco delle risorse predefinito è:

"certificatesigningrequests,configmaps,cronjob,daemonsets,deployments, endpoint,horizontalpodautoscalers,ingresses,job,leases,limitrange, mutatingwebhookconfigurations,namespaces,networkpolicy,nodi, persistentvolumeclaimes,durentvolumetsets,poddisruptionbudgets,pods,replicasets, replicationstoricasets,replicationfors,storeforcsets,servizi,storeforcsets,storeforcsets convalidatingwebhookconfigurations,volumeattachments"

Vengono visualizzati messaggi di errore di Telegraf simili ai seguenti, ma Telegraf si avvia ed esegue:

Oct 11 14:23:41:00 ip-172-31-39-47 systemd[1]: Avviato l'agente server basato su plugin per la generazione di rapporti sulle metriche in InfluxDB.
Ottobre 11 14:23:41 ip-172-31-39-47 telegraf[1827]: Time="2021-10-11T14:23:41Z" level=error msg="Impossibile creare la directory della cache. /etc/telegraf/.cache/snowflake, err: mkdir /etc/telegraf/.ca
che: permesso negato. Ignorato\n" func="gosnowflake.(*defaultLogger).Errorf" file="log.go:120"
Ott 11 14:23:41:00 ip-172-31-39-47 telegraf[1827]: Time="2021-10-11T14:23:41Z" level=error msg="Impossibile aprire. Ignorato. aprire /etc/telegraf/.cache/snowflake/ocsp_response_cache.json: no
File o directory\n" func="gosnowflake.(*defaultLogger).Errorf" file="log.go:120"
Oct:23:41:ip-172-31-39-47:11 14 telegraf[1827]: 2021-10-11T14:23:41Z i! Avvio di Telegraf 1.19.3

Si tratta di un problema noto. Fare riferimento a. "Questo articolo di GitHub" per ulteriori dettagli. Finché Telegraf è in funzione, gli utenti possono ignorare questi messaggi di errore.

In Kubernetes, i pod Telegraf riportano il seguente errore:
"Errore durante l'elaborazione delle informazioni sui mount stats: Impossibile aprire il file mountstats: /Hostfs/proc/1/mountstats, errore: Open /hostfs/proc/1/mountstats: Permesso negato"

Se SELinux è abilitato e abilitato, probabilmente impedisce ai pod Telegraf di accedere al file /proc/1/mountstats sul nodo Kubernetes. Per superare questa restrizione, modificare la configurazione dell'agente e attivare l'impostazione runPrivileged. Per ulteriori informazioni, fare riferimento a: https://docs.netapp.com/us-en/cloudinsights/task_config_telegraf_agent_k8s.html#openshift-instructions.

In Kubernetes, il pod Telegraf ReplicaSet riporta il seguente errore:

[inputs.prometheus] errore nel plugin: Impossibile caricare keypair /etc/kuowski/pki/etcd/server.crt:/etc/kuowski/pki/etcd/server.key: Aprire /etc/kuowski/pki/etcd/server.crt: Nessun file o directory di questo tipo

Il pod ReplicaSet di Telegraf è destinato all'esecuzione su un nodo designato come master o etcd. Se il pod ReplicaSet non è in esecuzione su uno di questi nodi, si otterranno questi errori. Verificare se i nodi master/etcd presentano delle contaminazioni. In tal caso, aggiungere le tolleranze necessarie a Telegraf ReplicaSet, telegraf-rs.

Ad esempio, modificare ReplicaSet…​

kubectl edit rs telegraf-rs

…​e aggiungere le tolleranze appropriate alle specifiche. Quindi, riavviare il pod ReplicaSet.

Ho un ambiente PSP/PSA. Questo influisce sul mio operatore di monitoraggio?

Se il cluster Kubernetes è in esecuzione con Pod Security Policy (PSP) o Pod Security Admission (PSA), è necessario eseguire l'aggiornamento all'ultimo NetApp Kubernetes Monitoring Operator. Per eseguire l'aggiornamento all'NKMO corrente con il supporto per PSP/PSA, procedere come segue:

1. Disinstallare l'operatore di monitoraggio precedente:

kubectl delete agent-monitoring-netapp -n monitoring
kubectl elimina ns monitoraggio netapp
kubectl cancella crd agents.monitoring.netapp.com
kubectl elimina agente-manager-ruolo-agente-proxy-ruolo-agente-metrica-lettore
kubectl elimina agente di associazione-manager-agente di legame-proxy-agente di legame-cluster-admin-rolebinding

2. Installare la versione più recente dell'operatore di monitoraggio.

Ho riscontrato problemi nel tentativo di implementare NKMO e ho utilizzato PSP/PSA.

1. Modificare l'agente utilizzando il seguente comando:

kubectl -n <name-space> edit agent

2. Contrassegnare 'sicurezza-policy-enabled' come 'false'. In questo modo verranno disabilitati i criteri di sicurezza Pod e l'ammissione alla sicurezza Pod e verrà consentito l'implementazione di NKMO. Confermare utilizzando i seguenti comandi:

Kubectl Prendi psp (dovrebbe mostrare la politica di sicurezza del Pod rimossa)
kubectl get all -n <namespace>

grep -i psp (dovrebbe mostrare che non si trova nulla)

Errori "ImagePullBackoff" rilevati

Questi errori possono essere rilevati se si dispone di un repository di docker personalizzato o privato e non si è ancora configurato NetApp Kubernetes Monitoring Operator per riconoscerlo correttamente. Scopri di più informazioni sulla configurazione per repo personalizzato/privato.

Si verifica un problema con l'implementazione dell'operatore di monitoraggio e la documentazione corrente non mi aiuta a risolverlo.

I pod Net-Observer (Workload Map) nello spazio dei nomi NKMO si trovano in CrashLoopBackOff

Questi pod corrispondono al data collector Workload Map per l'osservabilità della rete. Provare a effettuare le seguenti operazioni:
• Controllare i log di uno dei pod per confermare la versione minima del kernel. Ad esempio:

----
{"ci-tenant-id":"your-tenant-id","collector-cluster":"your-k8s-cluster-name","environment":"prod","level":"error","msg":"failed in validation. Motivo: La versione del kernel 3.10.0 è inferiore alla versione minima del kernel 4.18.0","Time":"2022-11-09T08:23:08Z"}
----

• I pod Net-observer richiedono che la versione del kernel Linux sia almeno 4.18.0. Controllare la versione del kernel usando il comando "uname -r" e assicurarsi che siano >= 4.18.0

I pod vengono eseguiti nello spazio dei nomi NKMO (impostazione predefinita: monitoraggio netapp), ma non vengono visualizzati dati nell'interfaccia utente per la mappa del carico di lavoro o le metriche Kubernetes nelle query

Controllare l'impostazione dell'ora sui nodi del cluster K8S. Per un controllo accurato e la creazione di report dei dati, si consiglia di sincronizzare l'ora sul computer dell'agente utilizzando il protocollo NTP (Network Time Protocol) o SNTP (Simple Network Time Protocol).

Alcuni dei pod net-osservatore nello spazio dei nomi NKMO sono in stato Pending

NET-osservatore è un DemonSet che esegue un pod in ogni nodo del cluster k8s.
• Notare il pod che si trova nello stato in sospeso e controllare se si verifica un problema di risorse per la CPU o la memoria. Assicurarsi che la memoria e la CPU richieste siano disponibili nel nodo.

Vedo quanto segue nei miei log subito dopo l'installazione dell'operatore di monitoraggio NetApp Kubernetes:

[inputs.prometheus] errore nel plugin: Errore durante la richiesta HTTP a. http://kube-state-metrics.<namespace>.svc.cluster.local:8080/metrics: Ottieni http://kube-state-metrics.<namespace>.svc.cluster.local:8080/metrics: dial tcp: lookube-state-metrics.<namespace>.svc.cluster.local: no tale host

Questo messaggio viene visualizzato in genere solo quando viene installato un nuovo operatore e il pod telegraf-rs è attivo prima che il pod ksm sia attivo. Questi messaggi dovrebbero interrompersi una volta che tutti i pod sono in esecuzione.

Non vedo alcuna metrica raccolta per Kubernetes Cronjobs che esiste nel mio cluster.

Verificare la versione di Kubernetes (ad es kubectl version). Se è v1.20.x o inferiore, si tratta di un limite previsto. La release di metriche dello stato kube implementata con l'operatore di monitoraggio Kubernetes di NetApp supporta solo v1.cronjob. Con Kubernetes 1.20.x e versioni precedenti, la risorsa cronjob è v1beta.cronjob. Di conseguenza, le metriche dello stato del kube non riescono a trovare la risorsa di crono-job.

Dopo aver installato l'operatore, i pod telegraf-ds entrano in CrashLoopBackOff e i registri del pod indicano "su: Authentication failure" (su: Errore di autenticazione).

Modificare la sezione telegraf in AgentConfiguration e impostare dockerMetricCollectionEnabled su false. Per ulteriori dettagli, fare riferimento al manuale dell'operatore "opzioni di configurazione".

NOTA: se si utilizza l'Edizione Federale di Cloud Insights, gli utenti con restrizioni sull'uso di su non potranno raccogliere metriche di docker perché l'accesso al socket di docker richiede l'esecuzione del contenitore di telegraf come root o l'utilizzo di su per aggiungere l'utente di telegraf al gruppo di docker. La raccolta di metriche Docker e l'utilizzo di su sono attivati per impostazione predefinita; per disabilitare entrambi, rimuovere la voce telegraf.docker nel file AgentConfiguration:

…​
specifiche:
…​
telegraf:
…​
     - nome: docker
            modalità di esecuzione:
              - DaemonSet
            sostituzioni:
              CHIAVE: DOCKER_UNIX_SOCK_PLACEHOLDER
                valore: unix://run/docker.sock
…​
…​

Nei registri di Telegraf vengono visualizzati messaggi di errore ricorrenti simili a quelli riportati di seguito:

E! [Agent] Error writing to outputs.http: Post "https://<tenant_url>/rest/v1/lake/ingest/influxdb": Scadenza contesto superata (timeout client superato in attesa di intestazioni)

Modificare la sezione telegraf in AgentConfiguration e impostare dockerMetricCollectionEnabled su false. Per ulteriori dettagli, fare riferimento al manuale dell'operatore "opzioni di configurazione".

Mancano i dati involvedobject per alcuni registri eventi.

Assicurarsi di aver seguito i passaggi descritti in "Permessi" sezione precedente.

Perché vedo due pod operatore di monitoring in esecuzione, uno denominato netapp-ci-monitoring-operator-<pod> e l'altro denominato monitoring-operator-<pod>?

A partire dal 12 ottobre 2023, Cloud Insights ha ridefinito l'operatore per servire meglio i nostri utenti; affinché tali modifiche siano completamente adottate, è necessario rimuovere il vecchio operatore e. installare il nuovo.

I miei eventi kuowski hanno inaspettatamente smesso di segnalare a Cloud Insights.

grep event-exporter

awk '{print $1}'

sed 's/event-exporter./event-exporter/'`
Deve essere "netapp-ci-event-exportant" o "event-exportant". Quindi, modificare l'agente di monitoraggio kubectl -n netapp-monitoring edit agent, E impostare il valore per LOG_FILE in modo che rifletta il nome del pod dell'esportatore di eventi appropriato trovato nel passaggio precedente. In particolare, LOG_FILE deve essere impostato su "/var/log/containers/netapp-ci-event-exportant.log" o "/var/log/containers/event-exportant*.log"

…​.
fluent-bit:
…​
- name: event-exporter-ci
substitutions:
- key: LOG_FILE
values:
- /var/log/containers/netapp-ci-event-exporter*.log
…​
…​.
In alternativa, si può anche disinstallazione e. reinstallare l'agente.

Sto vedendo i pod implementati dal crash dell'operatore di monitoring NetApp Kubernetes a causa di risorse insufficienti.

Fare riferimento all'operatore di monitoraggio Kubernetes NetApp "opzioni di configurazione" Per aumentare i limiti di CPU e/o memoria in base alle esigenze.