Infraestructura y procesos en entornos no K8s

Resumen

Este blueprint describe una referencia estratégica para los equipos de Platform Engineering y SRE que operan en entornos tradicionales de máquinas virtuales (VM), bare metal y on-premises, incluidos los escenarios en los que los contenedores se ejecutan directamente sobre un sistema operativo sin un orquestador como Kubernetes.

Aborda la fricción que suele encontrarse al intentar establecer una observabilidad coherente en infraestructuras heterogéneas, procesos heredados y cargas de trabajo en contenedores.

Al implementar los patrones de este blueprint, las organizaciones pueden esperar lograr los siguientes resultados:

• Telemetría de alta calidad y lista para usar en aplicaciones y servicios que se ejecutan en entornos no Kubernetes, incluidos los contenedores gestionados directamente.
• Gestión coherente del ciclo de vida de los agentes de OpenTelemetry, junto con patrones estandarizados de inicialización y configuración para la instrumentación basada en SDK.
• Observabilidad unificada en infraestructuras mixtas: VMs, bare metal y contenedores sin orquestador.
• Mejor gobernanza sobre la calidad de las señales de telemetría, el enriquecimiento de datos, el enrutamiento y las canalizaciones de exportación.
• Menor esfuerzo manual y carga cognitiva para desarrolladores y operadores.

Contexto

Muchas organizaciones mantienen una combinación de infraestructura heredada, VMs, servidores bare metal y despliegues de contenedores directos al runtime, además de Kubernetes o en lugar de este. Estos entornos pueden ser complejos y, a menudo, carecen de la automatización y estandarización que ofrecen los orquestadores. Garantizar una observabilidad coherente y de alta calidad en estos escenarios es fundamental, pero con frecuencia se ve obstaculizado por herramientas fragmentadas y procesos manuales.

El Open Agent Management Protocol (OpAMP) proporciona una forma estandarizada de gestionar, configurar y monitorizar de forma remota los agentes de OpenTelemetry en infraestructuras diversas donde esté soportado. En el momento de escribir esto, la especificación de OpAMP está en fase Beta, por lo que las organizaciones deben evaluar la madurez de la implementación y el soporte operativo antes de estandarizar una solución concreta. Cuando OpAMP aún no sea adecuado, las bibliotecas compartidas, las imágenes preconstruidas, los artefactos de configuración mantenidos de forma centralizada y las herramientas existentes de despliegue o gestión de configuración pueden seguir proporcionando una gestión coherente del ciclo de vida para la instrumentación basada en SDK y en agentes.

Retos comunes

Las organizaciones que operan en entornos no Kubernetes suelen enfrentarse a una serie de retos que dificultan una observabilidad eficaz. Sin automatización integrada, estandarización y gestión centralizada, estos entornos a menudo tienen dificultades para garantizar una telemetría coherente y de alta calidad en un panorama diverso de infraestructura y aplicaciones. Muchos de estos retos de observabilidad no son exclusivos de los entornos no Kubernetes. Sin embargo, en los entornos no Kubernetes, los equipos suelen contar con menos mecanismos de plataforma integrados para la gestión de despliegues progresivos, el descubrimiento de servicios, el enriquecimiento de metadatos y la distribución centralizada de políticas.

1. Automatización limitada para el despliegue y la gestión de la telemetría

La instrumentación y el despliegue de agentes en VMs, bare metal y contenedores gestionados directamente suele ser manual o basado en scripts, y la configuración continua es difícil de gestionar a escala. Este enfoque descentralizado y ad hoc suele requerir que el personal de operaciones o de desarrollo instale, configuren y actualicen los agentes de OpenTelemetry individualmente en cada host o carga de trabajo.

Esto conduce a:

• Alto esfuerzo manual: las nuevas cargas de trabajo o hosts requieren pasos de configuración repetidos y propensos a errores.
• Ciclos lentos de despliegue y actualización: las actualizaciones de la instrumentación o la configuración son lentas y difíciles de propagar en toda la flota.
• Riesgo operativo: los retornos a versiones anteriores, el control de versiones y la monitorización del estado son más difíciles de realizar de forma coherente en toda la infraestructura.

