Exportación de Observabilidad
Para qué sirve esta pantalla
Exportación de Observabilidad es donde declaras las herramientas de observabilidad externas a las que tu despliegue envía su propia telemetría. Es una de las tres tarjetas de Observabilidad y Auditoría que no contienen ningún valor de configuración: administra registros, y cada uno es un destino con nombre, proveedor, endpoint, credencial y un estado activo o inactivo.
Detrás de las pestañas de la superficie viven dos planos independientes. Configuración contiene los backends del propio despliegue — la exportación agregada, con el identificador de tenant eliminado. Por tenant contiene un plano propio, donde un tenant recibe únicamente su propia telemetría etiquetada y nunca la de otro. Coexisten; el segundo no es un refinamiento del primero.
Se ofrecen cuatro proveedores, en este orden: Datadog, Dynatrace, Instana y OTLP genérico.
Se pueden exportar tres señales: trazas, métricas y registros. Un backend nuevo empieza con las trazas y las métricas activadas y los registros desactivados. Registros envía las líneas de registro de los servicios con su servicio, nivel y host; el texto del mensaje sale de la plataforma con los UUID y las direcciones de correo electrónico enmascarados, y el resto del texto se envía tal como está escrito.
El destino propio de un tenant nunca recibe registros.
Puede haber como máximo cinco backends de despliegue. La consola muestra el recuento frente a ese límite, y la sexta creación la rechaza la plataforma, no la pantalla.
Qué debe existir antes
Es una pantalla de plataforma: se alcanza en el contexto de plataforma y solo se sirve al tenant de plataforma. Los permisos son propios de este subsistema, y tener la lectura de la configuración de plataforma no los incluye:
- El permiso de lectura de backends de observabilidad. Es lo que hace que valga la pena alcanzar la tarjeta y lo que lista los destinos; sin él la superficie declara que la configuración no está disponible para ti, en lugar de mostrar una lista vacía.
- El permiso de gestión de backends de observabilidad, para crear, editar, activar, desactivar o eliminar uno. La plataforma lo exige en cada escritura.
- Para el plano por tenant, sus propios permisos de lectura y de gestión, además de un despliegue SaaS. En una instalación operada por el cliente la superficie por tenant es inerte y una concesión o una declaración se rechaza por no estar soportada en ese tipo de despliegue.
- También para el plano por tenant, una habilitación concedida a ese tenant por un operador de plataforma. Es un indicador separado de cualquier destino, un tenant puede estar habilitado con cero destinos, y sin ella no puede declarar ninguno.
Decisiones que tomas aquí
Declarar un backend
Añadir backend es un flujo de dos pasos. Primero eliges una tarjeta de proveedor, y el proveedor queda fijado: editar un backend existente abre directamente el segundo paso y muestra el proveedor como una cabecera de identidad de solo lectura, nunca como un selector. El segundo paso pide un nombre, el endpoint OTLP/HTTP, qué señales exportar, si el backend arranca activo, y la credencial.
El nombre es único en todo el despliegue y no es decorativo: se convierte en el identificador del exportador dentro de la configuración generada del colector. En el plano por tenant el nombre es único dentro de cada tenant, así que dos tenants pueden reutilizar el mismo.
La credencial de exportación
La credencial es de solo escritura. La plataforma la sella y devuelve una máscara en cada lectura, así que la consola nunca tiene una copia y no existe ningún control para revelarla en toda la superficie. Cada proveedor la llama de una forma — una clave de API, un token de acceso o de plataforma de Dynatrace (la plataforma añade su esquema Api-Token o Bearer), una clave de agente o un valor Authorization simple — y el campo se etiqueta en consecuencia.
Al editar un backend el campo de credencial aparece vacío, no con la máscara. Dejarlo vacío significa sin cambios; escribir un valor real la rota. Enviar la propia máscara en una creación se rechaza. Una credencial de despliegue se sella bajo la clave del despliegue; una credencial por tenant se sella bajo la clave de ese tenant, y ninguna se almacena nunca en claro.
El endpoint, y qué rechazará la plataforma
El endpoint debe ser una URL https sin credenciales incrustadas. Ni el endpoint ni la credencial pueden contener $, porque el colector lee ${...} como una referencia a un archivo, una variable o una URL. La credencial no puede contener un carácter de control, y el endpoint usa solo los caracteres ASCII que admite una URL, sin comas y con corchetes solo alrededor de una dirección IPv6; codifica con porcentaje cualquier otro carácter de la ruta y escribe un host internacionalizado en su forma ASCII. Un valor así se rechaza y no se guarda nada.
Aparte de eso la regla depende del despliegue: en un despliegue SaaS se rechaza una dirección privada o interna, y en el resto se permite, porque allí un colector local es el caso normal.
Se distinguen deliberadamente dos rechazos, y cada uno pide de ti una acción distinta. Algo que no es una URL en absoluto es un error de la petición. Una URL bien formada que no es un destino permitido es un rechazo de la semántica, respondido por separado. Observa también lo que no se comprueba: los nombres de host nunca se resuelven durante la validación, así que solo se verifican los rangos de las direcciones IP literales.
Qué no se envía nunca
Debajo de las señales, el formulario declara en solo lectura lo que la exportación siempre elimina: secretos, datos personales, identificadores de tenant y cargas útiles en bruto. Es denegación por omisión y no es editable — no hay ningún control que vuelva a activar nada de ello.
Cuándo llega un cambio al colector
Un backend guardado se confirma primero, y a continuación se vuelve a generar la configuración del colector y se solicita una recarga. El colector comprueba la nueva configuración, se reinicia con ella y vuelve a la anterior si no arranca en buen estado.
La plataforma también vuelve a generarla por sí sola al iniciarse y comprueba cada minuto que el colector siga ejecutando la configuración actual, así que tras un reinicio de la plataforma tus backends vuelven sin necesidad de editarlos. Cuando el despliegue no aporta el montaje compartido y el recargador, la generación se degrada en el sitio: el cambio queda confirmado, la generación se aplaza y el backend aparece como No aplicado. La plantilla del stack activa esa vía por omisión, así que en un entorno desplegado con normalidad sí se ejecuta.
Mientras el colector se reinicia, se pierde la telemetría que todavía retenía para un backend: el colector mantiene una cola breve en memoria y reintenta un envío fallido durante cinco minutos como máximo, y no vuelve a enviar lo que no pudo entregar.
En esta superficie no hay acción de prueba. Nada de aquí envía una sonda al endpoint que escribiste; el primer tráfico real es la propia exportación del colector, y su resultado es lo que muestra el estado.
Qué significa el estado de un backend
Cada backend muestra un estado medido por el propio colector, que se actualiza aproximadamente cada minuto — nunca solo si el backend está habilitado. Cuando no está exportando, la fila indica qué ocurrió y qué hacer.
- Exportando — el colector está entregando la telemetría de este backend.
- Con fallos — el colector no pudo entregar a este backend. O bien el backend rechazó los datos, normalmente porque la clave de API o el endpoint son incorrectos, o bien los datos no pudieron entregarse tras cinco minutos de reintentos, normalmente porque el endpoint no es accesible desde la plataforma, o bien la cola del colector para este backend está llena y la telemetría nueva se descarta, porque el backend no es accesible o recibe más despacio de lo que la plataforma envía.
- No aplicado — el colector todavía no ejecuta la configuración actual de este backend; normalmente se aplica en un minuto. Si el colector rechazó la configuración de exportación más reciente, sigue ejecutando la anterior y los cambios recientes no están en vigor.
- Apagado — el backend está deshabilitado, por lo que no se le envía nada.
- Sin medición — la plataforma no pudo leer el estado del colector; el operador de la plataforma debe revisar el colector y su recargador.
La tarjeta de la página de Observabilidad y Auditoría muestra Activo solo cuando todos los backends están exportando; un backend apagado, o uno en cualquier otro estado, hace que muestre Atencion.
Cómo se relaciona con otras pantallas
Esta superficie vive dentro del grupo Observabilidad y Auditoría, junto a los otros dos subsistemas que administran registros en lugar de valores:
A dónde llega esta exportación se dibuja en el mapa de integraciones, y el estado que la plataforma informa sobre sí misma se lee en el panel de estado, no se configura aquí.