Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Instalación y configuración del operador de supervisión de Kubernetes

11/25/2024 Colaboradores

PDF

Data Infrastructure Insights ofrece el Operador de Monitoreo de Kubernetes para la colección de Kubernetes. Vaya a Kubernetes > Colectores > +Kubernetes Collector para implementar un nuevo operador.

Antes de instalar el operador de supervisión de Kubernetes

Consulte "Requisitos previos"la documentación antes de instalar o actualizar el operador de supervisión de Kubernetes.

Instalación del operador de supervisión de Kubernetes

Instrucciones del operador de monitorización

Pasos para instalar el agente del operador de supervisión de Kubernetes en Kubernetes:

Introduzca un nombre de clúster y un espacio de nombres únicos. Si es actualizando de un operador de Kubernetes anterior, utilice el mismo nombre de clúster y espacio de nombres.
Una vez introducidos, puede copiar el fragmento del comando de descarga en el portapapeles.
Pegue el fragmento en una ventana bash y ejecútelo. Se descargarán los archivos de instalación del operador. Tenga en cuenta que el fragmento tiene una clave única y es válido durante 24 horas.
Si tiene un repositorio personalizado o privado, copie el fragmento opcional Image pull, péguelo en un shell bash y ejecútelo. Una vez extraídas las imágenes, cópielas en tu repositorio privado. Asegúrese de mantener las mismas etiquetas y la misma estructura de carpetas. Actualice las rutas de acceso en operator-deployment.yaml, así como la configuración del repositorio de Docker en operator-config.yaml.
Si lo desea, revise las opciones de configuración disponibles, como la configuración de repositorio privado o proxy. Puedes leer más sobre "opciones de configuración".
Cuando esté listo, despliegue el Operador copiando el fragmento de aplicación kubectl, descargándolo y ejecutándolo.
La instalación se realiza automáticamente. Cuando haya terminado, haga clic en el botón Next.
Una vez finalizada la instalación, haga clic en el botón Next. Asegúrese también de eliminar o almacenar de forma segura el archivo operator-secrets.yaml.

Si está utilizando un proxy, lea acerca de configurando proxy.

Si tiene un repositorio personalizado, lea acerca de utilizando un repositorio de docker personalizado/privado.

Componentes de supervisión de Kubernetes

Información de la infraestructura de datos La supervisión de Kubernetes se compone de cuatro componentes de supervisión:

Métricas de cluster
Rendimiento de red y mapa (opcional)
Registros de eventos (opcional)
Análisis de cambios (opcional)

Los componentes opcionales anteriores están habilitados de forma predeterminada para cada recopilador de Kubernetes; si decide que no necesita un componente para un recopilador en particular, puede deshabilitarlo navegando a Kubernetes > Colectores y seleccionando Modify Deployment en el menú de tres puntos del recopilador a la derecha de la pantalla.

Modificar el menú de implementación en la página de la lista de recopiladores de Kubernetes

La pantalla muestra el estado actual de cada componente y le permite desactivar o activar componentes para ese recopilador según sea necesario.

Opciones de implementación de Mody, 700

Actualizar

Actualiza al operador de supervisión de Kubernetes más reciente

Determine si existe una AgentConfiguration con el operador existente (si el espacio de nombres no es el valor predeterminado netapp-monitoring, sustituya el espacio de nombres adecuado):

 kubectl -n netapp-monitoring get agentconfiguration netapp-monitoring-configuration
Si existe una configuración de agente:

Instale El último operador sobre el operador existente.
- Asegúrese de que está extracción de las imágenes de contenedor más recientesutilizando un repositorio personalizado.

Si la configuración de agente no existe:

