No pasado, cando falabamos do backend, adoitabamos referirnos a unha aplicación grande cunha única base de datos grande, e o rexistro era suficiente para o seguimento. Agora, grazas a tecnoloxías como   ,   convertéronse no estándar. As aplicacións son máis numerosas e distribuídas, e o rexistro tradicional xa non é suficiente para   e diagnosticar problemas nas nosas aplicacións. Kubernetes os microservizos depurar  Unha excelente solución para organizar a monitorización é OpenTelemetry, un conxunto de ferramentas moderno que se pode usar para depurar e analizar o rendemento de sistemas distribuídos.  Este artigo está destinado a profesionais de TI que buscan ampliar os seus coñecementos en optimización de backend. A continuación, detallaremos que é OpenTelemetry, os seus conceptos clave e os problemas que axuda a resolver. Se estás interesado en como OpenTelemetry pode cambiar o teu enfoque para supervisar e depurar os sistemas backend, mellorando a súa fiabilidade e eficiencia, segue lendo.  Breve historia de OpenTelemetry  As grandes empresas tecnolóxicas enfrontáronse por primeira vez ao reto do rexistro e rastrexo distribuídos a finais da década de 2000. En 2010, Google publicou un artigo,  , que sentou as bases para a ferramenta de rastrexo de Twitter, Zipkin, lanzada en 2012.   Dapper, unha infraestrutura de rastrexo de sistemas distribuídos a gran escala  En 2014, xurdiu Kubernetes, simplificando significativamente o desenvolvemento de microservizos e outros sistemas distribuídos na nube. Isto levou a que moitas empresas atopasen problemas co rexistro distribuído e o rastrexo nos microservizos. Para estandarizar o rastrexo distribuído creouse o estándar OpenTracing, adoptado pola CNCF, e o proxecto OpenCensus de Google.  En 2019, os proxectos OpenTracing e OpenCensus anunciaron unha fusión baixo o nome de OpenTelemetry. Esta plataforma combina as mellores prácticas acumuladas ao longo de moitos anos, o que permite a integración perfecta de rastrexo, rexistro e métricas en calquera sistema, independentemente da súa complexidade.  Hoxe, OpenTelemetry non é só un proxecto; é un estándar da industria para recoller e transmitir datos de telemetría. Está desenvolvido e apoiado por unha comunidade de especialistas e empresas líderes no mercado como Google e Microsoft. O proxecto segue evolucionando, adquirindo novas capacidades para simplificar o proceso de integración e uso.    Que hai dentro?  OpenTelemetry é un conxunto completo de prácticas e ferramentas que definen que sinais pode xerar unha aplicación para interactuar co mundo exterior e como se poden recoller e visualizar estes sinais para supervisar o estado das aplicacións e do sistema no seu conxunto. Os tres tipos principais de sinais son   e   . o rastrexo, o rexistro a recollida de métricas  ** Vexamos cada compoñente máis detidamente: \   Contextos  OpenTelemetry introduce o concepto de contextos de operación. Un contexto inclúe principalmente atributos como   (identificador para a operación actual) e   (identificador para unha sub-solicitude, tendo cada reintento dunha sub-solicitude un único   ). `trace_id` `span_id` `span_id`  Ademais, un contexto pode conter información estática, como o nome do nodo onde se implanta a aplicación ou o nome do ambiente (prod/qa). Estes campos, coñecidos como recursos na terminoloxía de OpenTelemetry, están anexados a cada rexistro, métrica ou trazo para facilitar a busca. Os contextos tamén poden incluír datos dinámicos, como o identificador do punto final actual (   ), que se poden anexar selectivamente a grupos de rexistros, métricas ou trazos. `http_path: "GET /user/:id/info"`  Os contextos de OpenTelemetry pódense pasar entre diferentes aplicacións utilizando protocolos de propagación de contexto. Estes protocolos consisten en conxuntos de cabeceiras que se engaden a cada solicitude HTTP ou gRPC ou ás cabeceiras das mensaxes das filas. Isto permite ás aplicacións posteriores reconstruír o contexto da operación a partir destas cabeceiras.   Aquí tes algúns exemplos de propagación do contexto:    Este é un conxunto de cabeceiras (   ) desenvolvido orixinalmente para o sistema de rastrexo Zipkin. Adaptouse a OpenTracing e utilizouse por moitas ferramentas e bibliotecas. B3-Propagation leva   /   e unha bandeira que indica se é necesario a mostraxe. B3-Propagation x-b3-* trace_id span_id    Desenvolvido polo grupo de traballo do W3C, este estándar unifica varios enfoques de propagación de contexto nun único estándar e é o predeterminado en OpenTelemetry. Un bo exemplo de aplicación destes estándares é o seguimento da execución dunha solicitude pasando por microservizos implementados con diferentes tecnoloxías sen comprometer a precisión da monitorización e depuración. Contexto de rastrexo W3C   Rastreo     O rastrexo é o proceso de gravar e, posteriormente, visualizar a liña de tempo do camiño dunha solicitude a través de varios microservizos.  Na visualización, cada barra denomínase "span" e ten un único   . O intervalo raíz denomínase   e ten un   , que serve como identificador para toda a solicitude. "span_id" "rastro" "trace_id"   Este tipo de visualización permítelle:  Analiza o tempo de execución das solicitudes en diferentes sistemas e bases de datos para identificar os pescozos de botella que precisan optimización.  Detectar dependencias cíclicas entre servizos.  Buscar solicitudes duplicadas. Usando datos de rastrexo, tamén pode crear análises adicionais, como crear un mapa de microservizos ou distribuír o tempo en diferentes sistemas durante o procesamento da operación. Aínda que non uses datos de rastrexo para visualizar liñas de tempo, OpenTelemetry aínda xera   e   para usar noutros sinais. trace_id span_id   Rexistros  A pesar da súa aparente sinxeleza, o rexistro segue a ser unha das ferramentas máis poderosas para diagnosticar problemas. OpenTelemetry mellora o rexistro tradicional engadindo información contextual. En concreto, se hai un trazo activo, os atributos `trace_id` e `span_id` engádense automaticamente aos rexistros, ligándoos á liña de tempo do rastrexo. Ademais, os atributos de rexistro poden incluír información estática do contexto de OpenTelemetry, como o identificador de nodo, así como información dinámica, como o identificador de punto final HTTP actual (`http_path: "GET /user/:id"`).  Usando o `trace_id`, podes atopar rexistros de todos os microservizos asociados á solicitude actual, mentres que o `span_id` permítelle diferenciar entre as solicitudes secundarias. Por exemplo, no caso de reintentos, os rexistros de diferentes intentos terán `span_id`s diferentes. O uso destes identificadores permite unha análise rápida do comportamento de todo o sistema en tempo real, acelerando o diagnóstico de problemas e mellorando a estabilidade e a fiabilidade.   Métricas  A recollida de métricas proporciona datos cuantitativos sobre o rendemento do sistema, como a latencia, as taxas de erro, o uso de recursos e moito máis. O seguimento en tempo real das métricas permítelle responder rapidamente aos cambios de rendemento, evitar fallos e esgotamento de recursos e garantir a alta dispoñibilidade e fiabilidade da aplicación para os usuarios.  A integración con sistemas métricos de almacenamento e visualización como Prometheus e Grafana facilita a visualización destes datos, simplificando significativamente a monitorización.   Colectores métricos  Os colectores de métricas OpenTelemetry son compatibles cos estándares Prometheus e OpenMetrics, o que permite unha transición sinxela ás solucións OpenTelemetry sen cambios significativos. O SDK de OpenTelemetry permite exportar exemplos de trace_id xunto con métricas, o que permite correlacionar métricas con exemplos de rexistro e trazos.  Correlación de sinal   Xuntos, os rexistros, as métricas e o rastrexo crean unha visión completa do estado do sistema:  Os rexistros proporcionan información sobre eventos do sistema, permitindo unha rápida identificación e resolución de erros.  As métricas reflicten indicadores de rendemento cualitativos e cuantitativos do sistema, como os tempos de resposta ou as taxas de erro.  O rastrexo complementa esta vista mostrando o camiño de execución da solicitude a través de varios compoñentes do sistema, axudando a comprender as súas interrelacións. A clara correlación entre rexistros, trazos e métricas é unha característica distintiva de OpenTelemetry. Por exemplo, Grafana permite aos usuarios ver as métricas de traza e solicitude correspondentes ao ver un rexistro, mellorando moito a usabilidade e a eficiencia da plataforma.   Ademais dos tres compoñentes principais, OpenTelemetry inclúe os conceptos de mostraxe, equipaxe e xestión do contexto operativo.   Mostraxe  Nos sistemas de alta carga, o volume de rexistros e trazos faise enorme, o que require recursos substanciais para a infraestrutura e o almacenamento de datos. Para solucionar este problema, os estándares de OpenTelemetry inclúen a mostraxe de sinal: a capacidade de exportar só unha parte dos rastros e rexistros. Por exemplo, pode exportar sinais detallados a partir dunha porcentaxe de solicitudes, solicitudes de longa duración ou solicitudes de erro. Este enfoque permite unha mostraxe suficiente para construír estatísticas e aforrar recursos significativos.  Non obstante, se cada sistema decide de forma independente que solicitudes supervisar en detalle, acabamos cunha vista fragmentada de cada solicitude. Algúns sistemas poden exportar datos detallados mentres que outros poden exportar só parcialmente ou non exportar nada.  Para resolver este problema, os mecanismos de propagación de contexto de OpenTelemetry transmiten unha bandeira de mostraxe xunto co `trace_id`/`span_id`. Isto garante que se o servizo inicial que recibe a solicitude do usuario decide que a solicitude debe ser supervisada en detalle, todos os demais sistemas seguirán o exemplo. En caso contrario, todos os sistemas deberían exportar sinais parcialmente ou non para conservar os recursos. Este enfoque chámase "Mostraxe de cabezas" - unha decisión tomada ao comezo do procesamento da solicitude, ben de forma aleatoria ou baseada nalgúns atributos de entrada.  Ademais, OpenTelemetry admite "Tail Sampling", onde todas as aplicacións sempre exportan todos os sinais en detalle, pero existe un búfer intermedio. Despois de recoller todos os datos, este búfer decide se conservar os datos completos ou conservar só unha mostra parcial. Este método permite unha mostra máis representativa de cada categoría de solicitude (exitosa/longa/erro) pero require unha configuración de infraestrutura adicional.   Equipaxe  O mecanismo Baggage permite que se transmitan pares clave-valor arbitrarios xunto con   /   , pasando automaticamente entre todos os microservizos durante o procesamento da solicitude. Isto é útil para transmitir información adicional necesaria ao longo da ruta de solicitude, como a información do usuario ou a configuración do contorno de execución. trace_id span_id     Exemplo de cabeceira para transmitir equipaxe segundo o estándar W3C: tracestate: rojo=00f067aa0ba902b7,congo=t61rcWkgMzE,userId=1c30032v5   Aquí tes algúns exemplos de uso da equipaxe:    como   ,   ou   pódese pasar a través de todos os microservizos. As aplicacións poden rexistrar automaticamente esta información, o que permite realizar buscas de rexistro por contexto de usuario para a solicitude orixinal. Pasar información de contexto empresarial userId productId deviceId    Configuración para SDK ou infraestrutura. Parámetros de configuración específicos    Bandeiras que axudan aos equilibradores de carga a tomar decisións de encamiñamento. Durante a proba, algunhas solicitudes poden ter que ser encamiñadas a backends simulados. Dado que a equipaxe transmítese automaticamente a través de todos os servizos, non é necesario crear protocolos adicionais; basta con configurar unha regra no equilibrador de carga. Bandeiras de enrutamento  Teña en conta que, aínda que o impacto no rendemento da Equipaxe é mínimo, un uso excesivo pode aumentar significativamente a carga de rede e servizo. Escolle con coidado os datos que realmente necesitas pasar a través de Baggage para evitar problemas de rendemento.   Implantación de Infraestruturas  A implementación de OpenTelemetry a nivel de infraestrutura implica a integración dos backends de OpenTelemetry na arquitectura da aplicación e a configuración da infraestrutura para a agregación de datos.   O proceso consta de catro etapas:    Na primeira fase, os SDK de OpenTelemetry intégranse directamente nas aplicacións para recoller métricas, rexistros e rastrexos, garantindo un fluxo continuo de datos sobre o rendemento de cada compoñente do sistema. Integración de aplicacións    Os datos recollidos envíanse desde as aplicacións a través dos exportadores a sistemas externos para o seu procesamento posterior, como sistemas de rexistro, seguimento, rastrexo ou análise, dependendo das súas necesidades. Configuración de exportadores    Esta etapa pode implicar normalizar os datos, enriquecelos con información adicional e fusionar datos de diferentes fontes para crear unha visión unificada do estado do sistema. Agregación e almacenamento    Finalmente, os datos procesados preséntanse como paneis en sistemas como Grafana (para métricas e trazos) ou Kibana (para rexistros). Isto permite aos equipos avaliar rapidamente a saúde do sistema, identificar problemas e tendencias e configurar alertas en función dos sinais xerados. Visualización de datos  Implementación da aplicación  Para integrarse cunha aplicación, cómpre conectar o SDK de OpenTelemetry adecuado para a linguaxe de programación en uso ou empregar bibliotecas e marcos que admitan directamente OpenTelemetry. OpenTelemetry adoita implementar interfaces moi utilizadas de bibliotecas coñecidas, permitindo substitucións directas. Por exemplo, a biblioteca Micrometer úsase habitualmente para a recollida de métricas no ecosistema Java. O SDK de OpenTelemetry ofrece as súas implementacións de interfaces Micrometer, permitindo a exportación métrica sen cambiar o código da aplicación principal. Ademais, OpenTelemetry ofrece implementacións de interfaces OpenTracing e OpenCensus máis antigas, facilitando unha migración sen problemas a OpenTelemetry.  Conclusión  Nos sistemas de TI, OpenTelemetry pode converterse na clave para o futuro de backends fiables e eficientes. Esta ferramenta simplifica a depuración e o seguimento e tamén abre oportunidades para unha comprensión profunda do rendemento e optimización das aplicacións nun novo nivel. Únete á comunidade de OpenTelemetry para axudar a moldear un futuro onde o desenvolvemento do backend sexa máis sinxelo e efectivo.

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

Even

Google

Microsoft

Real

reflect

Trace

Read My Stories

Este audio está producido na lingua orixinal da historia!

Que é OpenTelemetry e como pode mellorar a calidade do teu backend?

About Author

COMENTARIOS

Etiquetas colgantes

ESTE ARTIGO FOI PRESENTADO EN

Related Stories

HackerNoon Decoded 2024: Celebrating Our HackerNoon Community!

HackerNoon Decoded 2024: Celebrating Our Programming Community!

R Systems Blogbook—Chapter 1 is Now Open for Submissions🎉

HackerNoon Decoded 2024: Celebrating Our Writing Community!

HackerNoon Decoded 2024: Celebrating Our HackerNoon Community!

HackerNoon Decoded 2024: Celebrating Our Programming Community!

R Systems Blogbook—Chapter 1 is Now Open for Submissions🎉

HackerNoon Decoded 2024: Celebrating Our Writing Community!

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps