19 min de lectura

Objetivos de aprendizaje

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

  • Mapear 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 un solo panel de consola muestre todo
  • Diseñar considerando las tres brechas de observabilidad que afectan a los equipos en producción: los 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 35 días del registro de actividad
  • Utilizar el registro centralizado para que los productos integrados reenvíen sus propios registros sin que cada uno tenga que ejecutar una pila de ingesta independiente
  • Posicionar la observabilidad de vCenter de VMware dedicado junto a los planos de la plataforma para un entorno híbrido
  • Construir una canalización de métricas con una alerta y habilitar un registro de flujo en el Data Center Designer, y distribuir la telemetría a un SIEM externo como patrón de agregación empresarial

Unidad 7.2: Observabilidad y operaciones

Introducción

La observabilidad en IONOS CLOUD no es un solo producto. Se trata de cuatro planos independientes, cada uno con un alcance fijo, su propia ruta de ingesta y su propio modelo de retención. El trabajo arquitectónico no consiste en "activar la monitorización"; consiste en decidir qué señal se dirige a qué plano, dónde se encuentran las uniones entre planos y cómo se integra una única visión operativa a través de ellos y a través de los contratos.

FinCorp, nuestra empresa alemana de servicios financieros sujeta a las obligaciones del RGPD y de BSI, necesita una visión operativa de nivel de auditoría que abarque un núcleo de carga de trabajo regulado, una plataforma de Managed Kubernetes y un entorno dedicado de VMware, lo cual expone cada unión del modelo de telemetría de la plataforma. Esta unidad recorre los cuatro planos, identifica con honestidad las lagunas, construye una canalización de métricas con una alerta y un registro de flujo en el Data Center Designer, y concluye con el patrón de convergencia que proporciona a FinCorp un único lugar para correlacionar.

1. Los cuatro planos de telemetría y sus alcances fijos

La plataforma distribuye la señal operativa entre cuatro productos. Ninguno de ellos es un superconjunto de los demás, y las fronteras son rígidas, no convenciones.

Métricas (Monitoring Service). Un servicio por contrato y por región que ingiere métricas en formato Prometheus (Counter, Gauge, Histogram, Summary), con una alternativa en JSON que debe comprimirse usando Snappy. Las métricas se envían mediante un agente: Prometheus, Grafana Agent, OpenTelemetry o Fluent Bit, con un intervalo de envío predeterminado de 1 minuto, configurable. Detrás del punto de acceso, los datos se almacenan en Grafana Mimir y se visualizan en una instancia administrada de Grafana, con alcance por contrato y por región. Puede ejecutar hasta 10 pipelines por contrato.

Registros (Logging Service). Un servicio por contrato y por región que ingiere flujos de registros desde un conjunto fijo de orígenes: Kubernetes, Docker, Linux Systemd, HTTP (una API REST en JSON) y Genérico. El transporte es TLS sobre TCP (Fluent Bit forward, puerto 9000) o HTTPS (puerto 443). Cada pipeline transporta hasta 5 flujos de registros, puede ejecutar hasta 10 pipelines por contrato, y la retención por flujo es de 7, 14 o 30 días, o ilimitada (predeterminado: 30 días). Los registros se muestran en la misma instancia administrada de Grafana, pero la ventana de consulta de Grafana es de 30 días; cualquier dato conservado bajo retención ilimitada se recupera mediante una solicitud de soporte, no desde el panel.

Auditoría (Activity Logs). La pista de auditoría del plano de control: quién hizo qué a qué recurso. Registra inicios de sesión de usuarios, aprovisionamiento de recursos, cambios de configuración, acceso a datos, y recuperaciones, modificaciones y eliminaciones de recursos. Es de solo lectura por diseño, 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, tratado en profundidad en la Unidad 2.3; aquí es relevante porque su ventana corta impone una disciplina de exportación que los planos de métricas y registros no requieren.

Flujo de red (Flow Logs). Registros de conexión por flujo (5-tupla más recuentos de paquetes y bytes, más un campo action de ACCEPT o REJECT que muestra la decisión del firewall), emitidos a un bucket de Object Storage propiedad del cliente como texto comprimido con gzip, rotado cada 10 minutos. Flow Logs se adjuntan a una NIC de VM, a un Managed Network Load Balancer, a un Managed Application Load Balancer o a un Managed NAT Gateway, y capturan IPv4 e IPv6. Este plano se construye en la Unidad 3.2 como herramienta de verificación del firewall; reaparece aquí como la rama de capa de red de la imagen operativa.

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

2. Las limitaciones a considerar en el diseño