Anote el nombre de su clúster como reconocido por Data Infrastructure Insights (si su espacio de nombres no es la supervisión NetApp predeterminada, sustituya el espacio de nombres adecuado):
```
 kubectl -n netapp-monitoring get agent -o jsonpath='{.items[0].spec.cluster-name}'
* Cree una copia de seguridad del Operador existente (si su espacio de nombres no es el control de netapp predeterminado, sustituya el espacio de nombres adecuado):
```
```
 kubectl -n netapp-monitoring get agent -o yaml > agent_backup.yaml
* <<to-remove-the-kubernetes-monitoring-operator,Desinstalar>> El operador existente.
* <<installing-the-kubernetes-monitoring-operator,Instale>> El último operador.
```
- Utilice el mismo nombre de clúster.
- Después de descargar los últimos archivos YAML del operador, transfiera cualquier personalización encontrada en agent_backup.yaml al operator-config.yaml descargado antes de implementar.
- Asegúrese de que está extracción de las imágenes de contenedor más recientesutilizando un repositorio personalizado.

Detener e iniciar el operador de supervisión de Kubernetes

Para detener el operador de supervisión de Kubernetes:

 kubectl -n netapp-monitoring scale deploy monitoring-operator --replicas=0
Para iniciar el operador de supervisión de Kubernetes:

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

Desinstalando

Para eliminar el operador de supervisión de Kubernetes

Tenga en cuenta que el espacio de nombres predeterminado para el operador de supervisión de Kubernetes es la «supervisión de netapp». Si ha definido su propio espacio de nombres, sustituya este espacio de nombres en estos y todos los comandos y archivos subsiguientes.

Las versiones más recientes del operador de supervisión se pueden desinstalar con los siguientes comandos:

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>

Si el operador de supervisión se ha desplegado en su propio espacio de nombres dedicado, suprima el espacio de nombres:

 kubectl delete ns <NAMESPACE>
Si el primer comando devuelve “no se han encontrado recursos”, utilice las siguientes instrucciones para desinstalar versiones anteriores del operador de supervisión.

Ejecute cada uno de los comandos siguientes en orden. Dependiendo de su instalación actual, algunos de estos comandos pueden devolver mensajes de ‘no se ha encontrado el objeto’. Estos mensajes pueden ignorarse con seguridad.

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>

Si se ha creado previamente una restricción de contexto de seguridad:

kubectl delete scc telegraf-hostaccess

Acerca de las métricas de estado de Kube

El operador de supervisión de Kubernetes de NetApp instala sus propias métricas de estado kube para evitar conflictos con otras instancias.

Para obtener más información sobre Kube-State-Metrics, consulte "esta página".

Configuración/Personalización del Operador

Estas secciones contienen información sobre cómo personalizar la configuración del operador, cómo trabajar con proxy, cómo usar un repositorio de Docker personalizado o privado o cómo trabajar con OpenShift.

Opciones de configuración

La configuración más comúnmente modificada se puede configurar en el recurso personalizado AgentConfiguration. Puede editar este recurso antes de desplegar el operador editando el archivo operator-config.yaml. Este archivo incluye ejemplos de configuración comentados. Consulte la lista de "ajustes disponibles"para obtener la versión más reciente del operador.

También puede editar este recurso después de desplegar el operador mediante el siguiente comando:

 kubectl -n netapp-monitoring edit AgentConfiguration
Para determinar si la versión implementada del operador admite AgentConfiguration, ejecute el siguiente comando:

 kubectl get crd agentconfigurations.monitoring.netapp.com
Si ve un mensaje “Error from server (NotFound)”, su operador debe actualizarse antes de poder usar AgentConfiguration.

Configurar el soporte del proxy

Hay dos lugares en los que puede usar un proxy en su inquilino para instalar el operador de monitoreo de Kubernetes. Pueden ser los mismos sistemas proxy o independientes:

Proxy necesario durante la ejecución del fragmento de código de instalación (mediante «curl») para conectar el sistema donde se ejecuta el fragmento a su entorno de Data Infrastructure Insights
Proxy que necesita el clúster de Kubernetes de destino para comunicarse con su entorno de Data Infrastructure Insights

