La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Installazione e configurazione dell'operatore di monitoraggio Kubernetes

11/25/2024 Collaboratori

PDF

Data Infrastructure Insights offre la raccolta Kubernetes Monitoring Operator for Kubernetes. Navigare a Kubernetes > Collector > +Kubernetes Collector per implementare un nuovo operatore.

Prima di installare l'operatore di monitoraggio Kubernetes

Consultare la "Prerequisiti" documentazione prima di installare o aggiornare Kubernetes Monitoring Operator.

Installazione dell'operatore di monitoraggio Kubernetes

Istruzioni per il monitoraggio dell'operatore

Passaggi per installare l'agente Kubernetes Monitoring Operator su Kubernetes:

Immettere un nome cluster e uno spazio dei nomi univoci. Se si aggiornamento in corsoproviene da un operatore Kubernetes precedente, utilizzare lo stesso nome cluster e lo stesso namespace.
Una volta immessi, è possibile copiare il frammento Download Command negli Appunti.
Incollare il frammento in una finestra bash ed eseguirlo. I file di installazione dell'operatore verranno scaricati. Tenere presente che il frammento ha una chiave univoca ed è valido per 24 ore.
Se si dispone di un repository personalizzato o privato, copiare il frammento Image Pull opzionale, incollarlo in una shell bash ed eseguirlo. Una volta estratte le immagini, copiarle nel repository privato. Assicurarsi di mantenere gli stessi tag e la stessa struttura di cartelle. Aggiornare i percorsi in operator-deployment.yaml e le impostazioni del repository di docker in operator-config.yaml.
Se lo si desidera, esaminare le opzioni di configurazione disponibili, ad esempio le impostazioni del proxy o del repository privato. È possibile leggere ulteriori informazioni su "opzioni di configurazione".
Quando sei pronto, implementa l'operatore copiando il frammento kubectl apply, scaricandolo ed eseguendolo.
L'installazione procede automaticamente. Una volta completata l'operazione, fare clic sul pulsante Avanti.
Al termine dell'installazione, fare clic sul pulsante Next. Assicurarsi inoltre di eliminare o memorizzare in modo sicuro il file operator-secrets.yaml.

Se si utilizza un proxy, consultare informazioni su configurazione del proxy.

Se si dispone di un repository personalizzato, consultare informazioni su utilizzando un repository di docker personalizzato/privato.

Componenti di monitoring Kubernetes

Data Infrastructure Insights Kubernetes Monitoring comprende quattro componenti di monitoring:

Metriche cluster
Mappa e prestazioni della rete (opzionale)
Registri eventi (opzionali)
Analisi delle modifiche (opzionale)

I componenti opzionali elencati in precedenza sono abilitati per impostazione predefinita per ogni collettore di Kubernetes; se si decide di non avere bisogno di un componente per un determinato collettore, è possibile disattivarlo accedendo a Kubernetes > Collectors e selezionando Modify Deployment dal menu "Three Dots" del collettore sulla destra dello schermo.

Modificare il menu di distribuzione nella pagina dell'elenco di Kubernetes Collector

La schermata mostra lo stato corrente di ciascun componente e consente di disattivare o attivare i componenti per tale collettore, se necessario.

Opzioni di distribuzione di Mody, 700

Aggiornamento in corso

Aggiornamento alla versione più recente di Kubernetes Monitoring Operator

Determinare se esiste una configurazione Agentcon l'operatore esistente (se lo spazio dei nomi non è il monitoraggio netapp predefinito, sostituire lo spazio dei nomi appropriato):

 kubectl -n netapp-monitoring get agentconfiguration netapp-monitoring-configuration
Se esiste una configurazione AgentConfiguration:

Installare L'operatore più recente rispetto all'operatore esistente.
- Assicurarsi di estrarre le immagini container più recentiutilizzare un repository personalizzato.

Se AgentConfiguration non esiste:

