Supervisión de estado y estado

Supervisión

Independientemente de las comprobaciones de estado incorporadas, un administrador puede consultar los datos de supervisión en cualquier momento para verificar el estado general del sistema o la condición de un componente o servicio concreto. Esto se realiza a través de la interfaz de Grafana, consultando los datos de métricas de todo el sistema almacenados en Prometheus.

Grafana proporciona un enfoque visual para el monitoreo: le permite crear paneles compuestos por una serie de paneles de visualización. Cada panel se corresponde con una única consulta de métrica o una combinación de consultas de métricas, que se muestran en el formato seleccionado. Las opciones incluyen gráficos, tablas, gráficos, diagramas, indicadores, etc. Para cada panel de métricas, se pueden definir umbrales. Cuando el resultado de la consulta supera o cae por debajo de un umbral determinado, el color de visualización cambia, lo que proporciona una indicación rápida de qué elementos están en buen estado, requieren investigación o no funcionan correctamente.

Un conjunto de paneles de control predefinidos permite a los administradores comenzar a supervisar el sistema tan pronto como esté activo y en ejecución. Los cuadros de mandos de supervisión predeterminados se agrupan en las siguientes categorías:

Los paneles de control por defecto contienen datos de métricas para los componentes físicos del sistema (servidores, conmutadores, proveedores de almacenamiento y sus sistemas operativos y firmware), así como sus componentes lógicos: software de controlador, plataforma, cluster y microservicios de Kubernetes, instancias informáticas y sus recursos virtualizados. Esto permite al administrador o al ingeniero de soporte verificar el estado de ambas categorías de componentes de forma independiente y encontrar correlaciones entre ellas. Por ejemplo, un microservicio concreto puede mostrar un rendimiento deficiente debido a la falta de memoria disponible. Los datos de supervisión indican si se trata de un síntoma de un problema de configuración del sistema, una falta de recursos físicos o un fallo de hardware. El sistema de supervisión cuenta con un servicio de alertas capaz de detectar y notificar fallos de hardware. De manera opcional, el administrador puede configurar un canal de notificación para recibir alertas en función de las reglas definidas en el sistema de supervisión.

Como parte de las operaciones de servicio y soporte, Oracle puede solicitarle que informe datos de métricas específicos que se muestran en los paneles de control por defecto. Por este motivo, las configuraciones de panel de control por defecto siempre se deben conservar. Sin embargo, si parte de la funcionalidad de supervisión se modifica o se interrumpe involuntariamente, se pueden restaurar los valores predeterminados. De forma similar, es posible que Oracle cree nuevos paneles de control o modifique los existentes para mejorar la supervisión y los envíe al entorno operativo sin necesidad de un procedimiento de actualización formal.

Todas las herramientas de registro y supervisión de código abierto descritas aquí tienen API públicas que permiten a los clientes integrarse con sus sistemas de alerta y supervisión de estado existentes. Sin embargo, Oracle no proporciona soporte para dichas configuraciones personalizadas.

Observación del dominio de errores

Cuando se trata de mantener la infraestructura del dispositivo, las instancias informáticas y sus recursos relacionados en buen estado, el dominio de errores es un concepto extremadamente importante. Agrupa un juego de componentes de infraestructura con el objetivo de aislar eventos de tiempo de inactividad debido a fallos o mantenimiento, asegurándose de que los recursos de otros dominios de errores no se vean afectados.

De acuerdo con Oracle Cloud Infrastructure, siempre hay tres dominios de errores en un dispositivo de nube privada. Cada uno de sus dominios de errores se corresponde con uno o más nodos de cálculo físicos. Además de utilizar Grafana para consultar los datos de supervisión en todo el sistema, un administrador también puede acceder a las métricas de capacidad clave para los dominios de errores directamente desde el Enclave de servicio:

• Número de nodos de cálculo por dominio de errores

• Cantidad total y disponible de RAM por dominio de errores

• Número total y disponible de vCPUs por dominio de errores

• Capacidad de CPU y RAM del sistema no asignada

