No veo un hipervínculo/conexión entre mi volumen persistente Kubernetes y el dispositivo de almacenamiento back-end correspondiente. Mi volumen persistente de Kubernetes se configura usando el nombre de host del servidor de almacenamiento.

Siga los pasos para desinstalar el agente de Telegraf existente y, a continuación, vuelva a instalar el último agente de Telegraf. Debe utilizar Telegraf versión 2.0 o posterior y Cloud Insights debe supervisar de forma activa el almacenamiento del clúster de Kubernetes.

Veo mensajes en los registros que se parecen a los siguientes:

E0901 15:21:39,962145 1 reflector.go:178] k8s.io/kube-state-metrics/internal/store/builder.go:352: Error al mostrar *v1.MutatingWebhookConfiguration: El servidor no pudo encontrar el recurso solicitado
E0901 15:21:43,168161 1 reflector.go:178] k8s.io/kube-state-metrics/internal/store/builder.go:352: Error al mostrar *v1.Lease: El servidor no pudo encontrar el recurso solicitado (get leases.coordination.k8s.io)
etc.

Estos mensajes pueden aparecer si ejecuta métricas de estado kube versión 2.0.0 o posteriores con versiones de Kubernetes inferiores a 1.20.


Para obtener la versión de Kubernetes:

kubectl version

Para obtener la versión kube-state-metrics:

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

Para evitar que estos mensajes ocurran, los usuarios pueden modificar su implementación de métricas de estado-kube para deshabilitar los siguientes arrendamientos:

mutatingwebhookconfigurations
validatingwebhookconfigurations
volumeattachments resources

Más específicamente, pueden usar el siguiente argumento de la CLI:

resources=certificatesigningrequests,configmaps,cronjobs,daemonsets, despliegues,extremos,horizontalpodautoscalers,ingresas,trabajos,limitranges, espacios de nombres,networkpolicies,nodos,persistentvolumeclaims,volúmenes persistentes, presupuestos poddisruptionpods,replicasets,replicationcontroladoras,cuotas de recursos, secretos,servicios,statefulsets,storage

La lista de recursos predeterminada es:

«certificacionessolicitudes,configmaps,cronjobs,daemonsets,despliegues, extremos,horizontalpodautoescaladores,entradas,trabajos,arrendamientos,limitadores, mutatingwebhookconfiguraciones,espacios de nombres,networkpolicies,nodos, persistentvolumeclaims,volúmenes persistentes,presupuestos de disrupción,pods,replicaciones, controladoras replicación,recursos,cuotas,fulstorelsets,servicios validatingwebhookconfigurations,volumeattachments

Veo mensajes de error de Telegraf parecidos a los siguientes, pero Telegraf se inicia y se ejecuta:

Oct 11 14:23:41 ip-172-31-39-47 systemd[1]: Inició el agente de servidor controlado por complementos para informar métricas en InfluxDB.
Oct 11 14:23:41 ip-172-31-39-47 telegraf[1827]: Time="2021-10-11T14:23:41Z" level=error msg="no se pudo crear el directorio de caché. /etc/telegraf/.cache/snowflake, err: mkdir /etc/telegraf/.ca
che: permiso denegado. Ignorado\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” level=error msg=“Error al abrir. Ignorada. abra /etc/telegraf/.cache/snowflake/ocsp_response_cache.json: no es así
Archivo o directorio\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! Arranque de Telegraf 1.19.3

Este es un problema conocido. Consulte "Este artículo de GitHub" para obtener más detalles. Mientras Telegraf esté activo y en funcionamiento, los usuarios pueden ignorar estos mensajes de error.

En Kubernetes, mis pods de Telegraf informan del siguiente error:
Error al procesar la información de mountstats: Error al abrir el archivo mountstats: /Hostfs/proc/1/mountstats, error: Open /hostfs/proc/1/mountstats: Permission denied

Si SELinux está habilitado y se aplica, es probable que impida que los pods de Telegraf accedan al archivo /proc/1/mountstats en el nodo Kubernetes. Para superar esta restricción, edite la configuración de agentconfiguration y active la configuración runPrivileged. Si quiere más detalles, consulte la "Instrucciones de OpenShift".

En Kubernetes, mi pod de Telegraf ReplicaSet está informando del siguiente error:

[inputs.prometheus] Error en plugin: No se pudo cargar keypair /etc/kubernetes/pki/etcd/server.crt:/etc/kubernetes/pki/etcd/server.key: Open /etc/kubernetes/pki/etcd/server.crt: No existe tal archivo o directorio

El Pod Telegraf ReplicaSet está diseñado para ejecutarse en un nodo designado como maestro o etcd. Si el Pod ReplicaSet no se está ejecutando en uno de estos nodos, obtendrá estos errores. Compruebe si los nodos maestro/etcd tienen sugerencias. Si lo hacen, añada las toleraciones necesarias al Telegraf ReplicaSet, telegraf-rs.