Prendere nota del nome del cluster come riconosciuto da Data Infrastructure Insights (se il namespace non è quello predefinito di NetApp-monitoring, sostituire il namespace appropriato):
```
 kubectl -n netapp-monitoring get agent -o jsonpath='{.items[0].spec.cluster-name}'
* Creare un backup dell'operatore esistente (se lo spazio dei nomi non è il monitoraggio netapp predefinito, sostituire lo spazio dei nomi appropriato):
```
```
 kubectl -n netapp-monitoring get agent -o yaml > agent_backup.yaml
* <<to-remove-the-kubernetes-monitoring-operator,Disinstallare>> L'operatore esistente.
* <<installing-the-kubernetes-monitoring-operator,Installare>> L'operatore più recente.
```
- Utilizzare lo stesso nome del cluster.
- Dopo aver scaricato i file YAML dell'operatore più recenti, portare le personalizzazioni trovate in Agent_backup.yaml nell'operator-config.yaml scaricato prima di eseguire la distribuzione.
- Assicurarsi di estrarre le immagini container più recentiutilizzare un repository personalizzato.

Arresto e avvio dell'operatore di monitoraggio Kubernetes

Per arrestare l'operatore di monitoraggio Kubernetes:

 kubectl -n netapp-monitoring scale deploy monitoring-operator --replicas=0
Per avviare l'operatore di monitoraggio Kubernetes:

kubectl -n netapp-monitoring scale deploy monitoring-operator --replicas=1

Disinstallazione in corso

Per rimuovere l'operatore di monitoraggio Kubernetes

Si noti che il namespace predefinito per Kubernetes Monitoring Operator è "netapp-monitoring". Se è stato impostato uno spazio dei nomi personalizzato, sostituire tale spazio dei nomi in questi e in tutti i comandi e file successivi.

Le versioni più recenti dell'operatore di monitoraggio possono essere disinstallate con i seguenti comandi:

kubectl -n <NAMESPACE> delete agent -l installed-by=nkmo-<NAMESPACE>
kubectl -n <NAMESPACE> delete clusterrole,clusterrolebinding,crd,svc,deploy,role,rolebinding,secret,sa -l installed-by=nkmo-<NAMESPACE>

Se l'operatore di monitoraggio è stato distribuito nel proprio spazio dei nomi dedicato, eliminare lo spazio dei nomi:

 kubectl delete ns <NAMESPACE>
Se il primo comando restituisce "Nessuna risorsa trovata", attenersi alle istruzioni riportate di seguito per disinstallare le versioni precedenti dell'operatore di monitoraggio.

Eseguire ciascuno dei seguenti comandi nell'ordine indicato. A seconda dell'installazione corrente, alcuni di questi comandi potrebbero restituire i messaggi ‘oggetto non trovato’. Questi messaggi possono essere ignorati in modo sicuro.

kubectl -n <NAMESPACE> delete agent agent-monitoring-netapp
kubectl delete crd agents.monitoring.netapp.com
kubectl -n <NAMESPACE> delete role agent-leader-election-role
kubectl delete clusterrole agent-manager-role agent-proxy-role agent-metrics-reader <NAMESPACE>-agent-manager-role <NAMESPACE>-agent-proxy-role <NAMESPACE>-cluster-role-privileged
kubectl delete clusterrolebinding agent-manager-rolebinding agent-proxy-rolebinding agent-cluster-admin-rolebinding <NAMESPACE>-agent-manager-rolebinding <NAMESPACE>-agent-proxy-rolebinding <NAMESPACE>-cluster-role-binding-privileged
kubectl delete <NAMESPACE>-psp-nkmo
kubectl delete ns <NAMESPACE>

Se in precedenza è stato creato un vincolo del contesto di protezione:

kubectl delete scc telegraf-hostaccess

A proposito di Kube-state-metrics

NetApp Kubernetes Monitoring Operator installa le proprie metriche di stato kube per evitare conflitti con altre istanze.

Per informazioni su Kube-state-Metrics, vedere "questa pagina".

Configurazione/personalizzazione dell'operatore

Queste sezioni contengono informazioni sulla personalizzazione della configurazione dell'operatore, sull'utilizzo di proxy, sull'utilizzo di un repository di docker personalizzato o privato o sull'utilizzo di OpenShift.

Opzioni di configurazione

