18 min de lectura

Objetivos de aprendizaje

Al final de este módulo, podrás:

  • Asignar los cuatro planos de telemetría de IONOS CLOUD (métricas, registros, auditoría, flujo de red) a sus alcances fijos y enrutar cada señal de manera deliberada en lugar de esperar que una sola pestaña de la consola muestre todo
  • Diseñar alrededor de las tres brechas de observabilidad que atrapan a los equipos en producción: eventos del plano de control de Kubernetes que nunca llegan al Logging Service, la ausencia de agregación entre contratos y la ventana de retención de registros de actividad de 35 días
  • Utilizar el registro centralizado para que los productos integrados envíen sus propios registros sin que cada uno ejecute una pila de ingesta separada
  • Posicionar la observabilidad dedicada de VMware vCenter junto con los planos de la plataforma para un patrimonio híbrido
  • Construir una canalización de métricas con una alerta y habilitar un registro de flujo en el Data Center Designer, y dirigir la telemetría a un SIEM externo como el patrón de agregación empresarial

Unidad 7.2: Observabilidad y Operaciones

Introducción

La observabilidad en IONOS CLOUD no es un solo producto. Son cuatro planos separados, cada uno con un alcance fijo, su propia ruta de ingesta y su propio modelo de retención. El trabajo arquitectónico no se trata de "activar la monitorización"; se trata de decidir qué señal aterriza en qué plano, dónde están las costuras entre los planos y cómo se puede crear una imagen operativa única a través de ellos y a través de contratos.

FinCorp, nuestra empresa de servicios financieros alemana bajo las obligaciones del RGPD y BSI, necesita una vista operativa de grado de auditoría que abarque un núcleo de carga de trabajo regulada, una plataforma Managed Kubernetes y un patrimonio VMware dedicado, lo que expone cada costura en el modelo de telemetría de la plataforma. Esta unidad recorre los cuatro planos, nombra las brechas con honestidad, construye una canalización de métricas con una alerta y un registro de flujo en el Data Center Designer, y se centra en el patrón de fan-in que da a FinCorp un solo lugar para correlacionar.

1. Los Cuatro Planos de Telemetría y Sus Ámbitos Fijos

La plataforma divide la señal operativa en cuatro productos. Ninguno de ellos es un superconjunto de los demás, y los límites son rígidos, no convenciones.

Métricas (Monitoring Service). Un servicio por contrato, por región que ingiere métricas en formato Prometheus (Contador, Medidor, Histograma, Resumen), con una alternativa JSON que debe estar comprimida utilizando Snappy. Las métricas son empujadas por un agente: Prometheus, Grafana Agent, OpenTelemetry o Fluent Bit, con un intervalo de empuje predeterminado de 1 minuto que se puede configurar. Detrás del punto de conexión, los datos aterrizan en Grafana Mimir y se visualizan en una instancia gestionada de Grafana con ámbito por contrato y por región. Puede ejecutar hasta 10 tuberías por contrato.

Registros (Logging Service). Un servicio por contrato, por región que ingiere flujos de registros de un conjunto fijo de fuentes: Kubernetes, Docker, Linux Systemd, HTTP (una API REST JSON) y Genérico. El transporte es TLS sobre TCP (adelante Fluent Bit, puerto 9000) o HTTPS (puerto 443). Cada tubería transporta hasta 5 flujos de registros, puede ejecutar hasta 10 tuberías por contrato, y la retención por flujo es de 7, 14, 30 días o ilimitada (predeterminada 30). Los registros se muestran en la misma instancia gestionada de Grafana, pero la ventana de consulta de Grafana es de 30 días; cualquier cosa mantenida bajo retención ilimitada se lee nuevamente mediante la presentación de una solicitud de soporte, no en el panel.

Auditoría (Activity Logs). La pista de auditoría del plano de control: quién hizo qué a qué recurso. Registra los inicios de sesión del usuario, el aprovisionamiento de recursos, los cambios de configuración, el acceso a datos y la recuperación, modificación y eliminación de recursos. Está diseñada para ser de solo lectura, cada llamada es un GET contra https://api.ionos.com/activitylog/v1, y la retención es de 35 días. Este es un plano de gobernanza, cubierto en profundidad en la Unidad 2.3; aquí importa porque su ventana corta fuerza una disciplina de exportación que los planos de métricas y registros no tienen.