Esta brecha de automatización también sienta las bases para la fragmentación descrita en el Reto 2: cuando cada host o carga de trabajo se configura manualmente, los equipos tienden a tomar decisiones independientes sobre agentes, SDKs y exportadores que luego resultan difíciles de conciliar.

2. Enfoques de instrumentación fragmentados

Partiendo de la falta de automatización descrita en el Reto 1, la ausencia de patrones estandarizados de despliegue y gestión lleva a los equipos a adoptar distintos agentes, SDKs o exportadores de OpenTelemetry para las cargas de trabajo basadas en hosts y en contenedores.

Esto conduce a:

• Convenciones semánticas inconsistentes: las señales de telemetría pueden carecer de atributos de recurso estándar como service.name, host.id, host.name, container.id y deployment.environment, lo que dificulta la correlación entre sistemas.
• Comportamiento de instrumentación divergente: distintos equipos pueden aplicar valores predeterminados diferentes para el muestreo, la propagación, la detección de recursos o la exportación, lo que produce una calidad de telemetría desigual.
• Desviación de configuración manual: los agentes basados en hosts y en contenedores suelen requerir configuración manual, lo que provoca derivas y un mayor riesgo de errores.

3. Procesamiento y exportación de datos aislados

La brecha de automatización (Reto 1) y la consiguiente fragmentación (Reto 2) se agravan en la capa de la canalización de datos: las canalizaciones de recopilación y exportación de datos suelen configurarse por aplicación, por host o por equipo. Ante la ausencia de una gestión centralizada, los equipos individuales pueden configurar de forma independiente agentes de telemetría, exportadores y lógica de procesamiento de datos para cada carga de trabajo o entorno.

Esto conduce a:

• Esfuerzo duplicado: los equipos pueden duplicar la lógica de enriquecimiento, filtrado y enrutamiento de datos en distintos entornos.
• Aplicación inconsistente de políticas: las políticas de redacción, comportamiento de reintentos, agrupación (batching) y enrutamiento pueden variar entre equipos.
• Falta de visibilidad: los equipos de operaciones y gobernanza carecen de un control unificado sobre qué telemetría se recopila y cómo se procesa o exporta.

Directrices generales

Para abordar los retos descritos anteriormente, las organizaciones deben adoptar un conjunto de directrices estratégicas diseñadas para optimizar las prácticas de observabilidad en entornos diversos. Estas directrices ofrecen una base para estandarizar la instrumentación, automatizar la gestión de agentes y garantizar una calidad de datos coherente.

1. Gestionar de forma centralizada el ciclo de vida de los agentes permitiendo una personalización controlada

Retos abordados: 1, 2

Usa OpAMP, donde esté soportado y sea operativamente adecuado, para gestionar de forma centralizada los agentes de OpenTelemetry que se ejecutan como servicios del sistema o contenedores de servicio.

Dado que la especificación de OpAMP está actualmente en fase Beta, las organizaciones deben evaluar la madurez y el nivel de soporte de las implementaciones disponibles en su entorno antes de estandarizar en torno a una solución concreta. Donde OpAMP no esté soportado o aún no sea adecuado, las organizaciones deben usar otros mecanismos de gestión centralizada, como herramientas de gestión de configuración, imágenes doradas (golden images) o artefactos de despliegue estandarizados, para mantener un despliegue, configuración y gestión del ciclo de vida de los agentes coherentes.

Independientemente del mecanismo de gestión, los equipos de plataforma deben ser responsables de la distribución base del agente, los procesadores y exportadores requeridos, la configuración de seguridad, el reporte de estado y el comportamiento predeterminado de detección de recursos.

Al mismo tiempo, las organizaciones deben definir explícitamente cómo se permite la personalización específica de entorno o de carga de trabajo. Un modelo práctico consiste en usar un enfoque de configuración por capas:

• Una base propiedad de la plataforma, normalmente a cargo de ingeniería de plataforma, para los valores predeterminados obligatorios, los controles de seguridad y los procesadores/exportadores de toda la organización.
• Una capa de entorno (overlay), normalmente a cargo de infraestructura u operadores de entorno, para diferencias como endpoints, tenencia (tenancy), entorno de despliegue, metadatos específicos del sitio o configuraciones específicas de red.
• Una capa de carga de trabajo (overlay), normalmente a cargo de equipos de aplicación dentro de los límites definidos por la plataforma, para variaciones aprobadas como receptores opcionales (opt-in), atributos de recurso adicionales o parámetros de ajuste seguros.

Esto crea un límite claro entre la estandarización y la flexibilidad: los equipos pueden extender las partes aprobadas de la configuración sin crear despliegues puntuales y no gestionados.

Al implementar esta directriz, las organizaciones pueden esperar lograr:

• Configuración de telemetría automatizada y coherente en todos los entornos.
• Menos errores manuales y una incorporación simplificada para nuevas cargas de trabajo.
• Actualizaciones y reversiones más rápidas y seguras de las configuraciones de los agentes.
• Un mecanismo controlado para la personalización local sin sacrificar la gobernanza central.

2. Centralizar la recopilación y el procesamiento de telemetría a través de una capa de gateway de OpenTelemetry Collector

Retos abordados: 2, 3

Despliega uno o más gateways de OpenTelemetry Collector como puntos de agregación para la telemetría procedente de hosts y contenedores gestionados directamente. En este contexto, «centralizado» no significa necesariamente un único despliegue global. Dependiendo de la estructura organizativa, los límites de red, los requisitos de aislamiento y los patrones de tráfico, la capa de gateway puede implementarse en distintos niveles, como por región, por sitio, por entorno o por cuenta en la nube, a la vez que proporciona una aplicación de políticas centralizada dentro de ese ámbito.

En entornos no Kubernetes, estos gateways pueden desplegarse usando varios patrones, según la escala y el modelo operativo, entre ellos:

• VMs o hosts bare metal dedicados.
• Un grupo (pool) de servicios detrás de un balanceador de carga.
• Servicios de gateway en contenedores que se ejecutan en cómputo de propósito general.
• Gateways regionales o propios del sitio para entornos distribuidos.

El siguiente diagrama muestra el nivel de gateway con sus patrones de despliegue alternativos. Cada recuadro representa una forma distinta de implementar el rol de gateway; una organización normalmente elige un patrón, o combina patrones entre sitios:

flowchart TD
    S[Fuentes de telemetría<br/>Hosts y contenedores]
    B[(Backends de<br/>observabilidad)]

    subgraph G1["Patrón&nbsp;1"]
        P1[VMs dedicadas /<br/>Hosts bare metal]
    end

    subgraph G2["Patrón&nbsp;2"]
        P2[Pool de servicios detrás<br/>de un balanceador de carga]
    end

    subgraph G3["Patrón&nbsp;3"]
        P3[Gateways en contenedores<br/>sobre cómputo general]
    end

    subgraph G4["Patrón&nbsp;4"]
        P4[Gateways regionales /<br/>locales al sitio]
    end

    S --> G1 --> B
    S --> G2 --> B
    S --> G3 --> B
    S --> G4 --> B

Al implementar esta directriz, las organizaciones pueden esperar lograr:

• Control unificado sobre el procesamiento de datos, el enriquecimiento y las canalizaciones de exportación.
• Gobernanza simplificada y una implementación más sencilla de las políticas de toda la organización.
• Menos conexiones directas de hosts o aplicaciones a backends de observabilidad externos, lo que puede simplificar la gestión de firewalls y políticas de red.
• Mayor resiliencia y escalabilidad que las topologías de exportación por host o por aplicación.
• Una separación clara entre la recopilación local y la aplicación de políticas centralizada.

3. Estandarizar la atribución de recursos y distribuir bloques de instrumentación reutilizables

Retos abordados: 2

Define un estándar de telemetría a nivel de organización para la atribución de recursos y asegúrate de que se aplique de forma coherente en todas las cargas de trabajo. Esto no debe depender únicamente de la documentación; debe entregarse a través de bloques de construcción reutilizables como:

