Je ne vois pas de lien hypertexte/connexion entre mon volume persistant Kubernetes et le périphérique de stockage back-end correspondant. Mon volume persistant Kubernetes est configuré en utilisant le nom d'hôte du serveur de stockage.

Procédez comme suit pour désinstaller l'agent Telegraf existant, puis réinstaller l'agent Telegraf le plus récent. Vous devez utiliser Telegraf version 2.0 ou ultérieure et le stockage en cluster Kubernetes doit être activement surveillé par Cloud Insights.

Je vois des messages dans les journaux qui ressemblent à ce qui suit :

E0901 15:21:39.962145 1 Reflector.Go:178] k8s.io/kube-state-metrics/internal/store/builder.Go:352: Échec de la liste *v1.MutatingWebhookConfiguration: Le serveur n'a pas pu trouver la ressource demandée
E0901 15:21:43.168161 1 Reflector.Go:178] k8s.io/kube-state-metrics/Internal/store/Builder.Go:352: Échec de la liste *v1.Lease : le serveur n'a pas trouvé la ressource demandée (get Leans.coordination.k8s.io)
etc

Ces messages peuvent se produire si vous exécutez des metrics d'état kube version 2.0.0 ou supérieure avec les versions Kubernetes inférieures à 1.20.


Pour obtenir la version Kubernetes :

kubectl version

Pour obtenir la version kube-state-metrics :

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

Pour empêcher ces messages de se produire, les utilisateurs peuvent modifier leur déploiement de mesures d'état kube pour désactiver les baux suivants :

mutatingwebhookconfigurations
validagewebhookconfigurations
ressources de pièces jointes volumiques

Plus précisément, ils peuvent utiliser l'argument CLI suivant :

ressources=certificatesigningrequests,configmaps,cronjobs,demonsets, déploiements,noeuds finaux,horizontalpodautocalers,ingresses,travaux,limites, namespaces,networkpolicies,nodes,perstentvolumeseclaims,persistent volumes, podtionbudgets,pods,réplicasets,réplicationscontrolleurs,resresresources cequitas, storageclasses,secrets,services

La liste de ressources par défaut est :

« certificatesigningrequests,configmaps,cronjobs,demonsets,déploiements, terminaux,horizontalpodautocalers,ingresses,travaux,baux,limites, mutatingwebhookconfigurations,namespaces,netfulpolicies,nodes, distentesvolueclaims,persentvolumes,podtionbudgets,pods,réplicasetts validagewebhookconfigurations,pièces jointes volumiques »

Je vois que les messages d'erreur de Telegraf ressemblent à ce qui suit, mais Telegraf démarre et s'exécute :

Oct 11 14:23:41 ip-172-31-39-47 systemd[1]: A démarré l'agent serveur basé sur le plugin pour le reporting des mesures dans InfluxDB.
Oct 11 14:23:41 ip-172-31-39-47 telegraf[1827] : heure="2021-10-11T14:23:41Z" level=erreur msg="Impossible de créer le répertoire de cache. /etc/telegraf/.cache/snowflake, err : mkdir /etc/telegraf/.ca
che : autorisation refusée. Ignoré\n" func="gosnowflake.(*defaultLogger).Errorf" file="log.Go:120"
Oct 11 14:23:41 ip-172-31-39-47 telegraf[1827]: Time="2021-10-11T14:23:41Z" niveau=error msg="failed to open. Ignoré. ouvrez /etc/telegraf/.cache/snowflake/ocsp_response_cache.json : non
File or Directory\n" func="gosnowflake.(*defaultLogger).Errorf" file="log.Go:120"
Oct 11 14:23:41 ip-172-31-39-47 telegraf[1827]: 2021-10-11T14:23:41Z I! Démarrage de Telegraf 1.19.3

Il s'agit d'un problème connu. Reportez-vous à la section "Article GitHub" pour en savoir plus. Tant que Telegraf est opérationnel, les utilisateurs peuvent ignorer ces messages d'erreur.

Sur Kubernetes, mon ou mes pod(s) Telegraf signalent l'erreur suivante :
"Erreur lors du traitement des info mountstats: Impossible d'ouvrir le fichier mountstats: /Hostfs/proc/1/mountstats, erreur: Open /hostfs/proc/1/mountstats: Permission denied"

Si SELinux est activé et applique, il empêche probablement le ou les pod(s) Telegraf d'accéder au fichier /proc/1/mountstats sur le nœud Kubernetes. Pour contourner cette restriction, modifiez la configuration d'agentconfiguration et activez le paramètre runPrivileged. Pour plus de détails, voir : https://docs.netapp.com/us-en/cloudinsights/task_config_telegraf_agent_k8s.html#openshift-instructions.

Sur Kubernetes, mon pod ReplicaSet Telegraf rapporte l'erreur suivante :

