Supervisa tu implementación

Supervisar el estado de los pods y recursos de mongot

La señal más directa de la disponibilidad de mongot es el estado de su Pod y el estado del recurso MongoDBSearch.

Compruebe el estado del pod y el recuento de reinicios:

kubectl get pods -n <namespace> --context <context> | grep search

Un pod mongot en buen estado informa un estado Running con todos los contenedores listos y un recuento de reinicios que no aumenta. Un recuento de reinicios creciente puede indicar presión de memoria o un error de configuración. Para obtener más información, consulte Solucionar problemas de implementación de mongot.

Inspeccione el estado y las condiciones del recurso MongoDBSearch:

kubectl describe mongodbsearch <MongoDBSearch.metadata.name> \
  -n <namespace> --context <context>

Habilitar métricas de Prometheus

De forma predeterminada, el punto final de métricas de Prometheus mongot está deshabilitado. Agregue el bloque spec.observability.prometheus a su recurso MongoDBSearch para habilitarlo. Un bloque vacío habilita el punto final en el puerto por defecto 9946.

spec:
  observability:
    prometheus: {}

Para usar un puerto no por defecto, establece spec.observability.prometheus.port:

spec:
  observability:
    prometheus:
      port: 9090

El punto final se expone dentro del pod y se puede acceder a él a través de la IP del pod del contenedor mongot en el puerto configurado. El operador de Kubernetes no autentica el punto final de métricas.

Reenviar métricas a MongoDB Ops Manager

El reenviador de métricas envía métricas mongot a MongoDB Ops Manager para que pueda verlas junto con las métricas de otras implementaciones. El operador de Kubernetes implementa el reenviador como un Deployment de Kubernetes independiente que extrae el punto final de métricas mongot y envía las métricas a MongoDB Ops Manager.

El reenviador de métricas requiere MongoDB Ops Manager 8.0.25 o posterior y no es compatible con Cloud Manager.

Para configurar el reenviador, establezca los siguientes campos en spec.observability.metricsForwarder en el recurso MongoDBSearch:

• mode controla si el operador de Kubernetes implementa el reenviador. Establézcalo en uno de los siguientes valores:

  • auto (por defecto) implementa automáticamente el reenviador para una fuente interna de MongoDB y para una fuente externa cuando se establece opsManager.

  • enabled siempre implementa el reenviador.

  • disabled nunca implementa el reenviador.

• opsManager.projectConfigMapRef nombra el ConfigMap que contiene la configuración del proyecto de Ops Manager. Rellene el ConfigMap con las siguientes claves:

  • baseUrl: la URL de su instancia de MongoDB Ops Manager.

  • projectName: el nombre del proyecto de MongoDB Ops Manager.

  • orgId: el ID de la organización de Ops Manager.

• opsManager.agentCredentials nombra el Secret que contiene la clave de API de MongoDB Ops Manager. Rellene el Secret con las siguientes claves:

  • publicKey: la llave pública de la clave de API de Ops Manager.

  • privateKey: la llave privada de la clave API de MongoDB Ops Manager.

• resourceRequirements establece la CPU y la memoria para el contenedor del reenviador.

Si no establece opsManager, el operador de Kubernetes deriva los detalles de conexión de MongoDB Ops Manager del recurso de MongoDB de origen. Debe establecer opsManager para una fuente de MongoDB externa.

spec:
  observability:
    metricsForwarder:
      mode: enabled
      opsManager:
        projectConfigMapRef:
          name: my-om-project-config
        agentCredentials:
          name: my-om-agent-api-key

El operador de Kubernetes informa el estado del reenviador en status.metricsForwarder en el recurso MongoDBSearch.

Configurar el Nivel de Verbosidad de los Registros

mongot guarda registros JSON estructurados en los flujos stdout y stderr de su contenedor, para que pueda leerlos con las herramientas de registro estándar de Kubernetes:

kubectl logs statefulset/<MongoDBSearch.metadata.name>-search-0

Para transmitir registros en tiempo real, añada la marca --follow. Para ver los registros de una instancia de contenedor anterior después de un reinicio, añada la marca --previous.

Para cambiar el nivel de verbosidad del registro, establezca spec.logLevel en el recurso MongoDBSearch. Los valores válidos son TRACE, DEBUG, INFO, WARN y ERROR. Si se omite, mongot registra en INFO.

spec:
  logLevel: DEBUG

mongot no rota sus propios registros. En una implementación de Kubernetes, el tiempo de ejecución del contenedor (containerd o CRI-O en la mayoría de las distribuciones) gestiona la rotación de registros a nivel de nodo. Si reenvía registros a un agregador externo, configure la retención en ese sistema en lugar de en el proceso mongot.

Punto final de verificación de estado

mongot expone un servidor de estado HTTP en el puerto 8080 dentro del pod con dos puntos finales:

Los puntos finales reflejan la mongot empresa emergente, la actividad y la inicialización de la replicación de índices. Los puntos finales no se pueden deshabilitar.

El operador de Kubernetes conecta /health y /ready a las sondas de actividad y preparación del contenedor mongot automáticamente. Normalmente, no es necesario anular estas sondas; kubectl describe pod <mongot-pod> muestra la configuración de la sonda aplicada por el operador.

Diagnósticos FTDC

mongot guarda archivos de captura de datos de diagnóstico a tiempo completo (FTDC) en el volumen persistente montado en la ruta de datos del pod, en un subdirectorio diagnostic.data/. FTDC está habilitado por defecto y está destinado a que el soporte de MongoDB clasifique los problemas de rendimiento y estabilidad.

Los archivos FTDC incluyen datos de mayor cardinalidad que la superficie de Prometheus, incluido el tamaño por índice, los desgloses de latencia para la indexación y la query, las estadísticas del catálogo de solicitudes, la latencia de serialización y los contadores de rendimiento de Lucene.

Para recopilar archivos FTDC para un caso de soporte, copie el directorio diagnostic.data/ del pod mongot con kubectl cp:

kubectl cp <mongot-pod>:/mongot/data/diagnostic.data ./mongot-ftdc

La ruta de montaje en el pod se fija en /mongot/data independientemente de la configuración spec.clusters[].persistence. La configuración de persistencia controla el tamaño de PVC y la clase de almacenamiento, no la ubicación de montaje.

Observabilidad de Envoy gestionada

Cuando establece spec.clusters[].loadBalancer.managed, el operador de Kubernetes aprovisiona un proxy Envoy L7 que se encuentra frente a los pods mongot. El contenedor Envoy expone dos superficies de observabilidad:

• Punto final de administración en el puerto 9901 para estadísticas y control en tiempo de ejecución (nivel de registro, drenaje del oyente). El operador restringe la interfaz de administración a una lista de rutas permitidas: /ready, /stats*, /drain_listeners y /logging*. Utilice este punto final para la resolución de problemas ad hoc con kubectl port-forward; no está destinado a la exposición externa.

• Métricas de Prometheus en el puerto de administración de Envoy en la ruta /stats/prometheus estándar. Extraiga este punto final junto con las métricas mongot para obtener visibilidad de extremo a extremo del flujo de solicitudes, el estado ascendente y el estado de la conexión para el plano de tráfico de búsqueda.

El operador informa el estado de Envoy de alto nivel en status.loadBalancer.phase en el recurso MongoDBSearch:

kubectl get mongodbsearch <name> -o jsonpath='{.status.loadBalancer.phase}'

La fase refleja el ciclo de vida de Envoy Deployment gestionado por el operador (por ejemplo, Pending, Running, Failed).

Obtén más información

• Solucionar problemas de implementación de mongot
• mongot Limitaciones de implementación
• spec.observability.prometheus
• spec.logLevel