Le impostazioni più comunemente modificate possono essere configurate nella risorsa personalizzata AgentConfiguration. È possibile modificare questa risorsa prima di implementare l'operatore modificando il file operator-config.yaml. Questo file include esempi di impostazioni commentate. Vedere l'elenco di "impostazioni disponibili" per la versione più recente dell'operatore.

È anche possibile modificare questa risorsa dopo che l'operatore è stato distribuito utilizzando il seguente comando:

 kubectl -n netapp-monitoring edit AgentConfiguration
Per determinare se la versione implementata dell'operatore supporta AgentConfiguration, eseguire il seguente comando:

 kubectl get crd agentconfigurations.monitoring.netapp.com
Se viene visualizzato il messaggio "Error from server (notfound)" (errore dal server (non trovato)), l'operatore deve essere aggiornato prima di poter utilizzare AgentConfiguration.

Configurazione del supporto proxy

Esistono due posizioni in cui è possibile utilizzare un proxy sul tenant per installare l'operatore di monitoraggio Kubernetes. Questi possono essere sistemi proxy identici o separati:

Proxy necessario durante l'esecuzione del frammento di codice di installazione (utilizzando "curl") per connettere il sistema in cui il frammento viene eseguito all'ambiente Data Infrastructure Insights
Proxy necessario dal cluster Kubernetes di destinazione per comunicare con l'ambiente Data Infrastructure Insights

Se si utilizza un proxy per uno o per entrambi, per installare il monitor operativo Kubernetes è necessario innanzitutto assicurarsi che il proxy sia configurato in modo da consentire una buona comunicazione con l'ambiente Data Infrastructure Insights. Se si dispone di un proxy e si può accedere a Data Infrastructure Insights dal server/VM da cui si desidera installare l'operatore, è probabile che il proxy sia configurato correttamente.

Per il proxy utilizzato per installare il monitor operativo Kubernetes, prima di installare l'operatore, impostare le variabili di ambiente http_proxy/https_proxy. Per alcuni ambienti proxy, potrebbe essere necessario impostare la variabile no_proxy environment.

Per impostare le variabili, eseguire i seguenti passaggi sul sistema prima di installare l'operatore di monitoraggio Kubernetes:

Impostare le variabili di ambiente https_proxy e/o http_proxy per l'utente corrente:

Se il proxy da configurare non dispone dell'autenticazione (nome utente/password), eseguire il seguente comando:

 export https_proxy=<proxy_server>:<proxy_port>
.. Se il proxy da configurare dispone dell'autenticazione (nome utente/password), eseguire questo comando:

export http_proxy=<proxy_username>:<proxy_password>@<proxy_server>:<proxy_port>

Per il proxy utilizzato per il cluster Kubernetes e per comunicare con l'ambiente Data Infrastructure Insights, installare Kubernetes Monitoring Operator dopo aver letto tutte queste istruzioni.

Configurare la sezione proxy di AgentConfiguration in operator-config.yaml prima di distribuire l'operatore di monitoraggio Kubernetes.

agent:
  ...
  proxy:
    server: <server for proxy>
    port: <port for proxy>
    username: <username for proxy>
    password: <password for proxy>

    # In the noproxy section, enter a comma-separated list of
    # IP addresses and/or resolvable hostnames that should bypass
    # the proxy
    noproxy: <comma separated list>

    isTelegrafProxyEnabled: true
    isFluentbitProxyEnabled: <true or false> # true if Events Log enabled
    isCollectorsProxyEnabled: <true or false> # true if Network Performance and Map enabled
    isAuProxyEnabled: <true or false> # true if AU enabled
  ...
...

Utilizzando un repository di docker personalizzato o privato

Per impostazione predefinita, l'operatore di monitoring Kubernetes estrarrà le immagini dei container dal repository di Data Infrastructure Insights. Se hai un cluster Kubernetes utilizzato come destinazione per il monitoring e tale cluster è configurato in modo da estrarre solo le immagini dei container da un repository Docker o da un registro dei container personalizzato o privato, devi configurare l'accesso ai container necessari da Kubernetes Monitoring Operator.

