19 min de lectura

Objetivos de aprendizaje

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

  • Asociar los cuatro planos de telemetría de IONOS (métricas, registros, auditoría, flujo de red) con sus alcances fijos y enrutar cada señal de manera deliberada en lugar de esperar que una sola consola muestre todo
  • Diseñar alrededor de las tres brechas de observabilidad que atrapan a los equipos en producción: eventos 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 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 de vCenter dedicada-VMware junto a los planos de la plataforma para una propiedad híbrida
  • 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 en un SIEM externo como el patrón de agregación empresarial

Unidad 7.2: Observabilidad y Operaciones

Introducción

La observabilidad en IONOS no es un solo producto. Se compone de 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 limita a "activar la monitorización"; implica decidir qué señal de alerta se coloca en qué plano, dónde se encuentran las uniones entre 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 de GDPR y BSI, necesita una vista operativa de grado de auditoría que abarque un núcleo regulado de Workload, una plataforma de Managed Kubernetes y una finca dedicada de VMware, 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 tubería de métricas con una alerta y un registro de flujo en el Data Center Designer, y se centra en el patrón de convergencia que da a FinCorp un solo lugar para correlacionar.

1. Los cuatro planos de telemetría y sus alcances 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, Agente de Grafana, OpenTelemetry o Fluent Bit, con un intervalo de empuje predeterminado de 1 minuto que es configurable. Detrás del punto de conexión, los datos aterrizan en Grafana Mimir y se visualizan en una instancia de Grafana gestionada 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 (un JSON REST API), y Genérico. El transporte es TLS sobre TCP (adelante de Fluent Bit, puerto 9000) o HTTPS (puerto 443). Cada tubería lleva 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 el mismo Grafana gestionado, pero la ventana de consulta de Grafana es de 30 días; cualquier cosa que se mantenga bajo retención ilimitada se lee de nuevo 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 de los usuarios, la provisión 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 de flujo por flujo (5-tupla más conteos de paquetes y bytes, más un campo action de ACEPTAR o RECHAZAR que muestra el veredicto Firewall) emitidos a un bucket Object Storage propiedad del cliente como texto comprimido gzip, rotado cada 10 minutos. Flow Logs se adjuntan a una NIC VM, un Managed Network Load Balancer, un Managed Application Load Balancer o un Managed NAT Gateway, y capturan IPv4 y IPv6. Este plano se construye en la Unidad 3.2 como la herramienta de verificación Firewall; reaparece aquí como la pierna de capa de red de la imagen operativa.

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

2. Los vacíos que debemos diseñar

Tres límites son los que causan 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 de control de Kubernetes no fluyen a través de la Logging Service. La Logging Service enumera a Kubernetes como una fuente compatible, pero eso significa que los registros de Workload y Node que envía desde dentro de la Cluster, no la parte gestionada del plano de control. El Acuerdo de Nivel de Servicio (SLA) de IONOS Managed Kubernetes solo cubre la parte de Kubernetes API del plano de control, y los eventos del plano de control no se emiten en su tubería de Logging Service. La Cluster ofrece un toggle separado "Registro en S3" que escribe los datos de registro de Cluster en un cubo de Object Storage; trátelo como una ruta habilitada de forma separada, no como visibilidad del plano de control en su Grafana. Para la observabilidad de Workload, se despliega un agente dentro de la Cluster (Fluent Bit para registros, un exportador compatible con Prometheus para métricas) que envía a sus tuberías de Registro y Monitorización. La costura es la línea entre el plano de control gestionado y sus cargas de trabajo: usted instrumenta las últimas, IONOS opera las primeras.