Tres límites son los que afectan en producción. Cada uno es un parámetro de diseño, no un defecto, y cada uno cuenta con una composición nativa a su alrededor.

Los eventos del plano de control de Kubernetes no fluyen a través del Logging Service. El Logging Service lista Kubernetes como una fuente admitida, pero esto se refiere a los registros de cargas de trabajo y nodos que se envían desde dentro del clúster, no al plano de control gestionado. El SLA de IONOS CLOUD Managed Kubernetes cubre únicamente la API de Kubernetes del plano de control, y los eventos del plano de control no se emiten en su pipeline de Logging Service. El clúster ofrece un interruptor separado, "Logging to S3", que escribe los datos de registros del clúster en un bucket de Object Storage; considere esto como una ruta distinta y habilitada por separado, no como visibilidad del plano de control en su Grafana. Para la observabilidad de las cargas de trabajo, debe desplegar un agente dentro del clúster (Fluent Bit para registros, un exportador compatible con Prometheus para métricas) que envíe datos a sus pipelines de Logging y Monitoring. La frontera es la línea entre el plano de control gestionado y sus cargas de trabajo: usted instrumenta estas últimas, mientras que IONOS CLOUD opera el primero.

No existe agregación entre contratos. Los pipelines de Monitoring y Logging son por contrato y por región, y el Activity Log es por contrato, sin empuje ni punto de agregación. Si FinCorp divide la producción, la no producción y una carga de trabajo aislada por cumplimiento en contratos separados (la disciplina de límites de la Unidad 2.1), no hay un panel nativo que una su telemetría. La agregación es algo que usted construye, enviando la señal de cada contrato a un colector externo único (Sección 5).

La ventana de retención del Activity Log es de 35 días. Ese es el horizonte de eliminación definitiva para la ruta de auditoría. Para una empresa regulada cuyas obligaciones de retención se extienden durante años, la ventana de 35 días es un plazo de exportación, no una política de retención. El patrón a largo plazo documentado consiste en descargar los datos del Activity Log de forma programada y almacenarlos en un almacenamiento diferente, con IONOS Cloud Object Storage como destino explícitamente recomendado, idealmente bajo object lock para un archivo con evidencia de manipulación (Unidad 2.3, Unidad 5.2). Si se pierde la ventana, el registro desaparece.

3. Registro centralizado y observabilidad de vCenter híbrido

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

De forma predeterminada, usted envía los registros por su cuenta, dirigiendo un agente a un punto final de canalización. El registro centralizado es el interruptor a nivel de contrato y por región que permite que los productos integrados de IONOS CLOUD reenvíen sus propios registros al Logging Service en su nombre, mostrados 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 a su Logging Service una vez que el registro centralizado está habilitado. El mismo modelo se extiende a la monitorización central para el Monitoring Service.

El registro centralizado debe activarse antes de que cualquier producto pueda ingerir registros en su nombre, porque afecta tanto a su vista operativa como a su facturación. La activación es por región, y solo los administradores de contrato, los propietarios y los usuarios con el privilegio "Acceder y administrar 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 de su gestor de cuenta o del soporte de IONOS CLOUD, en lugar de publicarse como una lista estática, por lo que debe considerar el conjunto admitido como algo que debe verificar en cada contrato.

3.2 Observabilidad de vCenter para el entorno dedicado de VMware

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

Indique solo lo que la matriz admite aquí: la superficie de observabilidad del entorno dedicado de VMware es vCenter y vSAN. No asuma un puente administrado entre planos que ingiera alarmas de vCenter en el Logging Service; no existe documentación al respecto. Para un entorno híbrido, el modelo honesto es de dos dominios de observabilidad que funcionan en paralelo, los cuatro planos de la plataforma para recursos nativos de la nube y vCenter/vSAN para el núcleo dedicado de VMware, armonizados solo donde usted reenvía deliberadamente ambos a un colector externo común.

4. Guía de implementación de DCD

Usted implementará la parte de métricas de la vista operativa de FinCorp y la parte de flujos de red: un pipeline de métricas con una alerta, y un registro de flujos en el balanceador de carga de borde. Esto materializa dos de los cuatro planos de la Sección 1 y le proporciona puntos de ingesta concretos a los que dirigir los agentes. La tercera parte, los registros, sigue el mismo patrón de pipeline en el DCD.

Objetivo de construcción: Crear un pipeline de métricas con una alerta y habilitar los registros de flujos.