Eseguire il frammento Image Pull dalla sezione di installazione di NetApp Monitoring Operator. Questo comando consente di accedere al repository Data Infrastructure Insights, di estrarre tutte le dipendenze dell'immagine per l'operatore e di disconnettersi dal repository Data Infrastructure Insights. Quando richiesto, inserire la password temporanea del repository fornita. Questo comando scarica tutte le immagini utilizzate dall'operatore, incluse le funzioni opzionali. Vedere di seguito per quali funzioni vengono utilizzate queste immagini.

Funzionalità principale dell'operatore e monitoraggio Kubernetes

monitoraggio netapp
ci-kube-rbac-proxy
ci-ksm
ci-telegraf
distroless-root-user

Registro eventi

ci-fluent-bit
ci-kukasub-esportatore-di-eventi

Mappa e performance di rete

ci-net-osservatore

Trasferire l'immagine del gestore nel repository del supporto privato/locale/aziendale in base alle policy aziendali. Verificare che i tag delle immagini e i percorsi delle directory per queste immagini nel repository siano coerenti con quelli nel repository Data Infrastructure Insights.

Modificare l'implementazione dell'operatore di monitoraggio in operator-deployment.yaml e modificare tutti i riferimenti alle immagini per utilizzare il repository Docker privato.

image: <docker repo of the enterprise/corp docker repo>/ci-kube-rbac-proxy:<ci-kube-rbac-proxy version>
image: <docker repo of the enterprise/corp docker repo>/netapp-monitoring:<version>

Modificare la configurazione dell'agente in operator-config.yaml in modo che rifletta la nuova posizione del responsabile del docker. Crea un nuovo imagePullSecret per il tuo repository privato, per maggiori dettagli vedi https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/

agent:
  ...
  # An optional docker registry where you want docker images to be pulled from as compared to CI's docker registry
  # Please see documentation link here: link:task_config_telegraf_agent_k8s.html#using-a-custom-or-private-docker-repository
  dockerRepo: your.docker.repo/long/path/to/test
  # Optional: A docker image pull secret that maybe needed for your private docker registry
  dockerImagePullSecret: docker-secret-name

Istruzioni per OpenShift

Se si utilizza OpenShift 4.6 o versione successiva, è necessario modificare la configurazione dell'agente in operator-config.yaml per attivare l'impostazione runPrivileged:

# Set runPrivileged to true SELinux is enabled on your kubernetes nodes
runPrivileged: true

OpenShift potrebbe implementare un ulteriore livello di sicurezza che potrebbe bloccare l'accesso ad alcuni componenti di Kubernetes.

Una nota sui segreti

Per rimuovere l'autorizzazione per l'operatore di monitoraggio Kubernetes a visualizzare segreti a livello del cluster, eliminare le seguenti risorse dal file operatore-setup.yaml prima di eseguire l'installazione:

 ClusterRole/netapp-ci-<namespace>-agent-secret-clusterrole
 ClusterRoleBinding/netapp-ci-<namespace>-agent-secret-clusterrolebinding

Se si tratta di un aggiornamento, eliminare anche le risorse dal cluster:

 kubectl delete ClusterRole/netapp-ci-<namespace>-agent-secret-clusterrole
 kubectl delete ClusterRoleBinding/netapp-ci-<namespace>-agent-secret-clusterrolebinding

Se l'analisi delle modifiche è attivata, modificare AgentConfiguration o operator-config.yaml per annullare il commento alla sezione di gestione delle modifiche e includere kindsToIgnoreFromWatch: '"secrets"' nella sezione di gestione delle modifiche. Notare la presenza e la posizione di virgolette singole e doppie in questa riga.

# change-management:
  ...
  # # A comma separated list of kinds to ignore from watching from the default set of kinds watched by the collector
  # # Each kind will have to be prefixed by its apigroup
  # # Example: '"networking.k8s.io.networkpolicies,batch.jobs", "authorization.k8s.io.subjectaccessreviews"'
  kindsToIgnoreFromWatch: '"secrets"'
  ...

Verifica dei checksum di Kubernetes

