OpenTelemetry Collector: métricas, logs y trazas con dueño
Guía técnica para pymes: cómo recibir métricas, logs y trazas con OpenTelemetry Collector, permisos, costos, backup y prueba de salida verificable.
Un Collector de OpenTelemetry recibe datos antes de que el equipo elija dónde mirarlos. Para una pyme con aplicaciones, servidores y proveedores externos, esa pieza evita que cada sistema mande métricas, logs y trazas a destinos distintos. Esta guía muestra cómo entra el dato, qué componente lo cambia, quién lo consulta y qué prueba demuestra que la empresa puede salir sin perder evidencia.
Dónde aparece el desorden de observabilidad
La documentación oficial define al Collector como una implementación neutral para recibir, procesar y exportar telemetría. Esa frase se vuelve práctica cuando soporte necesita saber si una caída vino de base, red, aplicación o cola de trabajos. El antagonista concreto es el agente duplicado: un servicio manda logs a un lado, métricas a otro y trazas a una cuenta que nadie revisa. OpenTelemetry organiza tres tipos de datos: trazas, métricas y logs. La configuración del Collector separa receivers, processors, exporters, connectors y extensions. Esa división permite ver dónde entra el dato, qué regla lo filtra, a qué destino sale y qué endpoint de salud avisa una falla. El dato global muestra por qué vale ordenar esta capa. En la encuesta Stack Overflow 2025, Docker creció 17 puntos frente a 2024 entre quienes respondieron. Más contenedores traen más eventos cortos; un agente por herramienta termina caro de operar y difícil de auditar. Un tablero sin dueño envejece más rápido que el servidor que dice vigilar.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. 1. Una aplicación, servidor o contenedor envía telemetría por OTLP, Prometheus, syslog u otro receptor disponible. 2. El receiver acepta el dato y lo entrega a un pipeline de métricas, logs o trazas. 3. Un processor agrega atributos, borra campos sensibles, agrupa lotes o limita volumen. 4. El exporter manda cada flujo a Prometheus, Loki, Jaeger, Tempo, una base local o un servicio externo. 5. Los permisos separan administración del Collector, lectura de tableros, cambios de pipeline y acceso a datos sensibles. 6. El backup copia configuración, reglas, dashboards y muestras de eventos; la restauración levanta el Collector en otro host y reproduce una alerta. La lista oficial de receivers muestra la amplitud del problema: hay entradas para nubes, bases, contenedores, sistemas operativos y protocolos. La sección de management ordena operación, escalado, troubleshooting y telemetría interna. La página de releases permite fijar versión y ventana de cambio antes de actualizar.
Qué se instala o configura primero
El primer entregable verificable es un pipeline chico. Recibe métricas de host, logs de una aplicación y una traza de prueba. Exporta métricas a Prometheus, logs a Loki y trazas a Jaeger o Tempo. La configuración queda versionada en Git y cada cambio se prueba en staging antes de tocar producción. Una pila concreta usa OpenTelemetry Collector, Prometheus, Grafana, Loki, almacenamiento para configuraciones, roles de lectura y un job de backup. Tomando el dólar oficial vendedor informado por DolarAPI, una puesta en marcha de USD 440 a USD 920 equivale a ARS $677.600 a ARS $1.416.800. Ese costo cubre instalación, tres pipelines, tableros iniciales y prueba de restauración; no cubre reescritura de aplicaciones para instrumentación profunda. UMSA puede arrancar con un servicio web, una base PostgreSQL y un job nocturno. El primer corte útil muestra latencia, errores, consumo, logs por versión y una traza que siga una solicitud de punta a punta. Si el equipo puede apagar el destino externo y seguir guardando una muestra local, la salida dejó de ser una promesa.
Dónde se rompe y cómo probarlo
El primer riesgo es enviar datos sensibles en logs. La señal aparece cuando un token o DNI entra al destino. La prueba mínima es inyectar una cadena marcada y confirmar que el processor la elimina. El segundo riesgo es perder eventos por exceso de volumen. La señal aparece cuando el Collector muestra colas llenas o descartes. La prueba mínima es correr una carga de diez minutos y medir drops. El tercer riesgo es mezclar ambientes. La señal aparece cuando producción y staging comparten etiqueta o destino. La prueba mínima es filtrar por environment y revisar que cada flujo llegue separado. El cuarto riesgo es actualizar versión sin rollback. La señal aparece cuando un receiver cambia comportamiento y el pipeline deja de cargar. La prueba mínima es levantar la versión nueva con la misma configuración y comparar salida. El quinto riesgo es guardar solo dashboards. La señal aparece cuando Grafana abre, pero faltan pipelines y reglas. La prueba mínima es restaurar Collector, dashboards y datasource en otra máquina. OpenTelemetry Collector sirve cuando soporte puede seguir un incidente con dato, permiso, costo y prueba de salida, no solo con capturas sueltas.