Flujo de red (Flow Logs). Registros de conexión por flujo (5-tupla más conteos de paquetes y bytes, más un campo action de ACEPTAR o RECHAZAR que muestra el veredicto del firewall) emitidos a un bucket Object Storage propiedad del cliente como texto comprimido gzip, rotado cada 10 minutos. Los registros de flujo se adjuntan a una NIC VM, un Managed Network Load Balancer, un Managed Application Load Balancer o un Managed NAT Gateway, y capturan IPv4 e IPv6. Este plano se construye en la Unidad 3.2 como la herramienta de verificación del firewall; reaparece aquí como la pierna del nivel de red del cuadro operativo.

La superficie unificadora es Grafana: las métricas y los registros son ambos consultables a través de una instancia gestionada de Grafana por contrato por región. El punto deliberado del diseño es que los datos de auditoría y flujo de red viven completamente fuera de ese panel, en la API Activity Log y en Object Storage respectivamente. Una vista operativa completa es algo que usted ensambla, no algo que la consola le proporciona.

2. Los vacíos que debemos diseñar

Tres límites son los que pueden causar problemas en producción. Cada uno es una entrada de diseño, no un defecto, y cada uno tiene una composición nativa alrededor de él.

Los eventos del plano de control de Kubernetes no fluyen a través del Logging Service. El Logging Service enumera Kubernetes como una fuente compatible, pero eso significa registros de cargas de trabajo y nodos que se envían desde dentro del clúster, no del plano de control administrado. El SLA de IONOS CLOUD Managed Kubernetes cubre solo la API de Kubernetes del plano de control, y los eventos del plano de control no se emiten en su tubería de Logging Service. El clúster ofrece un toggle separado "Registro en S3" que escribe los datos de registro del clúster en un bucket de Object Storage; trátelo como una ruta habilitada por separado, no como visibilidad del plano de control en su Grafana. Para la observabilidad de las cargas de trabajo, se implementa un agente dentro del clúster (Fluent Bit para registros, un exportador compatible con Prometheus para métricas) que envía a sus tuberías de Logging y Monitoring. La costura es la línea entre el plano de control administrado y sus cargas de trabajo: usted instrumenta las últimas, IONOS CLOUD opera las primeras.

No hay agregación entre contratos. Las tuberías de Monitoring y Logging son por contrato y por región, y el Registro de Actividad es por contrato sin punto de agregación ni endpoint. Si FinCorp divide la producción, no producción y una carga de trabajo aislada por cumplimiento en contratos separados (la disciplina de límite desde la Unidad 2.1), no hay panel nativo que una su telemetría. La agregación es algo que se construye, conectando cada señal del contrato a un colector externo (Sección 5).

La ventana de retención del Registro de Actividad es de 35 días. Ese es el horizonte de eliminación duro para el registro de auditoría. Para una empresa regulada cuyas obligaciones de retención se extienden durante años, la ventana de 35 días es una fecha límite para la exportación, no una política de retención. El patrón documentado a largo plazo es descargar los datos del Registro de Actividad según un calendario y almacenarlos en un almacenamiento diferente, con IONOS Cloud Object Storage como objetivo recomendado explícitamente, idealmente bajo bloqueo de objeto para un archivo a prueba de manipulaciones (Unidad 2.3, Unidad 5.2). Si se pierde la ventana, el registro desaparece.

3. Registro centralizado y observabilidad híbrida de vCenter

3.1 Registro centralizado para el reenvío iniciado por el producto

De forma predeterminada, usted envía los registros usted mismo, apuntando a un agente a un punto de conexión de la canalización. El Registro centralizado es el interruptor de nivel de contrato, por región, que permite a los productos integrados de IONOS CLOUD reenviar sus propios registros al Logging Service en su nombre, mostrado en el mismo Grafana administrado, sin que cada producto ejecute una pila de ingesta separada. Un Managed Network Load Balancer, por ejemplo, envía sus registros de acceso al Logging Service una vez que se habilita el Registro centralizado. El mismo modelo se extiende al monitoreo centralizado para el Monitoring Service.