Il programma di installazione dell'agente Data Infrastructure Insights esegue controlli di integrità, ma alcuni utenti potrebbero voler eseguire le proprie verifiche prima di installare o applicare gli artefatti scaricati. Per eseguire un'operazione di solo download (invece del download e dell'installazione predefiniti), questi utenti possono modificare il comando di installazione dell'agente ottenuto dall'interfaccia utente e rimuovere l'opzione finale di "installazione".

Attenersi alla seguente procedura:

Copiare il frammento del programma di installazione dell'agente come indicato.
Invece di incollare il frammento in una finestra di comando, incollarlo in un editor di testo.
Rimuovere il file "--install" finale dal comando.
Copiare l'intero comando dall'editor di testo.

Incollarlo nella finestra di comando (in una directory di lavoro) ed eseguirlo.

Download e installazione (impostazione predefinita):

 installerName=cloudinsights-rhel_centos.sh … && sudo -E -H ./$installerName --download –-install
** Solo download:

installerName=cloudinsights-rhel_centos.sh … && sudo -E -H ./$installerName --download

Il comando solo download scaricherà tutti gli artefatti richiesti da Data Infrastructure Insights nella directory di lavoro. Gli artefatti includono, ma non possono essere limitati a:

uno script di installazione
un file di ambiente
File YAML
un file checksum firmato (sha256.signed)
Un file PEM (netapp_cert.pem) per la verifica della firma

Lo script di installazione, il file di ambiente e i file YAML possono essere verificati utilizzando l'ispezione visiva.

Il file PEM può essere verificato confermando che l'impronta digitale è la seguente:

 1A918038E8E127BB5C87A202DF173B97A05B4996
In particolare,

 openssl x509 -fingerprint -sha1 -noout -inform pem -in netapp_cert.pem
Il file checksum firmato può essere verificato utilizzando il file PEM:

 openssl smime -verify -in sha256.signed -CAfile netapp_cert.pem -purpose any
Una volta verificati correttamente tutti gli artefatti, l'installazione dell'agente può essere avviata eseguendo:

sudo -E -H ./<installation_script_name> --install

Tolerazioni e contamini

I DaemonSet netapp-ci-telegraf-ds, netapp-ci-fluent-bit-ds e netapp-ci-net-observer-L4-ds devono pianificare un pod su ogni nodo del cluster per raccogliere correttamente i dati su tutti i nodi. L'operatore è stato configurato in modo da tollerare alcuni segni noti. Se sono stati configurati dei tag personalizzati sui nodi, impedendo così l'esecuzione dei pod su ogni nodo, è possibile creare una tolleranza per tali tag "In AgentConfiguration". Se sono stati applicati dei tipi di manutenzione personalizzati a tutti i nodi del cluster, è necessario aggiungere anche le tolleranze necessarie all'implementazione dell'operatore per consentire la pianificazione e l'esecuzione del pod operatore.

Scopri di più su Kubernetes "Contamini e pedaggi".

Tornare al "Pagina Installazione dell'operatore di monitoraggio NetApp Kubernetes"

Risoluzione dei problemi

Alcuni elementi da provare in caso di problemi durante la configurazione dell'operatore di monitoring Kubernetes:

Problema: Prova:

Problema:	Prova:
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. Devi utilizzare Telegraf versione 2,0 o successiva e lo storage del cluster Kubernetes deve essere monitorato attivamente da Data Infrastructure Insights.
Sto vedendo messaggi nei log che assomigliano a quanto segue: E0901 15:21 178 v1:39,962145 1 k8s k8s Reflector.go:178] k8s.io/kube-state-metrics/internal/store/builder.go:352: Impossibile elencare *352.MutatingWebhookConfigurazione: Il server non ha trovato la risorsa richiesta E0901 15:21:43,168161 1:v1 Reflector.go.me.get coordinazione del server.go.oblies	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 di kube-state-metrics: Kubectl get deploy/kube-state-metrics -o jsonpath='{..image}' per evitare che questi messaggi si verifichino, gli utenti possono modificare la loro implementazione di kube-state-metrics per disabilitare le seguenti Leases: _Mutatingwebcooki_argomenti_conserviI possono usare le configurazioni_convalide_construzione_web: Resources=certificatesigningrequests,configmaps,crontowjobs,demonset,implementazioni,endpoint,horizontalpodautoscaler,ingassets,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims, validatingwebhookconfigurations,volumeattachments"
Vedo messaggi di errore da Telegraf che assomigliano 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 plugin-driven per la generazione di rapporti 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:172 1827 23" ott 2021 41Z:39-47 10 ip-31-23:41 telegraf[120]:-11 14"="errore di apertura. Ignorato. Open /etc/telegraf/.cache/snowflake/ocsp_Response_cache.json: No such file o directory\n" func="gosnowflake.(defaultLogger).errorf" file="log.go:23" Oct 2021 41Z:10 ip-1827-31:39-47 traf[172]: 11 14-23:41:120! Avvio di Telegraf 1.19.3	Si tratta di un problema noto. Per "Questo articolo di GitHub"ulteriori dettagli, fare riferimento a. Finché Telegraf è in funzione, gli utenti possono ignorare questi messaggi di errore.
Su Kubernetes, i miei pod Telegraf riportano il seguente errore: "Errore nell'elaborazione delle informazioni sui mountstats: 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".
Su Kubernetes, il mio pod ReplicaSet Telegraf riporta il seguente errore: [inputs.prometheus] errore nel plugin: Impossibile caricare la coppia di chiavi /etc/kubernetes/pki/etcd/server.crt:/etc/kubernetes/pki/etcd/server.key: Aprire /etc/kubernetes/pki/etcd/server.no	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 il Replica Set… kubectl edita rs telegraf-rs …e aggiunga le tolleranze appropriate alla specifica. 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 NetApp-monitoring kubectl delete ns NetApp-monitoring kubectl delete crd agents.monitoring.NetApp.com kubectl delete clusterrole agent-manager-ruolo-proxy agent-metrics-reader kubectl delete clusterrolebinding agent-manager-rolebinding agent-rolebinding-proxy-ading-cluster-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 usando il seguente comando: Kubectl -n <name-space> edit Agent 2. Contrassegna "Security-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 con i seguenti comandi: Kubectl Get psp (dovrebbe mostrare la politica di sicurezza Pod rimossa) kubectl Get all -n <namespace>
grep -i psp (dovrebbe mostrare che non viene trovato 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.
Acquisire o annotare in altro modo l'output dei seguenti comandi e contattare il team di supporto tecnico. kubectl -n netapp-monitoring get all kubectl -n netapp-monitoring describe all kubectl -n netapp-monitoring logs <monitoring-operator-pod> --all-containers=true kubectl -n netapp-monitoring logs <telegraf-pod> --all-containers=true	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. Prova: • Verifica 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","ambiente":"prod","level":"error","msg":"failed in validation. Motivo: La versione del kernel 3.10.0 è inferiore alla versione minima del kernel di 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. • Prendere nota del pod in stato Pending (in sospeso) e verificare 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.	Nei miei registri, subito dopo l'installazione dell'operatore di monitoraggio di Kubernetes, viene visualizzato quanto segue: [inputs.prometheus] errore nel plugin: 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: No such 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 alla "opzioni di configurazione". telegraf: … - Name: docker run-mode: - DaemonSet sostituzioni: - Chiave: DOCKER_UNIX_SOCK_PLACEHOLDER valore: unix://run/docker.sock … …	Vedo messaggi di errore ricorrenti simili ai seguenti nei miei registri Telegraf: 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 alla "opzioni di configurazione".	Mancano i dati involvedobject per alcuni registri eventi.
Assicurarsi di aver seguito i passaggi descritti nella "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, Data Infrastructure Insights ha ridefinito l'operatore per servire meglio i nostri utenti; affinché tali modifiche vengano completamente adottate, è necessario rimuovere il vecchio operatore e installare il nuovo.	I miei eventi kuowdi hanno interrotto inaspettatamente la segnalazione a Data Infrastructure Insights.
Recuperare il nome del pod dell'esportatore di eventi: `kubectl -n netapp-monitoring get pods	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 secondo necessità.
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 è in uno "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.
Vedo messaggi di avviso da Telegraf simili a quanto segue: W! [Inputs.diskio] Impossibile raccogliere il nome del disco per "vdc": Errore di lettura /dev/vdc: Nessun file o directory	Per l'operatore di monitoring Kubernetes, questi messaggi di avviso sono benigni e possono essere ignorati in modo sicuro. In alternativa, modificare la sezione telegraf in AgentConfiguration e impostare runDsPrivileged su true. Per ulteriori informazioni, fare riferimento alla "opzioni di configurazione dell'operatore".
Il mio Fluent-bit pod non funziona con i seguenti errori: [2024/10/16 14 16:16 23:23] [errore] [/src/fluent-bit/plugins/in_tail/tail_fs_inotify.c:tail,0 errno=2024] troppi file aperti [10/16 14/10/16 14:16:23] [errore] Inizializzazione input non riuscita [24/2024:360] [errore] [motore] Inizializzazione non riuscita	Prova a modificare le impostazioni di fsnotify nel cluster: sudo sysctl fs.inotify.max_user_instances (take note of setting) sudo sysctl fs.inotify.max_user_instances=<something larger than current setting> sudo sysctl fs.inotify.max_user_watches (take note of setting) sudo sysctl fs.inotify.max_user_watches=<something larger than current setting> Riavviare Fluent-bit. Nota: Per rendere queste impostazioni persistenti durante i riavvii dei nodi, è necessario inserire le seguenti righe in /etc/sysctl.conf fs.inotify.max_user_instances=<something larger than current setting> fs.inotify.max_user_watches=<something larger than current setting>

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. Devi utilizzare Telegraf versione 2,0 o successiva e lo storage del cluster Kubernetes deve essere monitorato attivamente da Data Infrastructure Insights.

Sto vedendo messaggi nei log che assomigliano a quanto segue: E0901 15:21 178 v1:39,962145 1 k8s k8s Reflector.go:178] k8s.io/kube-state-metrics/internal/store/builder.go:352: Impossibile elencare *352.MutatingWebhookConfigurazione: Il server non ha trovato la risorsa richiesta E0901 15:21:43,168161 1:v1 Reflector.go.me.get coordinazione del server.go.oblies

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 di kube-state-metrics: Kubectl get deploy/kube-state-metrics -o jsonpath='{..image}' per evitare che questi messaggi si verifichino, gli utenti possono modificare la loro implementazione di kube-state-metrics per disabilitare le seguenti Leases: _Mutatingwebcooki_argomenti_conserviI possono usare le configurazioni_convalide_construzione_web: Resources=certificatesigningrequests,configmaps,crontowjobs,demonset,implementazioni,endpoint,horizontalpodautoscaler,ingassets,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims,proxims, validatingwebhookconfigurations,volumeattachments"

