OpenTelemetry को चलाने में सफलता मिली, लेकिन यह इतना जटिल क्यों था?

• OpenTelemetry (OTel) एक observability framework और tools का संग्रह है
• मौजूदा tools में Prometheus (metrics), Logstash (logs), OpenTracing (distributed tracing) शामिल हैं
• OTel metrics, logs और tracing इन तीन signals को standardize करता है, और OpenTelemetry Protocol (OTLP), OpenTelemetry Collector, तथा विभिन्न भाषाओं के SDK प्रदान करता है
  • यह open source, vendor-independent, language-independent, distributed, zero-code जैसे सभी buzzwords पर खरा उतरता है

OTel की समस्याएँ

• logs और metrics मौजूदा tools जैसे होने के कारण आसानी से integrate हो जाते हैं। सिर्फ configuration जोड़कर भी OTel में migration संभव है
• tracing को implement करना कठिन है
  • Context Propagation: distributed systems के बीच request information पहुँचाने के लिए आवश्यक
    • request unit को Trace और Span में बाँटा जाता है
    • उदाहरण: "खरीदें" बटन क्लिक → Frontend → Backend → Payment/Shipping services के बीच संबंध को Span के रूप में व्यक्त किया जाता है
  • OTel का support करने का तरीका:
    • यह कई Context Propagation standards देता है (जैसे b3, W3C Trace Context)
  • OTel को कई standards को support करना पड़ता है
    • मौजूदा OpenTracing से OTel में migration के दौरान अप्रत्याशित conflicts होते हैं
    • Lightbend Telemetry OpenTelemetry logs और metrics को support करता है, लेकिन tracing को support नहीं करता

API के बीच conflict की समस्या

Spring और Akka integration की समस्या

• Spring: application bootstrapping और configuration management
• Akka: event sourcing, scheduling, clustering आदि में उपयोग
• समस्या:
  • OTel इस्तेमाल करने पर Spring और Akka के tracing API आपस में interact नहीं करते
  • वे एक ही Trace ID share नहीं कर पाते → गलत tracing results

समाधान: OpenTracing Shim

• OTel Tracer को OpenTracing Tracer में बदलने वाला tool
• समस्या:
  • Akka की Lightbend Telemetry, OpenTracing implementation से मेल नहीं खाती
  • Jaeger और OTel अलग-अलग SpanContext की अपेक्षा करते हैं, जिससे conflict होता है

समाधान की प्रक्रिया

OTel और OpenTracing का manual integration

• OTel Context को manually Jaeger SpanContext में convert करना:
  • OTel context को Java Map में inject करना
  • उस map को Jaeger SpanContext में extract करके manually set करना
• code उदाहरण:

  var otelContext = new HashMap<>();  
  GlobalOpenTelemetry.get().getPropagators().getTextMapPropagator()  
      .inject(Context.current(), otelContext, (carrier, key, value) -> carrier.put(key, value));  
  var openTracingContext = new TextMapCodec(false).extract(new TextMapAdapter(otelContext));  
  GlobalExtendedTracer.get().local().activateContext(openTracingContext);  
  

• परिणाम:
  • Spring और Akka के बीच tracing data का integration सफल रहा
  • HTTP boundaries के बीच Trace सही तरीके से connect हो गया

निष्कर्ष

जटिलता के कारण

• दो अलग-अलग tracing libraries को integrate करने की कोशिश
• OpenTelemetry द्वारा दिए गए standards उपयोगी हैं, लेकिन मौजूदा tools के साथ conflicts की संभावना रहती है

OpenTelemetry का मूल्य

• OpenTelemetry observability के standardization में महत्वपूर्ण भूमिका निभाता है
• यह जटिल है, लेकिन एक शक्तिशाली open source project है

आगे की चुनौतियाँ

• यह पुष्टि करना ज़रूरी है कि Akka का Trace Context threads के बीच सही तरीके से propagate हो रहा है या नहीं
• project को बेहतर बनाने के लिए अतिरिक्त testing और feedback आवश्यक हैं

[GN⁺]

Hacker News राय

• Otel को सीखते और पोर्ट करते समय ऐसा लगा जैसे Java की दुनिया में वापस आ गया हूँ। कोड में रास्ता ढूँढना EnterpriseFizzBuzz जैसा लगा और कुछ भी आसानी से खोजा नहीं जा सकता था। NodeJS में StatsD की तुलना में लगभग 4 गुना CPU उपयोग था, जिसे अपने aggregation से कम किया गया। OTEL उन भाषाओं के प्रति प्रतिकूल है जो प्रति core एक process का उपयोग करती हैं। Prometheus का उपयोग करना बेहतर है.

• अलग-अलग observability vendors द्वारा दिए गए SDK, agent और API की वजह से Otel जटिल लग सकता है। OpenTelemetry अब standard बन गया है, और Grafana द्वारा OpenTelemetry अपनाने की सराहना करता हूँ। Datadog की pricing mid-sized companies और enterprises के बीच बेकाबू हो गई है। documentation बेहतर हो सकती है, और onboarding docs programming language के हिसाब से अलग हैं। NodeJS/Typescript stack में OpenTelemetry जल्दी शुरू करने के लिए एक package और example Grafana stack बनाया गया है.

• लोकल development में logs, traces और metrics का support चाहिए था, लेकिन कई Docker images चलाना नहीं चाहता था। .NET टीम ने .NET Aspire जारी किया, जिससे local development stack में सब कुछ आसानी से visualize किया जा सकता है। k8s पर deploy करते समय OTEL endpoint को DataDog agent से जोड़ दें तो सब कुछ काम करता है। DataDog की custom tracing libraries और SDK से बचकर OTEL का उपयोग किया.

• OpenTelemetry जरूरत के हिसाब से जटिल हो सकता है। हमारी टीम इसे सरल तरीके से इस्तेमाल करती है और manual instrumentation के जरिए ध्यान से चुनती है कि क्या observe करना है। हम दो backend इस्तेमाल करते हैं, एक सस्ता third-party service, और दूसरा local development के लिए Jaeger installation.

• Python में Otel इस्तेमाल करते समय Logfire का client उपयोग करना बेहतर है। Pydantic टीम द्वारा बनाया गया यह client आधिकारिक Otel library की तुलना में कहीं बेहतर और सरल है.

• कई web frameworks ज़्यादातर instrumentation अपने-आप संभाल लेते हैं। opentelemetry-js का उपयोग करके और Signoz जैसी किसी चीज़ को self-host करने पर एक घंटे के भीतर काफी data मिल सकता है.

• OpenTelemetry को अपनाना आसान बनाने के लिए एक open source project शुरू किया गया है, जिसे एक ही command से चलाया जा सकता है.

• Python में standard stack का उपयोग करें तो केवल कुछ imports के साथ सब कुछ अपने-आप trace किया जा सकता है। Otel जटिल है क्योंकि इसे उन कंपनियों के लिए डिज़ाइन किया गया है जो Otel-compatible software बेचती हैं.

• OpenTelemetry की शुरुआत tracing से हुई थी, लेकिन metrics और logs को specialized solutions पर छोड़ना बेहतर है। सब कुछ एक ही umbrella के नीचे लाने की कोशिश "leaky abstraction" समस्या जैसी लगती है। SQL databases भी एक साथ सब कुछ कर सकते हैं, लेकिन इसका मतलब यह नहीं कि ऐसा करना चाहिए.