• Imágenes de agente preconstruidas.
• Agentes de lenguaje empaquetados y artefactos de auto-instrumentación cuando corresponda.
• Binarios o distribuciones estandarizadas de OpenTelemetry Collector.
• Bibliotecas compartidas o paquetes iniciales para la instrumentación basada en SDK.
• Wrappers de inicialización estándar o convenciones de variables de entorno.
• Fragmentos o plantillas de configuración mantenidos de forma centralizada.

El modelo de recursos recomendado para entornos no Kubernetes debe alinearse con las convenciones semánticas de recursos de OpenTelemetry y basarse en la detección automática de recursos siempre que sea posible. En OpenTelemetry, un recurso identifica la entidad que produjo la telemetría, como un host, una VM, un proceso, un contenedor o una instancia de servicio. En la práctica, las organizaciones deben asegurarse de que la telemetría pueda correlacionarse en los siguientes dominios de recursos, usando atributos detectados automáticamente cuando estén soportados:

• Host
• Dispositivo (cuando corresponda)
• Proceso
• Runtime del proceso
• Sistema operativo
• Contenedor (cuando corresponda)
• Identidad del servicio

En lugar de mantener manualmente todos los atributos correspondientes, las organizaciones deben preferir la instrumentación existente y la detección de recursos para los metadatos de host, proceso, runtime, SO y contenedor, y usar configuración compartida o artefactos de inicialización para mantener esa detección habilitada de forma coherente.

El área que suele requerir la estandarización más deliberada es la identidad del servicio. Las organizaciones deben asegurarse de que la telemetría del servicio use las convenciones semánticas de servicio adecuadas, con atributos como service.name y, cuando sea relevante, service.version, service.namespace, service.instance.id y deployment.environment.

Qué atributos de servicio deben estar presentes depende de cómo se despliegan e identifican las cargas de trabajo en el entorno. Por ejemplo, service.namespace puede ser útil para distinguir servicios entre límites organizacionales o de plataforma, mientras que service.instance.id puede ser necesario para distinguir instancias replicadas del mismo servicio.

La telemetría de la aplicación debe incluir suficiente contexto de servicio e infraestructura para admitir la correlación con la telemetría a nivel de host e infraestructura, usando las convenciones semánticas como fuente de verdad sobre qué atributos identificativos se aplican a cada tipo de recurso.

Al implementar esta directriz, las organizaciones pueden esperar lograr:

• Mejor correlación y capacidad de búsqueda de los datos de telemetría entre sistemas.
• Análisis y resolución de problemas más sencillos, independientemente del tipo de infraestructura.
• Calidad de metadatos coherente sin requerir que cada equipo reinvente los patrones de instrumentación.
• Adopción más rápida gracias a bloques de construcción reutilizables y soportados.

Implementación

Llevar estas directrices a la práctica requiere una combinación de automatización, herramientas estandarizadas y gestión centralizada. Los pasos de implementación a continuación se presentan como elementos de una hoja de ruta, con acciones al estilo de una lista de verificación que las organizaciones pueden planificar y ejecutar en secuencia.

1. Definir un estándar base de telemetría y un modelo de configuración por capas

Directrices respaldadas: 1, 3

Define el estándar mínimo de telemetría requerido para la organización y documenta qué partes de la configuración de telemetría son propiedad central y cuáles son personalizables localmente. Esto incluye la configuración soportada para agentes de host o servicio, agentes de lenguaje cuando corresponda, instrumentación basada en SDK y OpenTelemetry Collectors usados para la recopilación o el reenvío local. Cuando se use OpAMP, debe alinearse con este modelo para que la configuración de agentes gestionada de forma centralizada siga la misma base y las capas aprobadas. Esta es la base para la coherencia a escala.

Lista de verificación:

• Define los atributos de recurso obligatorios y las convenciones de señal que todas las cargas de trabajo deben emitir.
• Define la configuración base para los componentes de telemetría soportados, incluidos agentes, agentes de lenguaje cuando corresponda, SDKs y OpenTelemetry Collectors.
• Estandariza exportadores, autenticación, TLS, reporte de estado y procesadores predeterminados según el rol de cada componente.
• Define los puntos de extensión permitidos para la personalización específica de entorno y de carga de trabajo.
• Versiona todas las configuraciones base y de capas para que puedan desplegarse y revertirse de forma segura.
• Publica los límites de propiedad para que los equipos sepan qué pueden y qué no pueden modificar.