Vedo messaggi di errore da Telegraf che assomigliano 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 plugin-driven per la generazione di rapporti 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:172 1827 23" ott 2021 41Z:39-47 10 ip-31-23:41 telegraf[120]:-11 14"="errore di apertura. Ignorato. Open /etc/telegraf/.cache/snowflake/ocsp_Response_cache.json: No such file o directory\n" func="gosnowflake.(*defaultLogger).errorf" file="log.go:23" Oct 2021 41Z:10 ip-1827-31:39-47 traf[172]: 11 14-23:41:120! Avvio di Telegraf 1.19.3

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

Su Kubernetes, i miei pod Telegraf riportano il seguente errore: "Errore nell'elaborazione delle informazioni sui mountstats: 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".

Su Kubernetes, il mio pod ReplicaSet Telegraf riporta il seguente errore: [inputs.prometheus] errore nel plugin: Impossibile caricare la coppia di chiavi /etc/kubernetes/pki/etcd/server.crt:/etc/kubernetes/pki/etcd/server.key: Aprire /etc/kubernetes/pki/etcd/server.no

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 il Replica Set… kubectl edita rs telegraf-rs …e aggiunga le tolleranze appropriate alla specifica. 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 NetApp-monitoring kubectl delete ns NetApp-monitoring kubectl delete crd agents.monitoring.NetApp.com kubectl delete clusterrole agent-manager-ruolo-proxy agent-metrics-reader kubectl delete clusterrolebinding agent-manager-rolebinding agent-rolebinding-proxy-ading-cluster-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 usando il seguente comando: Kubectl -n <name-space> edit Agent 2. Contrassegna "Security-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 con i seguenti comandi: Kubectl Get psp (dovrebbe mostrare la politica di sicurezza Pod rimossa) kubectl Get all -n <namespace>