El Registro centralizado debe estar activado antes de que cualquier producto pueda ingerir en su nombre, porque afecta tanto su visión operativa como su facturación. La activación es por región, y solo los administradores de contrato, propietarios y usuarios con el privilegio "Acceso y administración del Logging Service" pueden activarlo o desactivarlo. Puede habilitarse desde el DCD (un interruptor de estado por región en la vista de registro centralizado del Logging Service), desde la API de registro o por un producto integrado en su nombre. Los productos que se integran se confirman a través del administrador de cuenta o del soporte de IONOS CLOUD, en lugar de publicarse como una lista estática, así que trate al conjunto compatible como algo que debe verificarse por compromiso.

3.2 Observabilidad de vCenter para el patrimonio dedicado-VMware

El núcleo regulado de FinCorp se ejecuta en IONOS CLOUD Private Cloud, el SDDC de VMware administrado dedicado (Unidad 4.4). Sus telemetrías no fluyen hacia los cuatro planos de plataforma. En su lugar, la observabilidad para ese patrimonio es la herramienta nativa de VMware que se envía con la pila dedicada: vCenter Server 8.0 para gráficos de rendimiento del host, clúster y VM, eventos y alarmas, y monitoreo de salud y capacidad de vSAN expuesto en el Panel de Cloud para la capa de almacenamiento. La API REST de vSphere (limitada a 100 solicitudes por segundo) es la costura programática si desea extraer esos datos hacia afuera.

Establezca solo lo que admite la matriz aquí: la superficie de observabilidad dedicada-VMware es vCenter y vSAN. No asuma un puente administrado entre planos que ingiera alarmas de vCenter en el Logging Service; ninguno está documentado. Para un patrimonio híbrido, el modelo honesto es dos dominios de observabilidad que funcionan lado a lado, los cuatro planos de plataforma para recursos nativos de la nube y vCenter/vSAN para el núcleo dedicado de VMware, reconciliados solo donde deliberadamente reenvíe ambos a un colector externo común.

4. Recorrido de implementación de DCD

Usted configurará la parte de métricas de la vista operativa de FinCorp y la parte de flujo de red: una canalización de métricas con una alerta y un registro de flujo en el equilibrador de carga de borde. Esto realiza dos de los cuatro planos del Capítulo 1 y le da puntos de ingesta concretos para apuntar a los agentes. La tercera parte, registros, sigue el mismo patrón de canalización en el DCD.

Objetivo de creación: Crear una canalización de métricas con una alerta y habilitar los registros de flujo.

Requisitos previos. Un bucket de Object Storage existente en la región objetivo que usted posee (el destino del registro de flujo debe ser un bucket propiedad del usuario). El privilegio "Crear registros de flujo" para el trabajo del registro de flujo, y el privilegio "Acceder y gestionar Monitoring" para la canalización de métricas. Salida HTTPS en el puerto 443 desde donde se ejecutan sus agentes de métricas.

Parte A: la canalización de métricas (Monitoring Service). La canalización de métricas del Monitoring Service se puede crear desde un formulario de creación del DCD o a través de la API del Monitoring Service, y el DCD también proporciona acceso al Grafana resultante. El ciclo de vida completo de la canalización (crear, recuperar, modificar, eliminar) está disponible a través de la API, que es el camino utilizado a continuación antes de pasar a Grafana para la alerta.

  1. Seleccione el punto final regional que coincida con su ubicación de datos, por ejemplo https://monitoring.de-txl.ionos.com/pipelines para Berlín. La región determina dónde se procesan y almacenan las métricas, así que manténgala coherente con la decisión de residencia de la carga de trabajo.
  2. Cree la canalización con un PUT (o POST) hacia ese punto final que lleva un properties.name, autenticado con un token Bearer. La respuesta incluye una clave única key en sus metadatos y un grafanaEndpoint. Guarde la clave al crearla; por motivos de seguridad no se devuelve nuevamente, y no puede enviar métricas sin ella.
  3. Configure un agente de métricas (Prometheus, Grafana Agent, OpenTelemetry o Fluent Bit) para enviar a la canalización del punto final HTTP con api/v1/push agregado al camino, enviando la clave guardada como encabezado de autorización Bearer sobre el puerto 443. Las métricas llegan en el intervalo predeterminado de 1 minuto a menos que lo cambie.
  4. Abra el Grafana administrado en la clave devuelta grafanaEndpoint y confirme que las métricas son consultables, lo que verifica la ingesta de extremo a extremo.
  5. Cree la alerta dentro del Grafana: defina una regla de alerta en la métrica que le preocupa (para el nivel de aplicación sin estado de FinCorp, un umbral de utilización del CPU que debe preceder a una acción autoescalable), y adjunte un punto de contacto para que la regla notifique al canal en espera. La alerta del Grafana es la superficie de alerta; no hay un objeto separado IONOS CLOUD para el plano métrico.