Si usas un proxy para una o ambas de ellas, para instalar el Monitor Operativo de Kubernetes, primero debes asegurarte de que tu proxy esté configurado para permitir una buena comunicación con tu entorno de Información de Infraestructura de Datos. Si tiene un proxy y puede acceder a Data Infrastructure Insights desde el servidor/VM desde el que desea instalar el Operador, es probable que su proxy esté configurado correctamente.

Para el proxy utilizado para instalar el monitor operativo de Kubernetes, antes de instalar el operador, defina las variables de entorno http_proxy/https_proxy. En algunos entornos proxy, también es posible que tenga que establecer la variable no_proxy Environment.

Para configurar las variables, realice los siguientes pasos en su sistema antes de instalar el Operador de monitoreo de Kubernetes:

Establezca las variables de entorno https_proxy y/o http_proxy para el usuario actual:

Si el proxy que se está estableciendo no tiene autenticación (nombre de usuario/contraseña), ejecute el siguiente comando:

 export https_proxy=<proxy_server>:<proxy_port>
.. Si el proxy que se está estableciendo tiene autenticación (nombre de usuario/contraseña), ejecute este comando:

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

Para que el proxy utilizado para su clúster de Kubernetes se comunique con su entorno de Información de infraestructura de datos, instale el operador de supervisión de Kubernetes después de leer todas estas instrucciones.

Configure la sección proxy de AgentConfiguration en operator-config.yaml antes de implementar el operador de supervisión de 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
  ...
...

Uso de un repositorio de Docker personalizado o privado

De forma predeterminada, el operador de supervisión de Kubernetes extraerá imágenes de contenedor del repositorio de información de infraestructura de datos. Si tiene un clúster de Kubernetes utilizado como destino para la supervisión, y ese clúster está configurado para extraer solo imágenes de contenedor de un repositorio Docker privado o personalizado o un registro de contenedores, debe configurar el acceso a los contenedores que necesita el operador de supervisión de Kubernetes.

Ejecute «Image pull Snippet» desde el icono de instalación del operador de supervisión de NetApp. Este comando iniciará sesión en el repositorio de Data Infrastructure Insights, extraerá todas las dependencias de imágenes del operador y cerrará la sesión en el repositorio de Data Infrastructure Insights. Cuando se le solicite, introduzca la contraseña temporal del repositorio proporcionada. Este comando descarga todas las imágenes utilizadas por el operador, incluidas las funciones opcionales. Consulte a continuación las funciones para las que se utilizan estas imágenes.

Funcionalidad del operador principal y supervisión de Kubernetes

supervisión de netapp
ci-kube-rbac-proxy
ci-ksm
ci-telegraf
usuario raíz sin interrupciones

Registro de eventos

bits ci-fluido
ci-kubernetes-event-exporter

Rendimiento de red y mapa

ci-net-observador

Introduzca la imagen del operador docker en el repositorio de su proveedor de servicios de empresa/local/privado de acuerdo con las políticas de su empresa. Asegúrese de que las etiquetas de imagen y las rutas de directorio a estas imágenes del repositorio sean coherentes con las del repositorio de Data Infrastructure Insights.

Edite el despliegue de operador de supervisión en operator-deployment.yaml y modifique todas las referencias de imagen para utilizar su repositorio Docker privado.

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>

Edite AgentConfiguration en operator-config.yaml para reflejar la nueva ubicación de repositorio de Docker. Cree una nueva imagePullSecret para su repositorio privado, para más detalles consulte 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

Instrucciones de OpenShift

Si se ejecuta en OpenShift 4,6 o superior, debe editar la configuración de AgentConfiguration en operator-config.yaml para activar la configuración runPrivileged:

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

OpenShift puede implementar un nivel de seguridad añadido que puede bloquear el acceso a algunos componentes de Kubernetes.

Una nota sobre los secretos

Para eliminar el permiso del operador de supervisión de Kubernetes para ver los secretos en todo el clúster, elimine los siguientes recursos del archivo operator-setup.yaml antes de instalar:

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