Por ejemplo, edite ReplicaSet…​

kubectl edit rs telegraf-rs

…​y añadir las toleraciones apropiadas a la especificación. A continuación, reinicie el Pod ReplicaSet.

Tengo un entorno PSP/PSA. ¿Afecta esto a mi operador de supervisión?

Si su clúster de Kubernetes se ejecuta con la política de seguridad de Pod (PSP) o la admisión de seguridad de Pod (PSA), debe actualizar al último operador de supervisión de Kubernetes. Siga estos pasos para actualizar al Operador actual con soporte para PSP/PSA:

1. Desinstalar el operador de monitorización anterior:

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-role agent-proxy-role agent-metrics-reader
kubectl delete clusterrolebinding agent-manager-rolebinding agent-proxy-rolebinding agent-cluster-admin-rolebinding

2. Instale la última versión del operador de supervisión.

Me encontré con problemas tratando de implementar el Operador, y tengo PSP/PSA en uso.

1. Edite el agente usando el siguiente comando:

kubectl -n agente de edición de <name-space>

2. Marque 'seguridad-política-habilitada' como 'falso'. Esto desactivará las políticas de seguridad de Pod y la admisión de seguridad de Pod y permitirá que el operador se despliegue. Confirme mediante los siguientes comandos:

Kubectl Get psp (debe mostrar la política de seguridad de Pod eliminada)
kubectl get all -n <namespace>

grep -i psp (debe mostrar que no se encuentra nada)

Se han visto errores "ImagePullBackoff"

Estos errores pueden verse si tiene un repositorio de Docker personalizado o privado y aún no ha configurado el operador de supervisión de Kubernetes para reconocerlo correctamente. Leer más acerca de la configuración para repo personalizado/privado.

Tengo un problema con la implementación de mi operador de supervisión y la documentación actual no me ayuda a resolverla.

Los pods de Net-Observer (Workload Map) en el espacio de nombres del operador están en CrashLoopBackOff

Estos pods corresponden al recopilador de datos de asignación de cargas de trabajo para la observabilidad de red. Pruebe lo siguiente:
• Compruebe los registros de uno de los pods para confirmar la versión mínima del kernel. Por ejemplo:

----
{«ci-tenant-id»: «your-tenant-id», «collector-cluster»: «your-k8s-cluster-name», «environment»: «prod», «level»: «error», «msg»: «failed in validation. Razón: La versión del kernel 3.10.0 es menor que la versión mínima del kernel de 4.18.0”, “Time”: “2022-11-09T08:23:08Z”}
----

• Net-Observer requiere que la versión del kernel de Linux sea al menos 4.18.0. Compruebe la versión del núcleo con el comando “uname -r” y asegúrese de que son >= 4.18.0

Los pods se ejecutan en el espacio de nombres del operador (predeterminado: Supervisión de netapp), pero no se muestran datos en la interfaz de usuario para el mapa de cargas de trabajo o las métricas de Kubernetes en consultas

Compruebe la configuración de hora en los nodos del clúster K8S. Para obtener informes precisos de auditoría y datos, se recomienda encarecidamente sincronizar la hora en el equipo del agente mediante el Protocolo de hora de red (NTP) o el Protocolo de hora de red simple (SNTP).

Algunos de los pods del observador de red en el espacio de nombres del operador están en estado Pendiente

NET-observer es un DaemonSet y ejecuta un pod en cada nodo del cluster k8s.
• Observe el pod que está en estado Pendiente y compruebe si está experimentando un problema de recursos para la CPU o la memoria. Asegúrese de que la memoria y la CPU requeridas estén disponibles en el nodo.

Veo lo siguiente en mis registros inmediatamente después de instalar el operador de supervisión de Kubernetes:

[inputs.prometheus] Error en plugin: Error al realizar la solicitud 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: Buscar kube-state-metrics.<namespace>.svc.cluster.local: No existe ese host

Este mensaje normalmente solo aparece cuando se instala un nuevo operador y el pod telegraf-rs está activo antes de que el pod ksm esté activo. Estos mensajes deben detenerse una vez que todos los pods se estén ejecutando.

No veo que se esté recopilando ninguna métrica para los cronjobs de Kubernetes que existen en mi clúster.

Compruebe la versión de Kubernetes (es decir, kubectl version). Si es v1,20.x o inferior, esta es una limitación esperada. La versión de métricas de estado de kube implementada con el operador de supervisión de Kubernetes solo admite v1.cronjob. Con Kubernetes 1,20.x y más abajo, el recurso cronjob está en v1beta.cronjob. Como resultado, kube-state-metrics no puede encontrar el recurso cronjob.

Después de instalar el operador, los pods de telegraf-ds ingresan CrashLoopBackOff y los registros de pod indican “su: Error de autenticación”.

Edite la sección telegraf en AgentConfiguration y establezca dockerMetricCollectionEnabled en false. Para obtener más información, consulte el apartado del operador "opciones de configuración".

