# ¿Cómo Debería Prometheus Manejar los Atributos de Recurso de OpenTelemetry? - Un Informe de Investigación UX LLMS index: [llms.txt](/llms.txt) --- El 29 de mayo de 2025, finalicé mi mentoría con Prometheus a través del [Linux Foundation Mentorship Program](https://mentorship.lfx.linuxfoundation.org/project/36e3f336-ce78-4074-b833-012015eb59be). Mi proyecto se enfocó en entender cómo Prometheus maneja los atributos de recurso de OpenTelemetry y cómo esa experiencia podría mejorarse para los usuarios. Mi trabajo consistió en realizar una investigación de usuarios para obtener la perspectiva del usuario sobre este desafío. En tres meses, realicé entrevistas a usuarios y stakeholders, ejecuté una encuesta y analicé los hallazgos. En este artículo, compartiré cómo realicé la investigación, qué descubrí y hacia dónde podrían dirigirse las comunidades involucradas a partir de aquí. ## Contexto del proyecto OpenTelemetry (OTel) tiene algo llamado [atributo de recurso](/docs/concepts/resources/), que es información adicional sobre la fuente de una métrica, como el servicio, el host o el entorno que la generó. Prometheus, una base de datos de series temporales, usa etiquetas para identificar y consultar métricas. Si los atributos de recurso se convierten a etiquetas, pueden causar lo que se conoce como "explosión de cardinalidad", esencialmente creando demasiadas combinaciones únicas que abruman el sistema. Esto suele suceder si los atributos cambian con frecuencia o incluyen muchos valores únicos, como IDs de usuario o nombres de pods. Actualmente, existen tres enfoques principales para manejar este desafío: - **Mapear todos los atributos de recurso a etiquetas:** Esto crea problemas de explosión de cardinalidad, especialmente para aplicaciones con grandes cantidades de atributos o valores de atributos que cambian frecuentemente. - **Promoción selectiva:** Los usuarios eligen manualmente qué atributos de recurso son suficientemente importantes como para convertirse en etiquetas en Prometheus. - **Patrón target info:** Colocar todos los atributos de recurso en una métrica separada llamada `target_info`. Cuando los usuarios necesitan consultar métricas que involucran atributos de recurso específicos, tienen que realizar un "join" entre el target info y sus métricas reales. Estas no son malas soluciones técnicamente, pero no ofrecen la mejor experiencia de usuario. Por eso, realicé esta investigación para entender qué podrían estar pasando por alto los mantenedores de Prometheus sobre la experiencia del usuario. Los objetivos de la investigación fueron: - Entender cómo los ingenieros utilizan actualmente los atributos de recurso de OpenTelemetry con Prometheus - Identificar puntos de dolor en la integración actual - Descubrir las expectativas de los usuarios sobre cómo deberían representarse los atributos de recurso ## Enfoque de investigación Mi enfoque de investigación fue una combinación de investigación cualitativa y cuantitativa. Comencé con entrevistas a stakeholders para entender el contexto histórico y evaluar qué tan abiertos estaban los stakeholders a cambios que podrían resultar de mi investigación. Los stakeholders con los que hablé representaban una variedad de roles, desde fundadores y cofundadores de proyectos, hasta mantenedores de larga data con contexto histórico, y otros más directamente involucrados en los desafíos actuales alrededor del manejo de atributos de recurso. A continuación, realicé entrevistas a usuarios para escuchar directamente de personas que realmente usan estas herramientas. Finalmente, hice seguimiento con una encuesta para llegar a una audiencia más amplia y validar lo que escuché en las entrevistas. ## Perspectivas de las entrevistas a stakeholders > [!NOTE] Las citas han sido traducidas del inglés original. Hablé con 6 stakeholders—3 de cada proyecto: **Stakeholders de Prometheus:** - [Julius Volz](https://github.com/juliusv) – Cofundador de Prometheus - [Beorn Rabestein](https://github.com/beorn7) – Mantenedor de larga data de Prometheus - [Richard Hartmann](https://github.com/RichiH) – Cofundador de OpenMetrics y mantenedor de Prometheus **Stakeholders de OpenTelemetry:** - [Juraci Paixão Kröhling](https://github.com/jpkrohling) – Miembro del Comité de Gobernanza de OpenTelemetry - [Josh Suereth](https://github.com/jsuereth) – Miembro del Comité Técnico de OpenTelemetry - [Austin Parker](https://github.com/austinlparker) – Cofundador de OpenTelemetry y miembro del Comité de Gobernanza Mis conversaciones con stakeholders sacaron a la luz varios descubrimientos interesantes: - La comunicación entre las comunidades de Prometheus y OpenTelemetry no siempre había sido la mejor y eso les impidió colaborar desde el principio. - Gran parte de los problemas de interoperabilidad que existen ahora provienen de las diferentes bases filosóficas y técnicas sobre las que se construyó cada uno de los proyectos. > _(Traducción)_ "Si pensamos en situaciones exploratorias o casos de uso, > entonces podemos justificar muchas de las decisiones de diseño detrás de > OpenTelemetry. Y si pensamos en métricas y escalado, monitoreo, para > infraestructura enorme, entonces las decisiones de diseño para Prometheus > también están justificadas. Así que ambos tienen muy buenos argumentos." — > _Juraci Paixão Kröhling_ > _(Traducción)_ "Creo que uno de los mayores [problemas de interoperabilidad] > es la diferencia entre push y pull." — _Julius Volz_ Julius luego elaboró que su preocupación va más allá del mecanismo de entrega en sí. En sus palabras: > _(Traducción)_ "Una de las mayores desventajas de usar OTLP para enviar > métricas a Prometheus es que terminas desechando una de las características > principales de Prometheus como sistema de monitoreo: su modelo de > recolección de métricas basado en pull que se basa en información de > descubrimiento de servicios dinámica (por lo que Prometheus siempre sabe qué > targets deberían existir actualmente), y el resultante monitoreo automático > de salud de targets a través de la métrica sintética 'up' que se genera para > cada scrape de target." - Hay un reconocimiento compartido de la importancia de poner las necesidades del usuario primero, incluso mientras se mantienen algunos aspectos no negociables (por ejemplo, que Prometheus mantenga su modelo pull y no aliene a los usuarios existentes). Una conclusión clave de las entrevistas para mí fue darme cuenta de que los problemas actuales de interoperabilidad no son fallos, sino el resultado natural de diferentes comunidades resolviendo diferentes problemas en diferentes momentos. Y es bueno ver que ambos proyectos están trabajando juntos ahora para mejorar la experiencia del usuario. ## Perspectivas de las entrevistas a usuarios Las entrevistas a usuarios fueron tan reveladoras como las conversaciones con stakeholders. Mi objetivo era hablar con alrededor de 10 usuarios (ciertamente ambicioso) pero logré entrevistar a 7, y todos compartieron perspectivas increíblemente útiles. El punto de dolor más prominente que los usuarios compartieron fue la complejidad de realizar joins con la integración actual. Otro problema mencionado fue la discrepancia en los nombres de métricas causada por las limitaciones del conjunto de caracteres, pero entiendo que eso ya se ha abordado, ya que las versiones recientes de Prometheus ahora soportan caracteres UTF-8 (aunque esto introduce la necesidad de la sintaxis de selector entre comillas más engorrosa en PromQL). Respecto a los modelos mentales, muchos usuarios (tanto entrevistados como encuestados) no distinguen entre atributos de recurso y etiquetas de Prometheus. Tienden a pensar en ellos como lo mismo. > _(Traducción)_ "Esperaría que los atributos de recurso por regla se trataran > exactamente de la misma manera que los atributos adjuntos al tracer, a la > métrica... No trazaría una frontera entre ellos." — _Participante de > Entrevista 1_ También aprendí sobre las diversas soluciones alternativas que las personas usan para manejar problemas de atributos de recurso en sus casos de uso específicos. Algunos promueven atributos de recurso seleccionados a etiquetas, otros manejan la conversión a nivel del OpenTelemetry-Collector para evitar lidiar con ello en Prometheus, y algunos convierten todos los atributos, aunque generalmente solo cuando el número de atributos es pequeño. ## Perspectivas de la encuesta La encuesta me ayudó a cuantificar lo que estaba escuchando en las entrevistas y llegar a una audiencia más amplia. Al momento de escribir esto, hemos tenido 134 respuestas, con 61 de nuestro grupo objetivo—personas que usan OTel y Prometheus juntos. Aquí están los hallazgos clave: - Los usuarios no conceptualizan los atributos de recurso como diferentes de las etiquetas regulares, sin embargo, la implementación actual los trata como metadatos separados. - La sintaxis compleja de join es una gran barrera para la adopción, lo que hace que al desarrollador común le cueste escribir consultas básicas que accedan a atributos de recurso. - La promoción manual de atributos crea una sobrecarga operacional que escala mal con el tamaño del equipo y la complejidad. - El 78% de los encuestados encuentran las brechas de documentación un desafío en su uso de atributos de recurso. ![Un gráfico de barras mostrando desafíos con los atributos de recurso de OpenTelemetry en Prometheus](Chart.PNG) Los patrones de la encuesta fueron consistentes con lo que surgió de mi investigación cualitativa. Para resultados detallados, consulta las [respuestas anonimizadas de la encuesta](https://github.com/prometheus-community/ux-research/blob/acc0194a79aa0f2ee1c6eb93462c9488d236a275/prom-otel-research/survey-results.csv?from_branch=main) ## Lo que no esperaba aprender (pero aprendí) Comencé esta investigación para entender los puntos de dolor de los usuarios con el manejo de atributos de recurso, pero descubrí algunos hallazgos inesperados e importantes. Uno de los más sorprendentes fue darme cuenta de que [la característica de Detección de Recursos de OpenTelemetry](/docs/specs/otel/resource/#telescoping) permite a los usuarios retener o descartar selectivamente atributos de recurso según su relevancia usando un patrón conceptual a veces denominado "telescoping". A pesar de su potencial, muchos usuarios e incluso algunos miembros de la comunidad de Prometheus parecen no estar al tanto de ello. Esta falta de conciencia puede haber contribuido a la adopción del patrón "join", que desde entonces ha demostrado ser problemático. Esto destaca un problema más amplio: las brechas de documentación y educación son una barrera importante. En nuestra encuesta, el 78% de los encuestados citó las brechas de documentación como un desafío. Otra realización clave es que las decisiones de integración anteriores, como la dependencia de joins, se tomaron sin una comprensión completa de las capacidades de cada herramienta, una consecuencia inevitable de la falta de colaboración y comunicación temprana entre las comunidades de Prometheus y OpenTelemetry. ## Soluciones recomendadas Basándome en conversaciones con stakeholders y usuarios finales, aquí están algunas de las soluciones propuestas, agrupadas por lo que es factible a corto plazo vs. lo que es parte de una visión a largo plazo: ### Soluciones a corto plazo - **Documentación mejorada para el manejo de atributos** Dado que los usuarios encuentran más fácil promover atributos que hacer join en target info, puede valer la pena desenfatizar (o incluso discontinuar) la documentación sobre joins, mientras se hace la [documentación de promoción de atributos](https://prometheus.io/docs/guides/opentelemetry/#promoting-resource-attributes) más prominente para aquellos que aún no están al tanto de la opción. El patrón telescoping de detección de recursos en OpenTelemetry también merece más visibilidad y documentación adecuada. Además, los usuarios han sugerido crear documentación consolidada Prometheus–OpenTelemetry que explique claramente cómo ambos sistemas manejan los atributos de recurso. ### Visión a largo plazo - **Marco de entidades** El concepto en desarrollo de entidades de OpenTelemetry podría ayudar a Prometheus a distinguir entre atributos identificadores vs. descriptivos. Esto guiaría qué atributos se convierten en etiquetas y cuáles se almacenan o filtran. - **Almacenamiento de metadatos** Los stakeholders también discutieron la idea de agregar soporte de metadatos de primera clase a Prometheus mismo. Esto permitiría que ciertos atributos de recurso se almacenen como metadatos (no etiquetas), evitando costos de cardinalidad mientras se mantiene la información disponible para consultas o joins. - **Expandir para telemetría exploratoria** Esto podría ser ambicioso, pero Prometheus podría considerar expandir su alcance para soportar mejor casos de uso de telemetría exploratoria. Los stakeholders mostraron apertura al cambio, siempre que la arquitectura central de Prometheus permanezca intacta y los usuarios existentes no sean alienados. Eso sugiere que puede haber espacio para la evolución, especialmente si las nuevas capacidades pueden complementar, en lugar de reemplazar, el comportamiento actual. > _(Traducción)_ Veo a OTel y Prometheus como provenientes de supuestos muy > diferentes sobre cómo debería funcionar la telemetría en general. Entonces, > mientras que Prometheus es muy opinado sobre el almacenamiento de series > temporales...OTel, por otro lado, proviene de un contexto de tracing, lo que > significa que es más explorativo que Prometheus. Así que [con] Prometheus, > más o menos sé de antemano lo que necesito. [Con] OpenTelemetry, no sé lo > que podría necesitar, así que almaceno todo. — _Juraci Paixão Kröhling_ - **Correlación entre señales** Los usuarios mencionan usar plataformas que pueden ingerir todos los tipos de telemetría y correlacionar métricas, trazas y logs dentro de un único sistema. Aunque Prometheus probablemente permanecerá enfocado solo en métricas, podría habilitar herramientas que correlacionen métricas con telemetría almacenada en otras bases de datos. Prometheus actualmente soporta [exemplars](https://prometheus.io/docs/specs/om/open_metrics_spec/#exemplars), que permiten vincular métricas con trazas, pero eso es aproximadamente el alcance de su ámbito. Dependen de que el tracing esté presente, lo que los hace menos útiles en entornos donde las trazas no están disponibles o instrumentadas. > _(Traducción)_ "Una de las cosas clave innovadoras en OpenCensus era... que > podías dividir el uso de CPU por qué solicitudes estaban usando CPU y > obtener una métrica que dijera, 'aquí está el uso de CPU por solicitud.' Eso > es algo que podías lograr en OpenCensus porque todo estaba basado en > contexto." — _Josh Suereth_ Todavía hay trabajo por hacer. Las comunidades necesitarán tiempo para desarrollar y probar soluciones. Pero estoy orgullosa de que esta investigación haya proporcionado una base centrada en el usuario para ese trabajo. Si estás interesado en las discusiones, propuestas y retroalimentación en curso alrededor de estas ideas, puedes consultar el repositorio de GitHub donde todo está siendo documentado: [OpenTelemetry Resource Attributes in Prometheus UX Research](https://github.com/prometheus-community/ux-research/tree/a2f8c6684321fd04de7b94cfbd39a48bb1d7beb4/prom-otel-research?from_branch=main) ## Agradecimientos {#acknowledgments} Esta publicación estaría incompleta sin reconocer a mis increíbles mentores: [Amy Super](https://github.com/amy-super), [Andrej Kiripolsky](https://github.com/AndrejKiri), y [Arthur Silva Sens](https://github.com/ArthurSens) – gracias por confiar en mí con este desafiante proyecto y preocuparse tan profundamente por mi trayectoria profesional. Ustedes son las verdaderas superestrellas. A todos los stakeholders y usuarios que dieron su tiempo: gracias por comprometerse con este trabajo y confiar en mí con su retroalimentación honesta. Sus perspectivas hicieron que esta investigación fuera significativa. ## Qué sigue para mí Me entusiasma seguir trabajando en la intersección de UX y sistemas cloud native. Si conoces oportunidades similares a esta mentoría, ¡me encantaría saber de ti! Soy una trabajadora dedicada—solo pregúntales a mis mentores.