Documentación:

• Especificación de OpAMP
• Convenciones semánticas de OpenTelemetry

2. Establecer un plano de gestión de OpAMP para los agentes

Directrices respaldadas: 1

Proporciona una capacidad central de gestión de OpAMP para gestionar la configuración de agentes, el reporte de estado, la monitorización de salud y los despliegues progresivos controlados para los agentes soportados. Este blueprint recomienda el patrón de gestión, no ninguna implementación de servidor de ejemplo específica; las organizaciones deben usar una solución lista para producción adecuada a su entorno.

Lista de verificación:

• Decide qué agentes o despliegues de OpenTelemetry Collector se gestionarán a través de OpAMP, según las capacidades de las distribuciones usadas en tu entorno (por ejemplo, si son upstream o específicas de un proveedor, si integran un cliente de OpAMP, si usan un Supervisor de OpAMP para el OpenTelemetry Collector, y si OpAMP está compilado de forma integrada o empaquetado por separado), y los componentes que quieres gestionar de forma centralizada.
• Establece o adopta un servidor de OpAMP o un endpoint de gestión listo para producción, siguiendo la documentación de gestión del Collector, con la autenticación, autorización y seguridad de transporte adecuadas.
• Configura los agentes o supervisores para que se registren en el servicio de gestión e informen su identidad, capacidades, estado de salud y estado de configuración efectiva, según lo definido por la especificación de OpAMP.
• Organiza los agentes en grupos lógicos como desarrollo, staging, producción, región o entorno para que los cambios de configuración puedan desplegarse por etapas.
• Define cómo se promueven las actualizaciones de configuración entre los grupos de despliegue y cómo se detectan y revierten los cambios fallidos.
• Monitoriza la salud del plano de gestión, la conectividad de los agentes, el estado de las actualizaciones y la desviación de configuración para asegurar que la flota permanezca bajo control.

OpAMP puede integrarse con el OpenTelemetry Collector de dos formas, con distintos alcances de capacidad:

• Usando un Supervisor de OpAMP: un proceso separado y local al host que gestiona el ciclo de vida del Collector y aplica la configuración remota, además de reportar estado, salud y capacidades. Esta es la integración más completa y es adecuada cuando OpAMP es el mecanismo principal para la gestión de configuración y ciclo de vida.

• Usando la extensión de OpAMP integrada del Collector: una integración ligera que reporta estado, salud y capacidades al servicio de gestión, pero no gestiona la entrega de configuración remota ni el ciclo de vida. Esto es adecuado cuando la configuración y el ciclo de vida ya son gestionados por otras herramientas (por ejemplo, gestión de configuración, imágenes doradas o distribuciones empaquetadas) y OpAMP se usa principalmente para la observabilidad centralizada de la flota de agentes.

En un despliegue basado en Supervisor, el servicio de gestión se comunica con el Supervisor local al host, que luego gestiona el ciclo de vida y la configuración del agente o Collector local. El siguiente diagrama ilustra el patrón de Supervisor; el patrón de solo extensión se ve similar, pero sin el recuadro del Supervisor y con el servicio de gestión comunicándose directamente con el Collector solo para el reporte de estado.

flowchart TB
    M[Servicio central de gestión OpAMP]

    subgraph H1[Host o VM]
        S1[Supervisor de OpAMP]
        A1[Agente u OpenTelemetry Collector]
        S1 --> A1
    end

    subgraph H2[Host o VM]
        S2[Supervisor de OpAMP]
        A2[Agente u OpenTelemetry Collector]
        S2 --> A2
    end

    subgraph H3[Host o VM]
        S3[Supervisor de OpAMP]
        A3[Agente u OpenTelemetry Collector]
        S3 --> A3
    end

    M -->|Gestión de configuración y ciclo de vida| S1
    M -->|Gestión de configuración y ciclo de vida| S2
    M -->|Gestión de configuración y ciclo de vida| S3

    S1 -->|Estado, salud y capacidades| M
    S2 -->|Estado, salud y capacidades| M
    S3 -->|Estado, salud y capacidades| M

    A1 --> O[Backend de observabilidad]
    A2 --> O
    A3 --> O

