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 alla "Istruzioni per OpenShift".

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'ultima versione di Kubernetes Monitoring Operator. Per eseguire l'aggiornamento all'operatore 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 dei problemi durante la distribuzione dell'operatore 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 si disattivano i criteri di protezione del pod e l'ammissione alla protezione del pod e si consente all'operatore di eseguire la distribuzione. 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 è ancora stato configurato l'operatore di monitoraggio Kubernetes in modo da 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 (mappa del carico di lavoro) nello spazio dei nomi Operator 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 in Operator namespace (predefinito: Monitoring netapp), ma non vengono visualizzati dati nell'interfaccia utente per la mappa dei carichi 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-observer nello spazio dei nomi Operator 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 Kubernetes:

[inputs.prometheus] errore nel plug-in: Errore durante la richiesta HTTP a http://kube-state-metrics.<namespace>.svc.cluster.local:8080/metrics: Get http://kube-state-metrics.<namespace>.svc.cluster.local:8080/metrics: Dial tcp: lookup kube-state-metrics.<namespace>.svc.cluster.local: Nessun 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 kube-state-metrics implementata con Kubernetes Monitoring Operator 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] errore di scrittura in outputs.http: Post "https://<tenant_url>/REST/v1/Lake/ingerment/influenzxdb": Scadenza contesto superata (client. Timeout durante l'attesa delle intestazioni)

Modificare la sezione telegraf in AgentConfiguration e aumentare outputTimeout a 10s. 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 Kubernetes a causa di risorse insufficienti.

Fare riferimento a Kubernetes Monitoring Operator "opzioni di configurazione" Per aumentare i limiti di CPU e/o memoria in base alle esigenze.

Un'immagine mancante o una configurazione non valida ha causato il mancato avvio o la mancata preparazione dei pod di metriche a stato di netapp-ci-kube. Ora StatefulSet è bloccato e le modifiche della configurazione non vengono applicate ai pod di metriche stato netapp-ci-kube.

StatefulSet si trova in un "rotto" stato. Dopo aver risolto eventuali problemi di configurazione, bounce i pod di metrica stato netapp-ci-kube.

I pod con metriche a stato di netapp-ci-kube non si avviano dopo l'aggiornamento di un operatore Kubernetes, lanciando ErrImagePull (non riuscendo a estrarre l'immagine).

Provare a reimpostare i pod manualmente.

I messaggi "evento scartato come vecchio allora maxEventAgeSeconds" vengono osservati per il mio cluster Kubernetes in Log Analysis.

Modificare l'operatore agentconfiguration e aumentare il event-exportant-maxEventAgeSeconds (cioè a 60s), il event-exportant-kubeQPS (cioè a 100) e il event-exportant-kubeBurst (cioè a 500). Per ulteriori informazioni su queste opzioni di configurazione, consultare la "opzioni di configurazione" pagina.

Telegraf avverte di, o si blocca a causa di, memoria bloccabile insufficiente.

Provare ad aumentare il limite di memoria bloccabile per Telegraf nel sistema operativo/nodo sottostante. Se l'aumento del limite non è un'opzione, modificare la configurazione dell'agente NKMO e impostare non protetto su true. In questo modo, Telegraf non tenterà di riservare pagine di memoria bloccate. Sebbene ciò possa rappresentare un rischio per la sicurezza poiché i segreti decrittografati potrebbero essere scambiati sul disco, consente l'esecuzione in ambienti in cui non è possibile riservare la memoria bloccata. Per ulteriori informazioni sulle opzioni di configurazione non protetto, fare riferimento alla "opzioni di configurazione" pagina.