Supervisa tu implementación

Monitorear mongot Estado del Pod y del Recurso

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

Compruebe el estado del pod y el número de reinicios:

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

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

Inspeccione el estado y las condiciones del recurso MongoDBSearch:

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

Habilitar las métricas de Prometheus

Por defecto, el mongot punto final de métricas de Prometheus está deshabilitado. Añada el spec.observability.prometheus bloque a su MongoDBSearch recurso para habilitarlo. Un bloque vacío habilita el punto final en el puerto 9946 predeterminado.

spec:
  observability:
    prometheus: {}

Para usar un puerto distinto al predeterminado, establezca spec.observability.prometheus.port:

spec:
  observability:
    prometheus:
      port: 9090

El punto final está expuesto 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.

Enviar métricas al gerente de operaciones

El agente de reenvío de métricas envía métricas mongot a Ops Manager para que pueda verlas junto con sus otras métricas de implementación. El operador de Kubernetes implementa el agente de reenvío como un Kubernetes Deployment independiente que recopila datos del punto final de métricas mongot y envía las métricas a Ops Manager.

El agente de reenvío de métricas requiere 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 agente de reenvío. Establézcalo en uno de los siguientes valores:

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

  • enabled siempre despliega el agente de reenvío.

  • disabled nunca implementa el agente de reenvío.

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

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

  • projectName: el nombre del proyecto del Administrador de Operaciones.

  • orgId: el ID de la organización del Administrador de Operaciones.

• opsManager.agentCredentials Nombra el secreto que contiene la clave API de Ops Manager. Rellena el secreto con las siguientes claves:

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

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

• resourceRequirements Configura la CPU y la memoria para el contenedor de reenvío.

Si no configura opsManager, el operador de Kubernetes obtiene los detalles de conexión del administrador de operaciones del recurso MongoDB de origen. Debe configurar opsManager para un origen MongoDB externo.

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 forwarder en status.metricsForwarder en el recurso MongoDBSearch.

Configurar el Nivel de Verbosidad de los Registros

mongot escribe 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, agregue la bandera --follow. Para ver los registros de una instancia de contenedor anterior después de un reinicio, agregue la bandera --previous.

Para cambiar el nivel de detalle 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 entorno 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 los 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 salud HTTP en el puerto 8080 dentro del pod con dos puntos finales:

Los puntos finales reflejan mongot el inicio, la disponibilidad y la inicialización de la replicación del índice. Los puntos finales no se pueden deshabilitar.

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

Diagnóstico FTDC

mongot Escribe archivos de Captura de Datos de Diagnóstico en Tiempo Completo (FTDC) en el volumen persistente montado en la ruta de datos del pod, dentro de un subdirectorio diagnostic.data/. FTDC está habilitado de forma predeterminada y está diseñado para que el soporte de MongoDB diagnostique y evalúe problemas de rendimiento y estabilidad.

Los archivos FTDC incluyen datos de mayor cardinalidad que la superficie de Prometheus, como el tamaño por índice, desgloses de latencia para la indexación y las consultas, estadísticas del catálogo de solicitudes, latencia de serialización y 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 dentro del pod es fija en /mongot/data independientemente de la configuración spec.clusters[].persistence. La configuración de persistencia controla el tamaño del PVC y la clase de almacenamiento, no la ubicación de montaje.

Observabilidad gestionada del enviado

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

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

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

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

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

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

Obtén más información

• Solución de problemas mongot Implementación
• mongot Limitaciones de despliegue
• espec.observabilidad.prometeo
• Nivel de registro de especificación