Documentación:

• Especificación de OpAMP
• Guía de introducción a OpAMP
• Configuración del OpenTelemetry Collector

3. Empaquetar y desplegar agentes estandarizados y artefactos de inicialización de SDK

Directrices respaldadas: 1, 3

Usa la gestión de configuración y el empaquetado de imágenes para entregar los componentes de telemetría soportados de forma coherente en hosts y cargas de trabajo en contenedores. Prefiere la configuración declarativa para la instrumentación basada en SDK cuando esté soportada. Cuando no esté disponible, estandariza las variables de entorno, las opciones de inicialización o los patrones de configuración específica del SDK para que los equipos hereden valores predeterminados coherentes con una configuración manual mínima.

Los patrones de empaquetado comunes incluyen paquetes de servicio de sistema estándar para agentes basados en host, imágenes de contenedor preconstruidas para despliegues de Collector o agente, y artefactos de inicialización de SDK compartidos como paquetes iniciales o wrappers de inicialización. Por ejemplo:

• Un Collector basado en host puede instalarse como un servicio de sistema estándar con un archivo de configuración y un archivo de entorno gestionados de forma centralizada.
• Un despliegue en contenedores puede usar una imagen preconstruida que incluya el binario del Collector aprobado, las extensiones y la configuración predeterminada.
• La instrumentación basada en SDK puede distribuirse a través de wrappers de inicialización compartidos, agentes de lenguaje o paquetes iniciales que apliquen automáticamente los valores predeterminados aprobados por la organización.

Lista de verificación:

• Empaqueta los agentes basados en host como servicios de sistema estándar.
• Proporciona imágenes preconstruidas o definiciones de contenedores de servicio para los despliegues en contenedores.
• Publica bibliotecas compartidas, paquetes iniciales o wrappers de inicialización para los lenguajes de SDK soportados.
• Prefiere la configuración declarativa del SDK cuando esté soportada, y de lo contrario estandariza las convenciones de variables de entorno, inicialización y archivos de configuración en todos los entornos.
• Valida que las nuevas cargas de trabajo hereden la configuración base de forma predeterminada.

Documentación:

• Configuración del OpenTelemetry Collector
• SDKs y APIs de lenguaje de OpenTelemetry
• Instrumentación sin código de OpenTelemetry
• Instrumentación sin código de Java
• Configuración del agente de Java

4. Desplegar una capa de gateway de OpenTelemetry Collector

Directrices respaldadas: 2

Despliega uno o más gateways de OpenTelemetry Collector como el nivel central de procesamiento y exportación. Elige una topología adecuada para el entorno, como VMs dedicadas, pools de servicios detrás de un balanceador de carga o nodos de gateway regionales.

Lista de verificación:

• Selecciona la topología de despliegue del gateway para cada entorno.
• Define cómo los agentes locales descubren y se conectan a los gateways.
• Configura procesadores para agrupación (batching), protección de memoria, enriquecimiento, reintentos y enrutamiento.
• Separa la ingesta ligera del procesamiento centralizado más pesado cuando la escala lo requiera.
• Define el comportamiento de alta disponibilidad y conmutación por error (failover) para los gateways.
• Valida el enrutamiento de extremo a extremo hacia los backends de observabilidad.

Un patrón común en entornos no Kubernetes es ejecutar Collectors a nivel de host en hosts individuales y reenviar la telemetría a un gateway de Collector local al sitio o a la región. Esa capa de gateway debe ser escalable horizontalmente y de alta disponibilidad, usando mecanismos adecuados de balanceo de carga y conmutación por error para el entorno, como patrones de escalado nativos de la nube o configuraciones de alta disponibilidad equivalentes en infraestructura no basada en la nube.