Una llamada ilustrativa corta (el punto arquitectónico es que este plano se aprovisiona a través de la API, no la consola):

curl --location --request POST 'https://monitoring.de-txl.ionos.com/pipelines' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer $TOKEN' \
  --data '{ "properties": { "name": "fincorp-app-metrics" } }'

Parte B: el registro de flujo (DCD). Esta etapa es una construcción de DCD real, adjunta a un recurso que ya tiene desde el Módulo 3.

  1. En el DCD, abra el centro de datos, seleccione el recurso de borde cuyo tráfico desea registrar. Para un servidor o Cube, abra la pestaña Red y las propiedades del Controlador de Red (NIC); para un Managed Network Load Balancer, Managed Application Load Balancer o Managed NAT Gateway, abra la pestaña Configuración en el panel Inspector.
  2. Abra el menú desplegable del Registro de flujo y cree una regla. Establezca un nombre (que también se convierte en la primera parte del prefijo de nombre de objeto de Object Storage), así que nómbrelo para el recurso y el entorno.
  3. Establezca la Dirección en Ingreso, Salida o Bidireccional, y la Acción en Rechazada, Aceptada o Cualquiera. Para una postura de investigación de seguridad, Bidireccional más Rechazada muestra lo que el firewall está bloqueando; para análisis de capacidad y conexión, Aceptada es el conjunto útil.
  4. Establezca el bucket de Object Storage de destino en su bucket existente propiedad del usuario en la región. Guarde. Los registros comienzan a llegar como objetos .log.gz, rotados cada 10 minutos.
  5. Aplicar una política de ciclo de vida en ese bucket para aged los objetos del registro de flujo, porque los Registros de flujo no tienen retención integrada: la retención es completamente administrada por el cliente a través de una Política de ciclo de vida de Object Storage o eliminación manual.

Errores comunes:

  • No guardar la clave de la canalización de monitorización en la creación. La clave se devuelve una vez y nunca más. Pérdala y vuelva a crear la canalización. La misma regla de clave de un solo uso se aplica a una canalización de Logging Service.
  • Tratar "Kubernetes" en la lista de fuentes del Logging Service como visibilidad del plano de control. Son solo los registros del trabajo de carga en el clúster; los eventos del plano de control nunca llegan allí. Implemente un agente en el clúster y no espere eventos que no llegarán.
  • Suponer que la retención del registro de flujo es administrada por usted. Eliminar la regla del registro de flujo no elimina los objetos ya escritos, y no hay expiración automática. Sin una política de ciclo de vida del bucket, el archivo crece y factura para siempre.
  • Apuntar un registro de flujo a un bucket que no posee o uno en la región incorrecta. El destino debe ser un bucket propiedad del usuario; apuntar incorrectamente falla silenciosamente al entregar registros.
  • Olvidar la ventana de 35 días del Registro de actividad. No es retención, es un horizonte de eliminación. Programe la exportación a Object Storage antes del día 35, o el registro auditor es irrecuperable.

5. Fan-In a un SIEM Externo

Para una empresa como FinCorp, el modelo de cuatro planos por contrato y región no produce la vista única correlacionada que un equipo de operaciones de seguridad y un auditor necesitan. El patrón empresarial es fan-in: cada plano de cada contrato fluye hacia un SIEM externo que se convierte en el sistema de registro para la correlación, retención a largo plazo y alertas en todo el estado. La plataforma le proporciona las herramientas para hacer esto sin un forwarder gestionado:

  • Registros y métricas: apunte sus agentes (o los forwarders iniciados por producto de Central Logging) a las tuberías de IONOS CLOUD para Grafana en la plataforma, y en paralelo envíe los mismos flujos desde sus agentes al recolector de SIEM. El Logging Service también expone una API de Telemetría de solo lectura (autenticada con el mismo token de API de Cloud) que un SIEM puede sondear, aunque el envío dual del lado del agente es la ruta más directa.
  • Flujo de red: los Flow Logs ya aterrizan en Object Storage como texto gzip; el SIEM los ingiere desde el bucket, que también sirve como archivo duradero.
  • Auditoría: un trabajo programado extrae el Activity Log a través de su API de solo lectura antes de que se cierre la ventana de 35 días y envía los registros al SIEM, satisfaciendo al mismo tiempo la retención a largo plazo y la correlación entre contratos.
  • Hybrid VMware: la API REST de vSphere y las alarmas de vCenter se envían desde el estado dedicado al mismo SIEM, uniéndose los dos dominios de observabilidad en el único punto donde la unificación es significativa.