Las métricas de dominio de errores reflejan los recursos físicos reales que pueden consumir las instancias informáticas alojadas en los nodos informáticos. Los totales no incluyen los recursos reservados para el funcionamiento del hipervisor: 40 GB de RAM y 4 núcleos de CPU (8 vCPUs).

Además de los tres dominios de errores, la CLI de servicio muestra una categoría "Unassigned". Hace referencia a los nodos de cálculo instalados que no se han aprovisionado y que, por lo tanto, aún no forman parte de un dominio de errores. Para los nodos de cálculo sin asignar, no se puede calcular la capacidad de memoria, pero se muestran las métricas de CPU.

Comprobaciones del sistema

Los controles de estado son la forma más básica de detección. Se ejecutan a intervalos regulares como servicios CronJob de Kubernetes, que son muy similares a los trabajos cron de UNIX normales. Se crea una entrada de estado para cada resultado de comprobación del sistema, que siempre es una de las dos posibilidades: healthy o not healthy. Toda la información de estado se almacena para su posterior procesamiento en Prometheus; los resultados en mal estado también generan entradas de log en Loki con detalles para ayudar a avanzar en el proceso de resolución de problemas.

Las comprobaciones de estado están diseñadas para verificar el estado de componentes específicos del sistema y para detectar cambios de estado. Cada proceso de comprobación del sistema sigue el mismo principio básico: registrar la condición actual y compararla con el resultado esperado. Si coinciden, la comprobación del sistema pasa; si difieren, la comprobación del sistema falla. Un cambio de estado de correcto a no correcto indica que se requiere la resolución de problemas.

Para la resolución de problemas, hay dos orígenes de datos principales a su disposición: logs y métricas. Ambas categorías de datos se recopilan de todo el sistema y se almacenan en una ubicación central: los registros se agregan en Loki y las métricas en Prometheus. Ambas herramientas cuentan con una interfaz de consulta que permite filtrar y visualizar los datos: ambas se integran con Grafana. Se puede acceder a su interfaz basada en explorador desde la interfaz de usuario web de servicio.

Para investigar qué causa un fallo en la comprobación del sistema, ayuda a filtrar logs y datos de métricas en función del tipo de fallo. Loki categoriza los datos con un sistema de etiquetado, mostrando mensajes de log que coinciden con la etiqueta de log seleccionada. Seleccione una etiqueta de la lista para ver los logs del servicio o la aplicación en los que está interesado. Esta lista le permite seleccionar no solo las comprobaciones de estado, sino también los servicios de dispositivos internos y externos.

Además, el estado más reciente de cada comprobación del sistema se muestra en el panel de control Comprobación del sistema de la plataforma, que forma parte del juego de paneles de control del asesor de servicios proporcionado por defecto en Grafana.

Private Cloud Appliance ejecuta las comprobaciones de estado que se muestran a continuación.

Registro Centralizado

La plataforma proporciona un registro unificado en todo el sistema. El recopilador de datos Fluentd recupera los logs de los componentes de todo el sistema y los almacena en una ubicación central, junto con los datos de telemetría del dispositivo. Como resultado, toda la información necesaria de solución de problemas y depuración se mantiene en un único almacén de datos y no es necesario recopilarla de diferentes orígenes cuando se deba investigar un problema. El estado general del sistema se captura en una vista, un panel de control de Grafana, lo que significa que no es necesario que un administrador compruebe componentes individuales.

Cuando se encuentra un problema que requiere asistencia de Oracle, el administrador registra una solicitud de servicio. Normalmente, se solicita un paquete de soporte como parte de ese proceso. Gracias al registro centralizado, el paquete de soporte es sencillo de generar y sigue siendo posible incluso si el funcionamiento del sistema se ve gravemente comprometido. La generación del paquete de soporte es una operación con scripts que produce un único archivo de almacenamiento comprimido. El administrador necesita cargar manualmente el archivo de almacenamiento que contiene los logs consolidados y otros datos de diagnóstico.

Si Private Cloud Appliance está registrado para ASR, ciertos fallos de hardware provocan que una solicitud de servicio y los datos de diagnóstico se envíen automáticamente al soporte de Oracle.