flowchart TB
    subgraph S1[Sitio o unidad de negocio A]
        A1[VM o host bare metal]
        A2[VM o host bare metal]
        A3[Host con contenedores gestionados directamente]

        AC1[Collector a nivel de host]
        AC2[Collector a nivel de host]
        AC3[Collector a nivel de host]

        A1 --> AC1
        A2 --> AC2
        A3 --> AC3

        AC1 --> AG[Gateway de Collector local al sitio]
        AC2 --> AG
        AC3 --> AG
        AG --> P1[Procesamiento y aplicación de políticas local al sitio]
    end

    subgraph S2[Sitio o unidad de negocio B]
        B1[VM o host bare metal]
        B2[Host con contenedores gestionados directamente]

        BC1[Collector a nivel de host]
        BC2[Collector a nivel de host]

        B1 --> BC1
        B2 --> BC2

        BC1 --> BG[Gateway de Collector local al sitio]
        BC2 --> BG
        BG --> P2[Procesamiento y aplicación de políticas local al sitio]
    end

    P1 --> O[Backend de observabilidad]
    P2 --> O

Documentación:

• Patrones de despliegue del OpenTelemetry Collector
• Configuración del OpenTelemetry Collector

5. Aplicar los estándares de atribución de recursos y correlación

Directrices respaldadas: 1, 3

Asegúrate de que toda la telemetría incluya los metadatos necesarios para la correlación entre las capas de infraestructura y aplicación.

Lista de verificación:

• Define qué recursos de host, proceso, runtime, sistema operativo y contenedor deben detectarse y correlacionarse, y habilita la detección automática de recursos de forma coherente para ellos mediante configuración compartida, artefactos de inicialización o plantillas mantenidas de forma centralizada.
• Asegúrate de que la telemetría de la aplicación incluya suficiente contexto de infraestructura para la correlación, como host.id o host.name cuando corresponda, por ejemplo mediante configuración de SDK, agentes de lenguaje, wrappers de inicialización o detección automática de recursos cuando esté soportada.
• Habilita y valida los detectores de recursos siempre que estén soportados, para que los metadatos de host, SO, proceso, runtime y contenedor se completen de forma automática y coherente, y complementa la salida de los detectores con atributos definidos centralmente cuando sea necesario.
• Valida la telemetría emitida frente al estándar de atributos definido, revisando telemetría representativa de hosts y aplicaciones antes de un despliegue amplio.
• Añade comprobaciones de conformidad a las canalizaciones de despliegue o a los pasos de validación posteriores al despliegue para que las nuevas cargas de trabajo puedan verificarse frente al conjunto de atributos esperado.

Este blueprint se centra en los requisitos de atributos y las prácticas a nivel de carga de trabajo necesarias para emitirlos de forma coherente. Los patrones más detallados de aplicación y normalización centralizada quedan fuera del alcance de esta sección y pueden tratarse por separado.

Documentación:

• Convenciones semánticas de OpenTelemetry
• Convenciones semánticas de recursos de OpenTelemetry

6. Centralizar la gobernanza, la aplicación de políticas y la gestión de cambios

Directrices respaldadas: 2, 3

Usa la capa de gateway del Collector y la configuración de propiedad central para aplicar reglas de toda la organización para el procesamiento, enrutamiento y exportación de la telemetría.

Lista de verificación:

• Define los exportadores y destinos de backend aprobados.
• Centraliza las políticas de redacción, filtrado, enriquecimiento y enrutamiento.
• Define políticas estándar de reintentos, agrupación (batching) y muestreo.
• Establece un proceso de excepción para las cargas de trabajo que necesiten un comportamiento distinto al predeterminado.
• Revisa periódicamente la calidad de la telemetría y el cumplimiento de las políticas.

Documentación:

• Configuración del OpenTelemetry Collector
• Despliegues de gateway del OpenTelemetry Collector

Arquitecturas de referencia

Los patrones descritos en este blueprint se han implementado con éxito en las siguientes organizaciones usuarias finales:

¡Próximamente!

¿Has implementado una arquitectura para este blueprint? Comparte tu experiencia o un enlace a tu artículo abriendo un issue en el repositorio de GitHub del End User SIG.