Esta es la misma lección de composición que la plataforma repite en otros lugares: no hay un producto de agregación gestionada entre contratos, así que usted compone uno. Object Storage es el centro duradero, el SIEM es el cerebro de correlación y los puntos finales por plano son las llaves.

Resumen

La observabilidad de IONOS CLOUD se compone de cuatro planos de alcance fijo (métricas a través del Monitoring Service, registros a través del Logging Service, auditoría a través de Activity Logs y flujo de red a través de Flow Logs) unificados solo parcialmente en Grafana, con datos de auditoría y flujo que viven fuera de ese panel por diseño. El trabajo operativo que soporta la carga es enrutear cada señal de manera deliberada, diseñando alrededor de las tres brechas (no hay eventos del plano de control en el plano de registro, no hay agregación entre contratos, una ventana de auditoría de 35 días), utilizando Central Logging para el envío iniciado por el producto, tratando la finca dedicada a VMware como un dominio de observabilidad vCenter/vSAN separado, y enviando todo a un SIEM externo donde se produce la correlación y la retención a largo plazo.

Puntos clave:

  • Cuatro planos, alcances fijos: Monitoring Service (métricas Prometheus, basado en push, Grafana Mimir), Logging Service (cinco tipos de origen, 5 flujos por pipeline, retención de 7/14/30/días ilimitados), Activity Logs (solo lectura GET, ventana de 35 días), Flow Logs (registros de 5 tuplas a un bucket de Object Storage propiedad del usuario, retención administrada por el cliente).
  • La canalización de métricas del Monitoring Service se puede crear desde un formulario de creación DCD o a través de la API; la clave de la canalización debe guardarse durante la creación.
  • Los eventos del plano de control de Kubernetes nunca llegan al Logging Service; instrumente las cargas de trabajo con un agente en el clúster y trate el "Registro en S3" del clúster como una ruta separada.
  • No hay agregación entre contratos y el registro de auditoría se elimina después de 35 días, por lo que la agregación y la retención a largo plazo se construyen externamente, con Object Storage como el centro duradero y un SIEM como el punto de correlación.
  • Central Logging es una función a nivel de contrato y región (controlada por el administrador) que permite que los productos integrados IONOS CLOUD envíen registros para usted; la finca dedicada a VMware se observa a través de vCenter 8.0 y vSAN, un dominio separado que se reconcilia solo en el SIEM.

Terminología importante:

  • Plano de telemetría: uno de los cuatro productos de observabilidad de alcance fijo (métricas, registros, auditoría, flujo de red), cada uno con su propia ruta de ingesta y modelo de retención.
  • Central Logging: una capacidad a nivel de contrato y región que permite que los productos IONOS CLOUD integrados envíen sus registros al Logging Service en su nombre, presentado en el Grafana administrado.
  • Registro de flujo: una regla por recurso que emite registros de conexión de 5 tuplas con el veredicto ACCEPT/REJECT del firewall a un bucket de Object Storage propiedad del cliente, rotado cada 10 minutos.
  • Fan-in: el patrón de agregación empresarial que consiste en enviar cada plano desde cada contrato a un SIEM externo para la correlación entre contratos y la retención a largo plazo.

Lectura adicional

  • Unidad 2.3: Activity Logs y el registro de auditoría (el plano de auditoría y el plazo de exportación)
  • Unidad 3.2: Seguridad de red: Firewall y grupos de seguridad (registros de flujo como herramienta de verificación del firewall)
  • Unidad 4.4: Private Cloud (VMware dedicado) (el patrimonio dedicado observado a través de vCenter y vSAN)
  • Unidad 6.1: Diseño de la plataforma Kubernetes (por qué los eventos del controlador se encuentran fuera del plano de registro)
  • Centro de arquitectura de IONOS CLOUD