Los equipos que migran cargas de trabajo a bare metal por rendimiento, coste o soberanía de datos suelen arrastrar consigo sus contratos de observabilidad SaaS. El resultado es un servidor de tenant único y alto rendimiento enviando gigabytes de telemetría a un proveedor que factura por volumen de ingesta, con tarifas por usuario encima. La economía deja de tener sentido rápidamente, y ninguno de esos datos necesitaba salir de tus propios racks.
Un stack de observabilidad bare metal autoalojado y listo para producción no es un compromiso. El ecosistema de Prometheus, Loki, Tempo y OpenTelemetry ha madurado hasta el punto en que las herramientas cubren métricas, logs y trazas con la misma profundidad que los servicios gestionados, a una fracción del coste operativo. La inversión en ingeniería es real, pero se concentra al inicio, no se repite mes a mes.
Este artículo recorre las decisiones de arquitectura que realmente importan: cómo dimensionar y estructurar cada capa, dónde están los puntos conflictivos y cómo conectar las tres señales para que sean útiles en lugar de simplemente estar presentes.
Empezando por la capa de recolección: OpenTelemetry como tubería común
Antes de elegir backends, define la estrategia de recolección. OpenTelemetry es la base adecuada para un stack de observabilidad bare metal porque es neutral respecto al proveedor: instrumentas una vez y cambias de backend sin tocar el código de la aplicación. El OTel Collector se ejecuta como agente ligero en cada host, recibe la telemetría de tus servicios y la reenvía al backend de almacenamiento que hayas elegido.
Conviene entender la madurez de cada señal antes de comprometerte. La especificación de trazas es completamente estable y cuenta con soporte a largo plazo. Las señales de métricas y logging han alcanzado el estado estable en la especificación, pero el propio OTel Collector tiene una estabilidad desigual entre sus componentes, así que fija la versión del Collector y prueba las actualizaciones en staging. Un aspecto importante: el propagador de Jaeger ha quedado obsoleto en la especificación de OTel, por lo que si estás migrando desde una configuración basada en Jaeger, planifica explícitamente el cambio de formato de propagación en lugar de asumir compatibilidad.
El esquema de configuración de OTel sigue sin ser estable después de varios años de trabajo, lo que significa que la gestión de configuración programática (valores de Helm, plantillas de Ansible y similares) es más fiable en este momento que depender del esquema para la validación. Diseña tus pipelines del Collector como código desde el primer día.
Métricas: dimensionando Prometheus para la realidad del bare metal
Prometheus es el estándar de facto para métricas en entornos cloud-native, pero su perfil de recursos en bare metal difiere de lo que los equipos experimentan en Kubernetes gestionado. Consume mucha CPU y memoria, especialmente con conjuntos de etiquetas de alta cardinalidad. Para entornos grandes, varios núcleos y al menos 32 GB de RAM son la línea base práctica. Usa NVMe o SSDs de alto IOPS: el TSDB de Prometheus ejecuta operaciones de compactación y consulta que se bloquearán en discos mecánicos.
La retención por defecto es de 15 días, configurable con –storage.tsdb.retention.time. También puedes limitar el uso de disco con –storage.tsdb.retention.size, pero ten en cuenta que Prometheus elimina bloques enteros en lugar de muestras individuales, por lo que el consumo real de almacenamiento puede superar ligeramente el límite configurado según los límites de bloque. Planifica la asignación de disco con margen.
Configurar remote write no reduce el coste local. Las muestras siguen pasando por la ruta de ingesta local, el WAL y el bloque head antes de ser reenviadas. Si añades remote write para almacenamiento a largo plazo, presupuesta el footprint completo de recursos locales independientemente.
Para retención a largo plazo en bare metal, el camino actualmente mantenido es Grafana Mimir (el sucesor de Cortex, que también se mencionaba junto a Thanos como backend de almacenamiento a largo plazo). Thanos sigue siendo una alternativa sólida, especialmente si prefieres un modelo sidecar que mantenga cada instancia de Prometheus independiente. Mimir se adapta mejor a equipos que quieren una única ruta de escritura escalable horizontalmente. Elige según tu modelo operativo, no según qué proyecto tenga más ruido en la comunidad en un momento dado.
A escala, distribuye las responsabilidades de scraping entre varias instancias de Prometheus en lugar de ejecutar un único monolito. La federación funciona pero añade latencia; instancias separadas con targets diferenciados es más limpio para la mayoría de los clusters bare metal.
Logs: Loki frente a Elasticsearch en la economía del bare metal
Elasticsearch es potente, pero su superficie operativa en bare metal es considerable: disciplina de shards, gestión de mappings, políticas de ciclo de vida de índices y ajuste del heap requieren atención continua. Para volúmenes de logs equivalentes, Elasticsearch suele costar entre cinco y diez veces más que Loki a escala, y la sobrecarga operativa amplifica esa diferencia.
La filosofía de diseño de Loki encaja bien con las restricciones del bare metal. Indexa solo etiquetas, no el contenido de los logs, y almacena chunks comprimidos en object storage. En bare metal, ese object storage puede ser MinIO ejecutándose en tus propios discos, manteniendo todo el pipeline de logs dentro de tu infraestructura. El stack multi-componente de Loki (distributor, ingester, querier, query-frontend, compactor y ruler) parece complejo sobre el papel, pero cada componente es stateless o tiene límites de estado bien definidos, lo que facilita su operación con herramientas estándar de gestión de configuración.
Una nota práctica: Loki no gestiona eficientemente las etiquetas de alta cardinalidad. Mantén tus conjuntos de etiquetas disciplinados. Usa logging estructurado en tus aplicaciones y lleva la cardinalidad al contenido de los logs en lugar de a las etiquetas. Los equipos que migran desde Elasticsearch e intentan replicar su comportamiento de indexación full-text mediante etiquetas de Loki se encontrarán rápidamente con problemas de rendimiento.
Trazas: Grafana Tempo y el modelo de object storage
Grafana Tempo es el complemento natural de Loki y Prometheus en un stack autoalojado. Solo requiere object storage para operar, ingesta formatos OpenTelemetry, Jaeger y Zipkin, y se integra de forma nativa con Grafana para la visualización. En bare metal, MinIO también gestiona el backend de almacenamiento aquí, manteniendo bajo el número de dependencias.
La restricción arquitectónica importante de Tempo es que almacena trazas sin indexación. Encontrar una traza concreta requiere un trace ID, que obtienes desde los exemplars de Prometheus o desde una línea de log correlacionada en Loki. Esto no es una limitación que sortear; es el diseño. Conecta las tres señales desde el principio: emite trace IDs en logs estructurados, adjunta exemplars a las métricas de Prometheus, y la ausencia de un índice de trazas se vuelve invisible en el uso cotidiano. Thoughtworks situó Tempo en el anillo Trial en abril de 2025, destacando su formato de bloque Parquet y el lenguaje de consulta TraceQL como las características que lo hacen apto para producción en despliegues serios.
Conectando el stack: Grafana como panel único
Grafana conecta los tres backends y es donde el stack de observabilidad demuestra su valor. Correlacionar un pico de latencia en una métrica de Prometheus con un aumento de errores en los logs de Loki y saltar después a la traza problemática en Tempo es el flujo de trabajo que reemplaza los costosos dashboards de servicios gestionados. Esto funciona de inmediato cuando configuras los data sources de Grafana para los tres backends e instrumentas tus servicios para emitir trace IDs consistentes entre señales.
Para alertas, el archivado del proyecto open source Grafana OnCall a principios de 2025 significa que el enrutamiento de guardias gratuito y autoalojado por esa vía ya no es viable. Las opciones prácticas actuales son Alertmanager (que se distribuye con Prometheus y gestiona bien el enrutamiento, la agrupación y el silenciado) o la integración con una plataforma externa de gestión de guardias. Planifica esto antes de llegar a producción, no después de tu primer incidente a las 3 de la madrugada.
Si quieres reducir aún más la superficie operativa, SigNoz merece evaluarse: reemplaza todo el stack de Loki, Grafana, Tempo y Mimir con un único binario open source. La contrapartida es menos flexibilidad y un ecosistema más pequeño, pero para equipos que quieren observabilidad funcionando rápidamente sin gestionar cinco ciclos de actualización de componentes separados, es una alternativa legítima.
Ejecutando esto en bare metal en DIVERSITY
En nuestra plataforma Bare Metal, aprovisionamos servidores con los perfiles de almacenamiento NVMe y las configuraciones de memoria que el TSDB de Prometheus realmente necesita, y soportamos despliegues de MinIO como capa de object storage tanto para Loki como para Tempo, manteniendo todo el pipeline de telemetría dentro de un entorno de tenant único. El problema del vecino ruidoso que afecta a los backends de observabilidad en nube compartida sencillamente no existe en hardware dedicado: la compactación de tu TSDB no compite con la carga de consultas de otro tenant.
La configuración autoalojada de métricas, logs y trazas descrita aquí no es un atajo para reducir costes. Es lo que debería ser la observabilidad en producción sobre bare metal: visibilidad total, sin factura por GB de ingesta, y telemetría que permanece exactamente donde se ejecutan tus cargas de trabajo.