grep -i psp (dovrebbe mostrare che non viene trovato 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.

Acquisire o annotare in altro modo l'output dei seguenti comandi e contattare il team di supporto tecnico.

 kubectl -n netapp-monitoring get all
 kubectl -n netapp-monitoring describe all
 kubectl -n netapp-monitoring logs <monitoring-operator-pod> --all-containers=true
 kubectl -n netapp-monitoring logs <telegraf-pod> --all-containers=true

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. Prova: • Verifica 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","ambiente":"prod","level":"error","msg":"failed in validation. Motivo: La versione del kernel 3.10.0 è inferiore alla versione minima del kernel di 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. • Prendere nota del pod in stato Pending (in sospeso) e verificare 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.

Nei miei registri, subito dopo l'installazione dell'operatore di monitoraggio di Kubernetes, viene visualizzato quanto segue: [inputs.prometheus] errore nel plugin: 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: No such 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 alla "opzioni di configurazione". telegraf: … - Name: docker run-mode: - DaemonSet sostituzioni: - Chiave: DOCKER_UNIX_SOCK_PLACEHOLDER valore: unix://run/docker.sock … …

Vedo messaggi di errore ricorrenti simili ai seguenti nei miei registri Telegraf: 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 alla "opzioni di configurazione".

Mancano i dati involvedobject per alcuni registri eventi.

Assicurarsi di aver seguito i passaggi descritti nella "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, Data Infrastructure Insights ha ridefinito l'operatore per servire meglio i nostri utenti; affinché tali modifiche vengano completamente adottate, è necessario rimuovere il vecchio operatore e installare il nuovo.

I miei eventi kuowdi hanno interrotto inaspettatamente la segnalazione a Data Infrastructure Insights.

Recuperare il nome del pod dell'esportatore di eventi:

`kubectl -n netapp-monitoring get pods

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 secondo necessità.

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 è in uno "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.

Vedo messaggi di avviso da Telegraf simili a quanto segue: W! [Inputs.diskio] Impossibile raccogliere il nome del disco per "vdc": Errore di lettura /dev/vdc: Nessun file o directory

Per l'operatore di monitoring Kubernetes, questi messaggi di avviso sono benigni e possono essere ignorati in modo sicuro. In alternativa, modificare la sezione telegraf in AgentConfiguration e impostare runDsPrivileged su true. Per ulteriori informazioni, fare riferimento alla "opzioni di configurazione dell'operatore".

Il mio Fluent-bit pod non funziona con i seguenti errori: [2024/10/16 14 16:16 23:23] [errore] [/src/fluent-bit/plugins/in_tail/tail_fs_inotify.c:tail,0 errno=2024] troppi file aperti [10/16 14/10/16 14:16:23] [errore] Inizializzazione input non riuscita [24/2024:360] [errore] [motore] Inizializzazione non riuscita

Prova a modificare le impostazioni di fsnotify nel cluster:

 sudo sysctl fs.inotify.max_user_instances (take note of setting)

 sudo sysctl fs.inotify.max_user_instances=<something larger than current setting>

 sudo sysctl fs.inotify.max_user_watches (take note of setting)

 sudo sysctl fs.inotify.max_user_watches=<something larger than current setting>

Riavviare Fluent-bit.

Nota: Per rendere queste impostazioni persistenti durante i riavvii dei nodi, è necessario inserire le seguenti righe in /etc/sysctl.conf

 fs.inotify.max_user_instances=<something larger than current setting>
 fs.inotify.max_user_watches=<something larger than current setting>

Ulteriori informazioni sono disponibili nella "Supporto"pagina o nella "Matrice di supporto Data Collector".