Si se trata de una actualización, suprima también los recursos del clúster:

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

Si el análisis de cambios está activado, modifique AgentConfiguration o operator-config.yaml para anular el comentario de la sección de gestión de cambios e incluya kindsToIgnoreFromWatch: ''secrets'' en la sección de gestión de cambios. Observe la presencia y posición de comillas simples y dobles en esta línea.

# 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"'
  ...

Verificando sumas de comprobación de Kubernetes

El instalador del agente de Data Infrastructure Insights realiza comprobaciones de integridad, pero es posible que algunos usuarios deseen realizar sus propias verificaciones antes de instalar o aplicar artefactos descargados. Para realizar una operación de sólo descarga (a diferencia de la descarga e instalación predeterminadas), estos usuarios pueden editar el comando de instalación del agente obtenido de la interfaz de usuario y eliminar la opción de instalación final.

Siga estos pasos:

Copie el fragmento de instalador del agente como se indica.
En lugar de pegar el fragmento en una ventana de comandos, péguelo en un editor de texto.
Retire el “--install” final del comando.
Copie el comando entero desde el editor de texto.

Ahora péguela en la ventana de comandos (en un directorio de trabajo) y ejecútela.

Descargar e instalar (predeterminado):

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

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

El comando download-only descargará todos los artefactos necesarios de Data Infrastructure Insights en el directorio de trabajo. Los artefactos incluyen, pero no se pueden limitar a:

una secuencia de comandos de instalación
un archivo de entorno
Archivos YAML
un archivo de suma de comprobación firmado (sha256.firmadas)
Un archivo PEM (netapp_cert.pem) para la verificación de firmas

La secuencia de comandos de instalación, el archivo de entorno y los archivos YAML se pueden verificar mediante inspección visual.

El archivo PEM puede verificarse confirmando que su huella digital es la siguiente:

 1A918038E8E127BB5C87A202DF173B97A05B4996
Más específicamente,

 openssl x509 -fingerprint -sha1 -noout -inform pem -in netapp_cert.pem
El archivo de suma de comprobación firmado se puede verificar mediante el archivo PEM:

 openssl smime -verify -in sha256.signed -CAfile netapp_cert.pem -purpose any
Una vez que todos los artefactos han sido verificados satisfactoriamente, la instalación del agente se puede iniciar ejecutando:

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

Toleraciones y daños

Los netapp-ci-telegraf-ds, netapp-ci-fluent-bit-ds y netapp-ci-net-observer-L4-ds DaemonSets deben programar un pod en cada nodo del clúster para recopilar correctamente los datos en todos los nodos. El operador ha sido configurado para tolerar algunos taints bien conocidos. Si ha configurado algún daño personalizado en sus nodos, evitando así que los pods se ejecuten en cada nodo, puede crear una tolerancia para esos daños"En el campo AgentConfiguration". Si ha aplicado daños personalizados a todos los nodos del cluster, también debe agregar las toleraciones necesarias al despliegue del operador para permitir que el pod del operador se programe y ejecute.

Más información sobre Kubernetes "Tolerancias y taints".

Vuelva a la "NetApp Kubernetes Monitoreo de la página de instalación del operador"

Resolución de problemas

Algunas cosas que debe probar si encuentra problemas para configurar el operador de supervisión de Kubernetes:

Problema: Pruebe lo siguiente:

Problema:	Pruebe lo siguiente:
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 Data Infrastructure Insights debe supervisar de forma activa su almacenamiento en clúster de Kubernetes.
Estoy viendo mensajes en los registros que se asemejan a lo siguiente: E0901 15 352:21 v1:39,962145 1 k8s reflector.go:43,168161 1] k8s.io/kube-state-metrics/internal/store/builder.go:352: Error al mostrar v1.MutatingWebhookConfiguration: El servidor no pudo encontrar el recurso solicitado 178:k8s:178 reflector.go:E0901 15] 21.io/kube-state-leases/leases: No se pudo encontrar las métricas internas del servidor log.log.lease_leases/server.log.log.log.log.leases	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 de kube-state-Metrics: Kubectl get deployment/kube-state-Metrics -o jsonpath='{..image}' para evitar que estos mensajes ocurran, los usuarios pueden modificar su implementación de kube-state-Metrics para desactivar los siguientes arrendamientos: Mulatingweblookingdeads puede usar específicamente las configuraciones de webs. Recursos=certififeligingRequests,configmaps,cronjobs,demonsets,despliegues,Endpoints,horizontal,podautocalers,ingesses,trabajos,limitrangos, espacios de nombres,networkpolds,nodos,persistenteclaims,persistentvolumes,podritionmars,poss,poss,netmasposs,poss,poss,possitaposs,poss,poss,posavapposs,poss,poss,poss,poss,poss,poss,netmasposs,poss,possitaposs,possita,poss,poss,poss,possitaposs,poss,poss,possita,poss,poss,poss,possitaposs,poss,possita,poss,poss,possita,poss,possita,poss,poss,possita,poss,poss,possita,possi validarconexiones web, volumeadjuntos"
Veo mensajes de error de Telegraf que se parecen a lo siguiente, pero Telegraf se inicia y ejecuta: Oct 11 14:23:41 ip-172-31-39-47 systemd[1]: Se ha iniciado el agente de servidor basado en plugin para informar las 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 2021 41Z:10 ip-23-31-39-47 telegmsraf[1827]: Time=”11 14-23:41=error abierto a nivel:172= Open /etc/telegraf/.cache/snowflake/ocsp_response_cache.json: No tal archivo o directorio\n” func=“gosnowflake.(defaultLogger).Errorf file=“log.go:120” Oct 2021 41Z:10 ip-23-31-39-47 telegraf[1827]: 11 14-23:41-11T14:172! Arranque de Telegraf 1.19.3	Este es un problema conocido. Consulte "Este artículo de GitHub"si desea obtener más información. Mientras Telegraf esté activo y en funcionamiento, los usuarios pueden ignorar estos mensajes de error.
En Kubernetes, My Telegraf pod/s notifican el siguiente error: "Error al procesar mountstats info: Error al abrir el archivo mountstats: /Hostfs/proc/1/mountstats, error: Open /hostfs/proc/1/mountstats: Permission denegado"	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. Para obtener más información, consulte la "Instrucciones de OpenShift".
En Kubernetes, mi pod Telegraf ReplicaSet informa del siguiente error: [inputs.prometheus] error en el 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 ese 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 edite rs telegraf-rs… y añada las toleraciones adecuadas 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 supervisió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-cluster-rolebinding agent-2. Instale la última versión del operador de monitorización.
Me encontré con problemas tratando de implementar el Operador, y tengo PSP/PSA en uso.	1. Edite el agente con el siguiente comando: Kubectl -n <name-space> edit agent 2. Marque "Security-policy-enabled" como "false". 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 utilizando los siguientes comandos: Kubectl Get psp (debería mostrar la política de seguridad de Pod eliminada) knotbtl get all -n <namespace>
grep -i psp (debería 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 repositorio 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.
Capture o anote el resultado de los siguientes comandos y póngase en contacto con el equipo de soporte técnico. 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	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 estos: • 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”, “tiempo”: “2022-11-09T08:23:08Z”} ---- • Los pods de Net-Observer requieren 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.	Estoy viendo lo siguiente en mis registros inmediatamente después de instalar el operador de supervisión de Kubernetes: [inputs.prometheus] Error en el plugin: Error al hacer 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: Lookup kube-state-metrics.<namespace>.svc.local: No hay tal 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 la sección del operador "opciones de configuración". … spec: … telegraf: … - Nombre: docker run-mode : - DaemonSet substitutions : - Clave: DOCKER_unix_SOCK_PLACEHOLDER valor: unix://run/docker.SOCK … …	Veo mensajes de error repetidos que se parecen 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 la sección 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, Data Infrastructure Insights ha refactorizado el operador para prestar un mejor servicio a nuestros usuarios; para que esos cambios se adopten por completo, debe retire el operador antiguo y instale la nueva.	Los eventos de My kubernetes dejaron de generar informes inesperadamente para la información de Data Infrastructure.
Recupere el nombre del pod de evento-exportador: `kubectl -n netapp-monitoring get pods	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 defina el valor para LOG_FILE para reflejar el nombre de pod de evento-exportador adecuado encontrado 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 desinstalary 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 CPU y/o 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 un "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 la "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.
Veo mensajes de advertencia de Telegraf parecidos a los siguientes: W! [Inputs.diskio] No se puede recopilar el nombre del disco para “vdc”: Error al leer /dev/vdc: No tal archivo o directorio	Para el operador de supervisión de Kubernetes, estos mensajes de advertencia son benignos y se pueden ignorar con seguridad. Alternativamente, edite la sección telegraf en AgentConfiguration y establezca runDsPrivileged en true. Para obtener más información, consulte la "opciones de configuración del operador".
Mi pod de bits fluidos está fallando con los siguientes errores: [2024/10/16 14:16 23:23] [error] [/src/fluent-bit/plugins/in_tail/tail_fs_inotify.c:360 errno=24] Demasiados archivos abiertos [2024/16:2024:10/16 14] [error] fallo al inicializar la entrada tail,0 [16/23:10/16 14] [error] [error]	Intente cambiar la configuración de fsnotify en su clúster: 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> Reinicie el bit fluido. Nota: Para que estos ajustes sean persistentes en todos los reinicios de nodos, debe poner las siguientes líneas en /etc/sysctl.conf fs.inotify.max_user_instances=<something larger than current setting> fs.inotify.max_user_watches=<something larger than current setting>

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 Data Infrastructure Insights debe supervisar de forma activa su almacenamiento en clúster de Kubernetes.

Estoy viendo mensajes en los registros que se asemejan a lo siguiente: E0901 15 352:21 v1:39,962145 1 k8s reflector.go:43,168161 1] k8s.io/kube-state-metrics/internal/store/builder.go:352: Error al mostrar *v1.MutatingWebhookConfiguration: El servidor no pudo encontrar el recurso solicitado 178:k8s:178 reflector.go:E0901 15] 21.io/kube-state-leases/leases: No se pudo encontrar las métricas internas del servidor *log.log.lease_leases/server.log.log.log.log.leases

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 de kube-state-Metrics: Kubectl get deployment/kube-state-Metrics -o jsonpath='{..image}' para evitar que estos mensajes ocurran, los usuarios pueden modificar su implementación de kube-state-Metrics para desactivar los siguientes arrendamientos: Mulatingweblookingdeads puede usar específicamente las configuraciones de webs. Recursos=certififeligingRequests,configmaps,cronjobs,demonsets,despliegues,Endpoints,horizontal,podautocalers,ingesses,trabajos,limitrangos, espacios de nombres,networkpolds,nodos,persistenteclaims,persistentvolumes,podritionmars,poss,poss,netmasposs,poss,poss,possitaposs,poss,poss,posavapposs,poss,poss,poss,poss,poss,poss,netmasposs,poss,possitaposs,possita,poss,poss,poss,possitaposs,poss,poss,possita,poss,poss,poss,possitaposs,poss,possita,poss,poss,possita,poss,possita,poss,poss,possita,poss,poss,possita,possi validarconexiones web, volumeadjuntos"

Veo mensajes de error de Telegraf que se parecen a lo siguiente, pero Telegraf se inicia y ejecuta: Oct 11 14:23:41 ip-172-31-39-47 systemd[1]: Se ha iniciado el agente de servidor basado en plugin para informar las 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 2021 41Z:10 ip-23-31-39-47 telegmsraf[1827]: Time=”11 14-23:41=error abierto a nivel:172= Open /etc/telegraf/.cache/snowflake/ocsp_response_cache.json: No tal archivo o directorio\n” func=“gosnowflake.(*defaultLogger).Errorf file=“log.go:120” Oct 2021 41Z:10 ip-23-31-39-47 telegraf[1827]: 11 14-23:41-11T14:172! Arranque de Telegraf 1.19.3

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

En Kubernetes, My Telegraf pod/s notifican el siguiente error: "Error al procesar mountstats info: Error al abrir el archivo mountstats: /Hostfs/proc/1/mountstats, error: Open /hostfs/proc/1/mountstats: Permission denegado"

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. Para obtener más información, consulte la "Instrucciones de OpenShift".

En Kubernetes, mi pod Telegraf ReplicaSet informa del siguiente error: [inputs.prometheus] error en el 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 ese 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 edite rs telegraf-rs… y añada las toleraciones adecuadas 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 supervisió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-cluster-rolebinding agent-2. Instale la última versión del operador de monitorización.

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

1. Edite el agente con el siguiente comando: Kubectl -n <name-space> edit agent 2. Marque "Security-policy-enabled" como "false". 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 utilizando los siguientes comandos: Kubectl Get psp (debería mostrar la política de seguridad de Pod eliminada) knotbtl get all -n <namespace>

grep -i psp (debería 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 repositorio 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.

Capture o anote el resultado de los siguientes comandos y póngase en contacto con el equipo de soporte técnico.

 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

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 estos: • 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”, “tiempo”: “2022-11-09T08:23:08Z”} ---- • Los pods de Net-Observer requieren 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.

Estoy viendo lo siguiente en mis registros inmediatamente después de instalar el operador de supervisión de Kubernetes: [inputs.prometheus] Error en el plugin: Error al hacer 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: Lookup kube-state-metrics.<namespace>.svc.local: No hay tal 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 la sección del operador "opciones de configuración". … spec: … telegraf: … - Nombre: docker run-mode : - DaemonSet substitutions : - Clave: DOCKER_unix_SOCK_PLACEHOLDER valor: unix://run/docker.SOCK … …

Veo mensajes de error repetidos que se parecen 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 la sección 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, Data Infrastructure Insights ha refactorizado el operador para prestar un mejor servicio a nuestros usuarios; para que esos cambios se adopten por completo, debe retire el operador antiguo y instale la nueva.

Los eventos de My kubernetes dejaron de generar informes inesperadamente para la información de Data Infrastructure.

Recupere el nombre del pod de evento-exportador:

`kubectl -n netapp-monitoring get pods

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 defina el valor para LOG_FILE para reflejar el nombre de pod de evento-exportador adecuado encontrado 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 desinstalary 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 CPU y/o 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 un "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 la "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.

Veo mensajes de advertencia de Telegraf parecidos a los siguientes: W! [Inputs.diskio] No se puede recopilar el nombre del disco para “vdc”: Error al leer /dev/vdc: No tal archivo o directorio

Para el operador de supervisión de Kubernetes, estos mensajes de advertencia son benignos y se pueden ignorar con seguridad. Alternativamente, edite la sección telegraf en AgentConfiguration y establezca runDsPrivileged en true. Para obtener más información, consulte la "opciones de configuración del operador".

Mi pod de bits fluidos está fallando con los siguientes errores: [2024/10/16 14:16 23:23] [error] [/src/fluent-bit/plugins/in_tail/tail_fs_inotify.c:360 errno=24] Demasiados archivos abiertos [2024/16:2024:10/16 14] [error] fallo al inicializar la entrada tail,0 [16/23:10/16 14] [error] [error]

Intente cambiar la configuración de fsnotify en su clúster:

 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>

Reinicie el bit fluido.

Nota: Para que estos ajustes sean persistentes en todos los reinicios de nodos, debe poner las siguientes líneas en /etc/sysctl.conf

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

Puede encontrar información adicional en la "Soporte técnico" página o en el "Matriz de compatibilidad de recopilador de datos".