Requisitos previos. Un bucket de Object Storage existente en la región de destino que usted posea (el destino del registro de flujos debe ser un bucket propiedad del usuario). El privilegio "Create Flow logs" para el trabajo con registros de flujos, y el privilegio "Access and manage Monitoring" para el pipeline de métricas. Tráfico saliente HTTPS en el puerto 443 desde donde se ejecuten sus agentes de métricas.

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

  1. Elija el punto final regional que corresponda con la ubicación de sus 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, por lo que manténgala coherente con la decisión de residencia de la carga de trabajo.
  2. Cree el pipeline con una PUT (o POST) a ese punto final, llevando una properties.name, autenticada con un token Bearer. La respuesta incluye una key de un solo uso en sus metadatos y una grafanaEndpoint. Guarde la clave al momento de la creación; por 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 datos al punto final HTTP del pipeline con api/v1/push agregado a la ruta, enviando la clave guardada como un encabezado de autorización Bearer sobre el puerto 443. Las métricas llegan con un intervalo predeterminado de 1 minuto, a menos que lo cambie.
  4. Abra el Grafana administrado en la grafanaEndpoint devuelta y confirme que las métricas son consultables, lo cual verifica la ingesta de extremo a extremo.
  5. Cree la alerta dentro de Grafana: defina una regla de alerta en la métrica que le interese (para la capa de aplicación sin estado de FinCorp, un umbral de utilización de CPU que debería preceder a una acción de escalado automático), y adjunte un punto de contacto para que la regla notifique al canal de guardia. La alertas de Grafana es la superficie de alertas; no existe un objeto de alerta separado de IONOS CLOUD para el plano de métricas.