[inputs.prometheus] erreur dans le plug-in : impossible de charger keypair /etc/kubernetes/pki/etcd/Server.crt:/etc/kubernetes/pki/etcd/Server.key: Ouvrir /etc/kubernetes/pki/etcd/Server.crt: Pas de fichier ou de répertoire de ce type

Le pod Télégraf ReplicaSet est conçu pour s'exécuter sur un nœud désigné comme maître ou pour ETCD. Si le pod ReplicaSet n'est pas en cours d'exécution sur l'un de ces nœuds, vous obtenez ces erreurs. Vérifiez si vos nœuds maître/ETCD ont des astuces sur eux. S'ils le font, ajoutez les tolérances nécessaires à Telegraf ReplicaSet, telegraf-RS.

Par exemple, modifiez ReplicaSet…​

kubectl éditer rs telegraf-rs

…​et ajouter les tolérances appropriées à la spécification. Redémarrez ensuite le pod ReplicaSet.

J'ai un environnement PSP/PSA. Cela affecte-t-il mon opérateur de surveillance ?

Si votre cluster Kubernetes s'exécute avec la règle de sécurité Pod (PSP) ou l'admission de sécurité Pod (PSA) sur place, vous devez effectuer la mise à niveau vers l'opérateur de surveillance Kubernetes le plus récent. Procédez comme suit pour effectuer la mise à niveau vers l'opérateur actuel avec prise en charge de PSP/PSA :

1. Désinstaller l'opérateur de surveillance précédent :

kubectl delete agent agent-monitoring-netapp -n netapp-monitoring
kubectl delete ns netapp-monitoring
kubectl delete crd agents.monitoring.netapp.com
kubectl delete clusterrole agent-manager-role agent-proxy-role agent-metrics-reader
kubectl delete clusterrolebinding agent-manager-rolebinding agent-proxy-rolebinding agent-cluster-admin-rolebinding

2. Installer la dernière version du moniteur.

J'ai rencontré des problèmes lors de la tentative de déploiement de l'opérateur, et j'ai utilisé PSP/PSA.

1. Modifiez l'agent à l'aide de la commande suivante :

kubectl -n agent de modification <name-space>

2. Marquez « sécurité-stratégie-activée » comme « faux ». Ceci désactivera les stratégies de sécurité du Pod et l'admission de sécurité du Pod et permettra à l'opérateur de déployer. Confirmer à l'aide des commandes suivantes :

Kubectl get psp (doit afficher la politique de sécurité du Pod supprimée)
kubectl get all -n <namespace>