NOTA: si está utilizando la edición federal de Cloud Insights, los usuarios con restricciones sobre el uso de su no podrán recopilar métricas de Docker porque el acceso al socket de Docker requiere ejecutar el contenedor de telegraf como root o usar su para agregar el usuario de telegraf al grupo de Docker. La recopilación de métricas de Docker y el uso de su están habilitados de forma predeterminada; para deshabilitar ambos, elimine la entrada telegraf.docker en el archivo AgentConfiguration:

…​
espec.:
…​
telégrafo:
…​
     - nombre: docker
            modo de ejecución:
              - DaemonSet
            sustituciones:
              - KEY: DOCKER_UNIX_SOCK_PLACEHOLDER
                valor: unix:///run/docker.sock
…​
…​

Veo mensajes de error repetidos parecidos a los siguientes en mis registros de Telegraf:

¡E! [Agent] Error al escribir en outputs.http: Post «\https://<tenant_url>/rest/v1/lake/ingest/influxdb»: Fecha límite de contexto excedida (Cliente. Se ha excedido el tiempo de espera de cabeceras)

Edite la sección telegraf en AgentConfiguration y aumente outputTimeout a 10s. Para obtener más información, consulte el apartado del operador "opciones de configuración".

Faltan datos involved dobject para algunos registros de eventos.

Asegúrese de haber seguido los pasos de la "Permisos" sección anterior.

¿Por qué veo que funcionan dos pods del operador de supervisión, uno llamado netapp-ci-monitoring-operator-<pod> y otro llamado monitoring-operator-<pod>?

A partir del 12 de octubre de 2023, Cloud Insights ha reestructurado el operador para servir mejor a nuestros usuarios; para que esos cambios se adopten plenamente, debe hacerlo retire el operador antiguo y.. instale la nueva.

Los eventos de My kubernetes dejaron de generar informes inesperadamente para Cloud Insights.

grep event-exporter

awk '{print $1}'

sed 's/event-exporter./event-exporter/'`
Debe ser «exportador-de-centro-eventos-netapp» o «exportador-de-eventos». A continuación, edite el agente de supervisión kubectl -n netapp-monitoring edit agent, Y establezca el valor de LOG_FILE para reflejar el nombre de pod de evento-exportador adecuado que se encuentra en el paso anterior. Más concretamente, EL ARCHIVO_REGISTRO debe establecerse en «/var/log/containers/netapp-ci-event-exporter.log» o «/var/log/containers/event-exporter*.log»

…​.
fluent-bit:
…​
- name: event-exporter-ci
substitutions:
- key: LOG_FILE
values:
- /var/log/containers/netapp-ci-event-exporter*.log
…​
…​.
Alternativamente, uno también puede desinstalar y.. vuelva a instalar el agente.

Estoy viendo que los pods han sido puestos en marcha por el operador de supervisión de Kubernetes se han bloqueado debido a la falta de recursos.

Consulte el operador de supervisión de Kubernetes "opciones de configuración" Para aumentar los límites de la CPU o la memoria según sea necesario.

La falta de una imagen o una configuración no válida provocó que los pods de métricas de estado de netapp-ci-kube no se iniciaran o estuvieran listos. Ahora, StatefulSet se bloquea y los cambios de configuración no se aplican a los pods de métricas de estado-ci-kube.

El StatefulSet está en a. "roto" estado. Después de resolver cualquier problema de configuración, renueve los pods de métricas de estado-ci-kube-state.

Los pods de métricas de estado-ci-kube-state no se pueden iniciar tras ejecutar una actualización del operador de Kubernetes y lanzar ErrImagePull (no lograr extraer la imagen).

Intente restablecer los pods manualmente.

Los mensajes de «Event descarded as as as older then maxEventAgeSeconds» se observan para mi clúster de Kubernetes en Log Analysis.

Modifique el Operador agentconfiguration y aumente el event-exporter-maxEventAgeSeconds (es decir, a 60s), event-exporter-kubeQPS (es decir, a 100) y event-exporter-kubeBurst (es decir, a 500). Para obtener más información sobre estas opciones de configuración, consulte "opciones de configuración" página.

Telegraf advierte de, o se bloquea debido a, memoria bloqueable insuficiente.

Intente aumentar el límite de memoria bloqueable para Telegraf en el sistema operativo/nodo subyacente. Si aumentar el límite no es una opción, modifique la configuración de agentconfiguration NKMO y establezca UNPROTECTED en TRUE. Esto indicará a Telegraf que no intente reservar páginas de memoria bloqueadas. Aunque esto puede suponer un riesgo para la seguridad, ya que los secretos descifrados se pueden intercambiar en el disco, permite su ejecución en entornos en los que no es posible reservar la memoria bloqueada. Para obtener más información sobre las opciones de configuración UNPROTECTED, consulte la "opciones de configuración" página.