Una llamada de creación ilustrativa breve (el punto arquitectónico es que este plano se aprovisiona a través de la API, no a través de 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 parte es una construcción real de DCD, adjunta a un recurso que ya tiene desde la Unidad 3.

  1. En el DCD, abra el centro de datos y seleccione el recurso de borde cuyo tráfico desea registrar. Para un servidor o un Cube, abra la pestaña Network y las propiedades del Network Controller (NIC); para un Managed Network Load Balancer, Managed Application Load Balancer o Managed NAT Gateway, abra la pestaña Settings en el panel Inspector.
  2. Abra el menú desplegable Flow Log y cree una regla. Establezca un Name (también se convierte en la primera parte del prefijo del nombre del objeto de Object Storage), así que nómbrelo según el recurso y el entorno.
  3. Establezca Direction como Ingress, Egress o Bidirectional, y Action como Rejected, Accepted o Any. Para una postura de investigación de seguridad, Bidirectional junto con Rejected revela lo que el firewall está bloqueando; para el análisis de capacidad y conexiones, Accepted es el conjunto útil.
  4. Establezca el cubo de Object Storage de destino en su cubo existente propiedad del usuario en la región. Guarde. Los registros comienzan a llegar como objetos .log.gz, rotados cada 10 minutos.
  5. Aplique una política de ciclo de vida en ese cubo para eliminar los objetos de registro de flujo, porque Flow Logs no tiene retención integrada: la retención es gestionada completamente por el cliente a través de una Object Storage Lifecycle Policy o mediante eliminación manual.

Errores comunes:

  • No guardar la clave del canal de monitorización en la creación. La clave se devuelve una sola vez y nunca vuelve a aparecer. Si la pierde, debe recrear el canal. La misma regla de clave de un solo uso se aplica a un canal de Logging Service.
  • Tratar "Kubernetes" en la lista de orígenes de Logging Service como visibilidad del plano de control. Se trata solo de los registros de carga de trabajo dentro del clúster; los eventos del plano de control nunca llegan allí. Despliegue un agente dentro del clúster y no espere eventos que no llegarán.
  • Suponer que la retención de los registros de flujo se gestiona por usted. Eliminar la regla de registro de flujo no elimina los objetos ya escritos, y no hay caducidad automática. Sin una política de ciclo de vida del cubo, el archivo crece y genera cargos indefinidamente.
  • Apuntar un registro de flujo a un cubo que no le pertenece o a uno en la región incorrecta. El destino debe ser un cubo propiedad del usuario; un destino incorrecto falla silenciosamente al entregar los registros.
  • Olvidar la ventana de 35 días del Activity Log. 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 de auditoría será irrecuperable.

5. Agregación (Fan-In) hacia un SIEM externo

Para una empresa como FinCorp, el modelo por contrato, por región y de cuatro planos no produce la única vista correlacionada que necesitan tanto el equipo de operaciones de seguridad como el auditor. El patrón empresarial es la agregación (fan-in): cada plano de cada contrato fluye hacia un único SIEM externo que se convierte en el sistema de registro para la correlación, la retención a largo plazo y la generación de alertas en toda la infraestructura. La plataforma le proporciona las uniones necesarias para realizar esto sin un reenviador administrado:

  • Registros y métricas: dirija sus agentes (o los reenviadores iniciados por el producto de Central Logging) hacia las pipelines de IONOS CLOUD para Grafana dentro de la plataforma, y en paralelo reenvíe los mismos flujos desde sus agentes al colector del SIEM. El Logging Service también expone una API de Telemetría de solo lectura (autenticada con el mismo token de Cloud API) que un SIEM puede consultar mediante sondeo, aunque el doble envío desde el lado del agente es la ruta más directa.
  • Flujo de red: los Flow Logs ya se almacenan en Object Storage como texto gzip; el SIEM los ingiere desde el cubo, que también sirve como archivo duradero.
  • Auditoría: un trabajo programado recupera el Activity Log a través de su API de solo GET antes de que se cierre la ventana de 35 días y reenvía los registros al SIEM, satisfaciendo simultáneamente la retención a largo plazo y la correlación entre contratos.
  • VMware híbrido: la API REST de vSphere y las alarmas de vCenter se reenvían desde la infraestructura dedicada al mismo SIEM, unificando así los dos dominios de observabilidad en el único punto donde la unificación tiene sentido.

Esta es la misma lección de composición que la plataforma repite en otras partes: no existe un producto administrado de agregación entre contratos, por lo que usted debe componer uno. Object Storage es el centro duradero, el SIEM es el cerebro de correlación y los puntos de acceso por plano son las tomas.

Resumen

La observabilidad de IONOS CLOUD consta de cuatro planos de alcance fijo (métricas a través de Monitoring Service, registros a través de 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 los datos de auditoría y de flujo ubicados fuera de ese panel por diseño. El trabajo operativo fundamental consiste en enrutar cada señal de manera deliberada, diseñar en torno a las tres carencias (ausencia de eventos del plano de control en el plano de registros, ausencia de agregación entre contratos y una ventana de auditoría de 35 días), utilizar Central Logging para la reenvío iniciado por el producto, tratar el entorno dedicado de VMware como un dominio de observabilidad separado de vCenter/vSAN y distribuir todo hacia un SIEM externo, donde realmente se llevan a cabo la correlación y la retención a largo plazo.

Puntos clave:

  • Cuatro planos, alcances fijos: Monitoring Service (métricas de Prometheus, basadas en envío, Grafana Mimir), Logging Service (cinco tipos de origen, 5 flujos por canalización, retención de 7/14/30 días o ilimitada), Activity Logs (solo lectura mediante GET, ventana de 35 días), Flow Logs (registros de 5-tupla hacia un cubo de Object Storage propiedad del usuario, retención gestionada por el cliente).
  • El canal de métricas de Monitoring Service puede crearse desde un formulario de creación de DCD o a través de la API; la clave de canalización de un solo uso debe guardarse en el momento de la creación.
  • Los eventos del plano de control de Kubernetes nunca llegan a Logging Service; debe instrumentar las cargas de trabajo con un agente dentro del clúster y tratar el "Logging to S3" del clúster como una ruta separada.
  • No existe agregación entre contratos y la pista de auditoría se elimina a los 35 días, por lo que la agregación y la retención a largo plazo se construyen externamente, con Object Storage como centro duradero y un SIEM como punto de correlación.
  • Central Logging es un interruptor a nivel de contrato y por región (con control de administrador) que permite a los productos integrados reenviar registros en su nombre; el entorno dedicado de VMware se observa a través de vCenter 8.0 y vSAN, un dominio separado que solo se armoniza 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 su modelo de retención.
  • Central Logging: una capacidad a nivel de contrato y por región que permite a los productos integrados de IONOS CLOUD reenviar sus registros a Logging Service en su nombre, visible en Grafana gestionado.
  • Registro de flujo: una regla por recurso que emite registros de conexión de 5-tupla con la decisión ACCEPT/REJECT del cortafuegos hacia un cubo de Object Storage propiedad del cliente, rotado cada 10 minutos.
  • Fan-in: el patrón de agregación empresarial que consiste en reenviar cada plano de 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 la ruta de auditoría (el plano de auditoría y la fecha límite de exportación)
  • Unidad 3.2: Seguridad de red: Firewall y grupos de seguridad (los registros de flujo como herramienta de verificación del firewall)
  • Unidad 4.4: Private Cloud (VMware dedicado) (el entorno dedicado observado a través de vCenter y vSAN)
  • Unidad 6.1: Diseño de la plataforma Kubernetes (por qué los eventos del plano de control se encuentran fuera del plano de registro)
  • Centro de Arquitectura de IONOS CLOUD