No hay agregación entre contratos. Las tuberías de Monitorización y Registro son por contrato y por región, y el Registro de Actividades es por contrato sin punto de agregación ni extremo de push. Si FinCorp divide la producción, la no producción y un Workload aislado por cumplimiento en contratos separados (la disciplina de límite de 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 de contrato a un colector externo (Sección 5).

La ventana de retención del Registro de Actividades 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 a años, la ventana de 35 días es una fecha límite de exportación, no una política de retención. El patrón documentado a largo plazo es descargar los datos del Registro de Actividades de forma programada y almacenarlos en un almacenamiento diferente, con IONOS Cloud Object Storage como el 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 se elimina.

3. Registro de logs centralizado y observabilidad híbrida de vCenter

3.1 Registro de logs 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 de logs centralizado es el interruptor de nivel de contrato, por región, que permite a los productos de IONOS Cloud integrados reenviar sus propios registros al Logging Service en su nombre, mostrados en el mismo Grafana gestionado, 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 se habilita el Registro de logs centralizado. El mismo modelo se extiende al Monitoreo centralizado para el Monitoring Service.

El Registro de logs centralizado debe activarse antes de que cualquier producto pueda ingerir 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, propietarios y usuarios con el privilegio "Acceder y gestionar Logging Service" pueden activarlo. Puede habilitarse desde el DCD (un interruptor de estado por región en la vista de Registro de logs centralizado de Logging Service), desde el API de Registro de logs, o por un producto integrado en su nombre. Qué productos se integran se confirma a través de su gestor de cuenta o Soporte de IONOS Cloud, en lugar de publicarse como una lista estática, así que trate al conjunto compatible como algo que verificar por compromiso.

3.2 Observabilidad de vCenter para el patrimonio de VMware dedicado

El núcleo regulado de FinCorp se ejecuta en IONOS Private Cloud, el VMware SDDC gestionado dedicado (Unidad 4.4). Su telemetría no fluye en los cuatro planos de plataforma. En su lugar, la observabilidad de 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 de host, Cluster y VM, eventos y alarmas, y monitoreo de salud y capacidad de vSAN expuesto en el Panel de Cloud para la capa de almacenamiento. El REST API de vSphere (limitado 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 del VMware dedicado es vCenter y vSAN. No suponga un puente gestionado de cruz de plano 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 se ejecutan lado a lado, los cuatro planos de plataforma para recursos nativos de la nube y vCenter/vSAN para el núcleo de VMware dedicado, reconciliados solo donde usted reenvía deliberadamente ambos a un colector externo común.

4. DCD Implementación paso a paso

Usted implementará 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 borde Load Balancer. Esto realiza dos de los cuatro planos de la Sección 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 Flow Logs.

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 Flow Logs" para el trabajo de registro de flujo, y el privilegio "Acceso y administración de Monitoring" para la canalización de métricas. Salida HTTPS en el puerto 443 desde cualquier lugar donde se ejecuten los agentes de métricas.

Parte A: la canalización de métricas (Monitoring Service). Tenga en cuenta un límite de plataforma importante: la canalización de métricas Monitoring Service se crea a través de la API de Monitoring Service, no a través de un formulario de creación de DCD. El ciclo de vida de la canalización (creación, recuperación, modificación, eliminación) es API-only en este momento; la superficie de DCD es para acceder al Grafana resultante, no para aprovisionar la canalización. Trate lo siguiente como la ruta de creación de nivel API, luego mueva a Grafana para alertas.

  1. Elija el punto de conexión regional que coincida 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, así que manténgala coherente con la decisión de residencia de Workload.
  2. Cree la canalización con un PUT (o POST) en ese punto de conexión que lleva un properties.name, autenticado con un token Bearer. La respuesta incluye una clave de un solo uso key en sus metadatos y un grafanaEndpoint. Guarde la clave al crear; por motivos de seguridad, no se devuelve de nuevo, 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 en el punto de conexión HTTP con api/v1/push agregado al camino, enviando la clave guardada como encabezado de autorización Bearer en 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 grafanaEndpoint devuelta y confirme que las métricas son consultables, lo que 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 preocupa (para el nivel de aplicación sin estado de FinCorp, un umbral de utilización de CPU que debe preceder a una acción de escalado automático), y adjunte un punto de contacto para que la regla notifique al canal de llamada. La alerta de Grafana es la superficie de alerta; no hay un objeto de alerta de IONOS por separado para el plano de métricas.

Una llamada de creación ilustrativa (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 real de DCD, conectada 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 Object Storage), así que nómbrelo para el recurso y el entorno.
  3. Establezca la Dirección en Ingreso, Egreso o Bidireccional, y la Acción en Rechazado, Aceptado o Cualquiera. Para una postura de investigación de seguridad, Bidireccional más Rechazado muestra lo que el Firewall está bloqueando; para el análisis de capacidad y conexión, Aceptado es el conjunto útil.
  4. Establezca el bucket de destino Object Storage en su bucket existente de 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 que los objetos de registro de flujo caducen, porque los Flow Logs 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:

  • Esperar un botón "crear pipeline" para métricas en el DCD. El pipeline de Monitoring Service es proporcionado por API; solo el acceso a Grafana llega a la experiencia de DCD. Planifique la construcción de métricas como un paso de API, no como un clic en la consola.
  • No guardar la clave de la tubería de monitoreo al crearla. La clave se devuelve una vez y nunca más. Si la pierde, debe volver a crear la tubería. La misma regla de clave de un solo uso se aplica a una tubería de Logging Service.
  • Tratar "Kubernetes" en la lista de fuentes de Logging Service como visibilidad del plano de control. Son solo los registros de Workload dentro de Cluster; los eventos del plano de control nunca llegan allí. Implemente un agente dentro de Cluster y no espere eventos que no llegarán.
  • Suponer que la retención del registro de flujo es administrada por usted. Eliminar la regla de 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 se factura para siempre.
  • Apuntar un registro de flujo a un bucket que no es de su propiedad o que está en la región incorrecta. El destino debe ser un bucket de propiedad del usuario; apuntar incorrectamente a un bucket falla silenciosamente al entregar registros.
  • Dejar una tubería inactiva en ejecución. Una tubería de registro o monitoreo se factura desde su creación hasta su eliminación, independientemente de si fluye algún dato; detener el agente no detiene el cargo. Elimine las tuberías que no esté utilizando.
  • 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 de auditoría 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 necesita un equipo de operaciones de seguridad y un auditor. El patrón de empresa 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, la retención a largo plazo y la alerta en todo el estado. La plataforma le proporciona las costuras 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 para Grafana en la plataforma, y en paralelo envíe los mismos flujos desde sus agentes al colector de SIEM. El Logging Service también expone un Telemetría de solo lectura API (/api/v1/query, /api/v1/query_range, /api/v1/series, autenticado con el mismo token de Cloud API) 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 actúa como archivo duradero.
  • Auditoría: un trabajo programado extrae el Registro de Actividad a través de su API de solo lectura API 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.
  • Híbrido VMware: los alarmas de vSphere REST API y 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. El Object Storage es el centro duradero, el SIEM es el cerebro de correlación y los puntos finales de cada plano son las llaves.

Resumen

La observabilidad de IONOS consta de cuatro planos de alcance fijo (métricas a través de la Monitoring Service, registros a través de la Logging Service, auditoría a través de la Activity Logs y flujo de red a través de la 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 enrutiar cada señal de manera deliberada, diseñar alrededor de las tres brechas (no hay eventos de control de plano en el plano de registro, no hay agregación entre contratos, una ventana de auditoría de 35 días), utilizando la registrazione centralizada para el envío iniciado por el producto, tratando la finca dedicada-VMware como un dominio de observabilidad de vCenter/vSAN separado, y distribuyendo todo en 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 de Prometheus, basadas en push, Grafana Mimir), Logging Service (cinco tipos de origen, 5 flujos por tubería, 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 tubería de métricas de Monitoring Service es provista por API, no es un formulario de creación de DCD; la clave de tubería de una sola vez debe guardarse en la creación, y las tuberías inactivas siguen facturando.
  • Los eventos de control de plano de Kubernetes nunca llegan a la Logging Service; instrumente las cargas de trabajo con un agente dentro de Cluster y trate a Cluster "Registro en S3" como una ruta separada.
  • No hay agregación entre contratos y el rastro 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 el centro duradero y un SIEM como el punto de correlación.
  • La registrazione centralizada es un interruptor de nivel de contrato y por región (controlado por el administrador) que permite a los productos integrados de IONOS Cloud enviar registros para usted; la finca dedicada-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.
  • Registro centralizado: una capacidad de nivel de contrato y por región que permite a los productos integrados de IONOS Cloud enviar sus registros a la Logging Service en su nombre, presentado en el Grafana administrado.
  • Registro de flujo: una regla de recurso que emite registros de conexión de 5 tuplas con el veredicto de Firewall ACEPTAR/RECHAZAR a un bucket de Object Storage propiedad del cliente, rotado cada 10 minutos.
  • Agregación: el patrón de agregación empresarial de envío de 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 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 (Flow Logs como herramienta de verificación de 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 plano de control se encuentran fuera del plano de registro)
  • Centro de arquitectura de IONOS Cloud