grep -i psp (devrait montrer que rien n'est trouvé)

Erreurs « ImagePullBackoff » détectées

Ces erreurs peuvent se produire si vous disposez d'un référentiel docker personnalisé ou privé et que vous n'avez pas encore configuré l'opérateur de surveillance Kubernetes pour qu'il le reconnaisse correctement. En savoir plus a propos de la configuration pour repo personnalisé/privé.

J'ai un problème avec mon déploiement d'opérateur de surveillance, et la documentation actuelle ne m'aide pas à le résoudre.

Les pods net-observateur (Workload Map) de l'espace de noms de l'opérateur se trouvent dans CrashLoopBackOff

Ces pods correspondent au collecteur de données Workload Map pour l'observabilité réseau. Essayez les solutions suivantes :
• Vérifiez les journaux de l'un des modules pour confirmer la version minimale du noyau. Par exemple :

----
{"ci-tenant-id":"votre-tenant-id","collector-cluster":"votre-k8s-cluster-name","environment":"prod","level":"error","msg":"échec de la validation. Raison : la version du noyau 3.10.0 est inférieure à la version minimale du noyau 4.18.0","Time":"2022-11-09T08:23:08Z"}
----

• Les modules Net-observateur nécessitent une version du noyau Linux d'au moins 4.18.0. Vérifiez la version du noyau à l'aide de la commande “uname -r” et assurez-vous qu'ils sont >= 4.18.0

Les pods s'exécutent dans l'espace de noms Operator (par défaut : surveillance netapp), mais aucune donnée n'est affichée dans l'interface pour la carte des workloads ou les metrics Kubernetes dans les requêtes

Vérifiez le réglage de l'heure sur les nœuds du cluster K8S. Pour un audit et un reporting précis des données, il est vivement recommandé de synchroniser l'heure sur l'ordinateur de l'agent à l'aide du protocole NTP (Network Time Protocol) ou SNTP (simple Network Time Protocol).

Certains des pods net-observateur dans l'espace de noms de l'opérateur sont à l'état en attente

Net-observateur est un DemonSet et exécute un pod dans chaque nœud du cluster k8s.
• Notez le pod qui est à l'état en attente et vérifiez s'il rencontre un problème de ressource pour le processeur ou la mémoire. Assurez-vous que la mémoire et le processeur requis sont disponibles dans le nœud.

Je vois ce qui suit dans mes journaux immédiatement après l'installation de l'opérateur de surveillance Kubernetes :

[inputs.prometheus] erreur dans le plug-in : erreur lors de la demande HTTP à http://kube-state-metrics.<namespace>.svc.cluster.local:8080/metrics: Obtenez http://kube-state-metrics.<namespace>.svc.cluster.local:8080/metrics: dial tcp: lookup kube-state-metrics.<namespace>.svc.cluster.local: pas d'hôte de ce type

Ce message n'apparaît généralement que lorsqu'un nouvel opérateur est installé et que le module telegraf-RS est en marche avant que le module ksm ne soit en marche. Ces messages doivent s'arrêter une fois que tous les modules sont en cours d'exécution.

Je ne vois aucun indicateur collecté pour les cronjobs Kubernetes qui existent dans mon cluster.

Vérifiez votre version Kubernetes (c'est-à-dire kubectl version). S'il est v1.20.x ou inférieur, il s'agit d'une limitation attendue. La version de kube-state-metrics déployée avec l'opérateur de surveillance Kubernetes ne prend en charge que v1.cronjob. Avec Kubernetes 1.20.x et versions antérieures, la ressource cronjob est à v1beta.cronjob. Par conséquent, les indicateurs d'état kube ne peuvent pas trouver la ressource cronjob.

Après l'installation de l'opérateur, les modules telegraf-ds entrent dans CrashLoopBackOff et les journaux du pod indiquent « su: Authentication failure ».

Modifiez la section telegraf dans AgentConfiguration et définissez dockerMetricCollectionEnabled sur FALSE. Pour plus de détails, reportez-vous au manuel de l'opérateur "options de configuration".

REMARQUE : si vous utilisez l'édition fédérale de Cloud Insights, les utilisateurs avec des restrictions sur l'utilisation de su ne pourront pas collecter de metrics docker car l'accès au socket docker nécessite l'exécution du conteneur telegraf en tant que root ou l'utilisation de su pour ajouter l'utilisateur telegraf au groupe docker. La collecte de mesures Docker et l'utilisation de su sont activées par défaut ; pour les désactiver, supprimez l'entrée telegraf.docker dans le fichier AgentConfiguration :

…​
spéc. :
…​
telegraf :
…​
     - nom: docker
            mode run :
              - DemonSet
            substitutions :
              - CLÉ : DOCKER_UNIX_SOCK_PLACEHOLDER
                valeur : unix:///run/docker.sock
…​
…​

Je vois des messages d'erreur récurrents ressemblant à ce qui suit dans mes journaux Telegraf :

E ! [Agent] erreur lors de l'écriture dans les sorties.http: Post "https://<tenant_url>/rest/v1/lake/ingest/influxdb": Délai de contexte dépassé (client.Timeout dépassé lors de l'attente des en-têtes)

Modifiez la section telegraf dans AgentConfiguration et définissez dockerMetricCollectionEnabled sur FALSE. Pour plus de détails, reportez-vous au manuel de l'opérateur "options de configuration".

Il me manque des données involvedobject pour certains journaux d'événements.

Assurez-vous d'avoir suivi les étapes de la "Autorisations" section ci-dessus.

Pourquoi deux modules d'opérateurs de surveillance s'exécutent, l'un nommé netapp-ci-monitoring-Operator-<pod> et l'autre Monitoring-Operator-<pod> ?

Depuis le 12 octobre 2023, Cloud Insights a décidé de réorganiser l'opérateur pour mieux servir nos utilisateurs ; pour que ces changements soient pleinement adoptés, vous devez retirez l'ancien opérateur et installez le nouveau.

Mes événements kubernetes ont cessé de générer des rapports sur Cloud Insights de manière inattendue.

grep event-exporter

awk '{print $1}'

sed 's/event-exporter./event-exporter/'`
Il doit être « netapp-ci-event-exportatrice » ou « event-exportatrice ». Modifiez ensuite l'agent de surveillance kubectl -n netapp-monitoring edit agent, Et définissez la valeur de LOG_FILE pour qu'elle reflète le nom de pod d'exportation d'événements approprié trouvé à l'étape précédente. Plus précisément, LOG_FILE doit être défini sur «/var/log/containers/netapp-ci-event-exportatrice.log » ou «/var/log/containers/event-exportatrice*.log ».

…​.
fluent-bit:
…​
- name: event-exporter-ci
substitutions:
- key: LOG_FILE
values:
- /var/log/containers/netapp-ci-event-exporter*.log
…​
…​.
Vous pouvez également le faire désinstaller et réinstallez l'agent.

J'constate que le ou les pods déployés par l'opérateur de surveillance Kubernetes sont en panne en raison de ressources insuffisantes.

Reportez-vous à l'opérateur de surveillance Kubernetes "options de configuration" Pour augmenter les limites du CPU et/ou de la mémoire selon les besoins.