2023 में OpenTelemetry

 (bit.kevinslin.com)
2 पॉइंट द्वारा GN⁺ 2023-08-29 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 2019 में OpenTracing और OpenCensus के विलय से शुरू हुआ OpenTelemetry, 4 साल में trace·metrics·logs को समेटने वाला observability standard बन गया
  • इसकी मुख्य संरचना specification और implementation में बंटी है, जो vendor compatibility के लिए मानक और वास्तविक instrumentation·collection tools दोनों प्रदान करती है
  • OTEL specification में 2020 में tracing, 2021 में metrics, और 2023 में logs stable हुए, जिससे सभी signals stable स्थिति में पहुंच गए, हालांकि logs support अभी भी SDK के अनुसार अलग-अलग है
  • OTLP और Collector observability data को common format में भेजने और process करने की बुनियाद हैं, और Grafana·Datadog जैसे vendor agents भी इन्हें implement करते हैं
  • OTEL Collector, Semantic Conventions, OpAMP, OTTL, और Demo तक अपना दायरा बढ़ाते हुए vendor-neutral observability की common foundation के रूप में विस्तार कर रहा है

OpenTelemetry की वर्तमान स्थिति

  • OpenTelemetry, संक्षेप में OTEL, 2019 में OpenTracing और OpenCensus के एक होने से शुरू हुआ
  • शुरुआत में यह tracing-केंद्रित project था, लेकिन विलय के बाद इसका दायरा पूरे observability क्षेत्र तक फैल गया
  • इसका लक्ष्य संगठनों को high-quality, universal, portable telemetry उपलब्ध कराने में मदद करना है
  • 4 साल बाद OTEL के पास अब यह आधार है
    • metrics, logs, और traces के लिए stable standards
    • ऐसा Collector जो किसी भी environment में telemetry receive, process, और export कर सके
    • प्रमुख भाषाओं में code instrumentation को support करने वाले SDKs
    • Semantic Conventions और agent management से जुड़े अतिरिक्त standards
  • फिलहाल OTEL, CNCF में Kubernetes के बाद सबसे सक्रिय project है, और इसके contributors प्रमुख observability vendors में फैले हुए हैं; इसका protocol भी observability providers के बीच लगभग सार्वभौमिक रूप से अपनाया जा चुका है

specification और implementation में बंटी OTEL संरचना

  • OTEL मुख्य रूप से specification और implementation से मिलकर बना है
  • specification यह परिभाषित करती है कि telemetry को capture, collect, process, और export कैसे किया जाए
    • इसे उस common standard के रूप में देखा जा सकता है जिसे vendors को OTEL-compatible बनने के लिए मानना होता है
  • implementation वे client libraries और tools हैं जो telemetry data को संभालते हैं
    • यही वह हिस्सा है जिससे end users code instrumentation करते समय सीधे जुड़ते हैं
  • project की stability आम तौर पर signal के आधार पर दिखाई जाती है
    • OTEL में signal का मतलब metrics, logs, traces जैसे telemetry data types से है
  • प्रमुख subprojects इस प्रकार हैं
    • OpenTelemetry Specification
    • OpenTelemetry SDKs
    • OpenTelemetry Protocol
    • OpenTelemetry Collector
    • Open Agent Management Protocol
    • OpenTelemetry Semantic Conventions

OpenTelemetry Specification 1.24.0

  • OpenTelemetry Specification OTEL की नींव है और यह API, SDK, तथा data model प्रदान करती है, जिन पर बाकी OTEL standards आधारित हैं
  • stabilization signal के अनुसार आगे बढ़ी
    • सितंबर 2020: tracing stable
    • नवंबर 2021: metrics stable
    • अप्रैल 2023: logs stable
  • वर्तमान में OTEL specification सभी signals पर stable स्थिति में है
  • क्योंकि log signal सिर्फ 2023 में stable हुआ, इसलिए अभी भी कई OTEL SDKs logs को support नहीं करते

OpenTelemetry SDK और auto instrumentation

  • OTEL SDK OTEL specification पर आधारित client-side instrumentation प्रदान करता है
  • हर language SDK में metrics, logs, और traces signals के लिए maturity अलग-अलग हो सकती है
  • कुछ SDKs programming language के आधार पर auto instrumentation support करते हैं
    • auto instrumentation में SDK application code में signals, खासकर traces, अपने-आप inject करता है ताकि manual instrumentation का बोझ कम हो
  • go और rust जैसी compiled languages में auto instrumentation काम नहीं करता
  • हालांकि SDK के बाहर eBPF या service mesh आधारित tools का उपयोग करके automatic trace injection पाया जा सकता है

OTLP 1.0 और data transfer standard

  • OTLP observability data भेजने के लिए एक common wire protocol है
  • इसके दो आधिकारिक transport तरीके हैं
  • इस specification को stable माना जाता है, और OTEL data को receive, process, तथा export करने वाली सभी services में इसे implement किया जा सकता है
  • OTLP को OpenTelemetry Collector implement करता है, और Grafana तथा Datadog जैसे observability vendors के agents भी इसे implement करते हैं

OpenTelemetry Collector 0.83.0

  • OTEL Collector observability data को collect, transform, और transfer करने वाला vendor-neutral agent है
  • Collector निम्न components से बना होता है
    • receivers: कई sources से push/pull तरीके से data लेते हैं
    • processors: रास्ते में data को transform, filter, enrich, और derive करते हैं
    • exporters: data को downstream destinations तक भेजते हैं
    • connectors: receiver और exporter दोनों की तरह काम करते हैं और कई pipelines को जोड़ते हैं
    • pipelines: receiver, 0 या अधिक processors, और exporter से बनी chain
    • extensions: basic auth, health check जैसी telemetry processing से बाहर की सुविधाएं देते हैं
  • ये components मिलकर observability pipeline के रूप में काम करते हैं, जिससे किसी भी source से telemetry इकट्ठा की जा सकती है, रास्ते में उसे process किया जा सकता है, और फिर मनचाहे destination तक भेजा जा सकता है
  • Collector दो projects में बंटा है
    • otel-collector: इसमें Collector के सिर्फ core components शामिल हैं, और यह मुख्य रूप से OTLP data processing से सीधे जुड़े logic को रखता है
    • otel-collector-contrib: यह integrations का संग्रह है, जिसमें अधिकांश observability providers के लिए exporters और receivers शामिल हैं
  • लिखे जाने के समय otel-collector-contrib में 91 receivers, 48 exporters, और 24 processors शामिल हैं
  • end users को सलाह दी जाती है कि वे OpenTelemetry Collector Builder का उपयोग करके सिर्फ जरूरत के components वाला otel-collector-contrib custom build बनाएं
  • AWS और Splunk जैसे vendors भी अपने OTEL distribution प्रदान करते हैं

OpAMP और agent का remote management

  • OpAMP agent remote management के लिए एक network protocol है
  • यह 2022 में OTEL में जोड़ा गया अपेक्षाकृत नया standard है, जो agents के समूह को नियंत्रित करने का vendor-neutral तरीका देता है
  • प्रबंधन का लक्ष्य otel-collector instances भी हो सकते हैं और OpAMP implement करने वाले vendor-specific agents भी
  • OpAMP की मदद से ये सुविधाएं सक्षम की जा सकती हैं
    • dynamic configuration deployment
    • agent updates
    • credentials management
  • फिलहाल OpAMP specification की Go implementation work-in-progress स्थिति में है

Semantic Conventions और अतिरिक्त projects

  • OTEL Semantic Conventions observability data में उपयोग होने वाले common attributes set को परिभाषित करती हैं
  • इनके दायरे में cloud resources, databases, exceptions, और systems शामिल हैं
  • Semantic Conventions का उपयोग OTEL SDKs करते हैं, और auto instrumentation support करने वाले SDKs में ये अपने-आप लागू हो जाती हैं
  • common semantics अलग-अलग signals के बीच correlation संभव बनाती हैं
  • OTEL के अन्य प्रमुख components भी अलग से मौजूद हैं
    • OpenTelemetry Transformation Language (OTTL): telemetry के लिए common transformation language, जिसे performance और flexibility के साथ otel-collector-contrib में design और implement किया गया है
    • OTEL Demo: microservice-आधारित shopping site जो OTEL features और अधिकांश language SDKs को दिखाती है

4 साल का बदलाव

  • OTEL प्रतिस्पर्धी tracing specifications के विलय से शुरू होकर observability का industry standard बन गया
  • पिछले 4 साल vendors और tools के पूरे ecosystem के लिए common foundation बनाने का समय रहे हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-08-29
Hacker News की राय

  • OpenTelemetry में दो समस्याएँ हैं

    1. इसकी पहचान साफ़ नहीं है। यह semantic standard है, protocol है, facade है, library है, या कौन-सी abstraction layer देता है—यह अस्पष्ट है; जवाब “सब कुछ” के काफ़ी करीब है
    2. ऐसा लगता है कि OpenTelemetry की तरफ़ से किसी ने सच में libraries को instrument करके नहीं देखा है। Instrument करने वाले को metrics, traces, logs का इस्तेमाल कैसे करना चाहिए, तीनों इस्तेमाल करने चाहिए या सिर्फ़ एक, इस पर भी कोई सुझाव नहीं है। 2 साल पहले पूछा था, लेकिन जवाब नहीं मिला: https://github.com/open-telemetry/opentelemetry-specificatio...
    • सहमत हूँ। यह sink और उससे जुड़ा पूरा घर एक साथ देने जैसा है, इसलिए documentation भी पतला और उलझाने वाला हो जाता है
      इसी तरह desktop app में usage समझने के लिए एक साधारण heartbeat implement करना चाहता था, लेकिन project के नाम को देखते हुए आश्चर्यजनक रूप से यह लगभग असंभव था। सवालों पर response भी कम मिला, इसलिए OpenTelemetry का plan पूरी तरह छोड़ दिया: https://github.com/open-telemetry/community/discussions/1598, https://github.com/open-telemetry/semantic-conventions/issue...
    • सहमत हूँ। OpenTelemetry जिन चीज़ों की सिफ़ारिश करता है, उनमें से कुछ असली SDK से संभव नहीं हैं
      उदाहरण के लिए histogram define करने वाली जगह के पास buckets define नहीं किए जा सकते। किसी global exporter जैसी जगह पर histogram name से bucket तक mapping वाली “override” list पास करनी पड़ती है। अगर metrics emit करने वाली library हो, तो यह बहुत messy हो जाता है: https://github.com/open-telemetry/opentelemetry-go/issues/38...
    • सवाल अच्छे हैं, लेकिन मुझे वे बहुत महत्वपूर्ण नहीं लगते। ऐसे सवालों का OpenTelemetry हो या कोई दूसरा proprietary system, observability क्षेत्र में साफ़ जवाब देना मुश्किल है
      अग्रणी observability कंपनियों की websites देखें तो custom instrumentation पर लेख लगभग 4 pages के होते हैं और सिर्फ़ बहुत basic बातें cover करते हैं। OTel खास तौर पर पीछे नहीं है, और जवाब आम तौर पर “स्थिति पर निर्भर करता है” जैसा होता है। अनुभव बढ़ने पर शुरुआती लोगों को उलझाने वाले ये हिस्से भी सुलझाए जा सकते हैं
    • ज़रूरत बस 3 JSON schema files maintain करने जितनी थी
    • तीसरा सवाल यह है कि क्या इसमें scalability है

  • मुझे OpenTelemetry बहुत पसंद है और मैं लगभग हर span track करना चाहता हूँ। अगर कोई vendor इस्तेमाल किया होता, तो cost की वजह से दिवालिया हो जाता
    Java auto-instrumentation से लगभग बिना मेहनत OpenTelemetry जोड़ा, और self-hosted ClickHouse में भेजकर $100 वाले EC2 पर रोज़ 700 million से ज़्यादा spans store करता हूँ: https://clickhouse.com/blog/how-we-used-clickhouse-to-store-...

    • एक छोटे personal project में SigNoz के जरिए traces/logs/metrics ClickHouse में भेज रहा हूँ। रोज़ करीब 400k–800k spans हैं(https://i.imgur.com/s0J6Mzo.png), और single t4g.small पर CPU आम तौर पर 11%, IOPS 4% के आसपास है
      traces को 1 महीने तक retain करने के हिसाब से signoz_index_v2 में 26.9 million rows और 17.06GiB, trace_log में 123 million rows और 2.64GiB, samples_v2 में 949 million rows और 345MiB के आसपास है, यानी compression अच्छा है। Recommended specs वाली ClickHouse machine इस्तेमाल करता तो tuning time कम हो जाता, लेकिन अभी भी यह ठीक काम कर रहा है
      downside यह है कि छोटे sc1 disk का IOPS करीब 4 है, इसलिए ClickHouse start होने में लगभग 5 मिनट लगते हैं, और SigNoz UI में features पर्याप्त हैं, लेकिन Datadog जैसी polish expect करना मुश्किल है
    • sampling ratio रखना चाहिए, लेकिन यह पक्का करना चाहिए कि errors सभी भेजे जा रहे हों
      पिछली नौकरी में non-error traces के सिर्फ़ 5% collect करते थे
    • व्यावहारिक रूप से ज्यादातर लोग अपना ClickHouse storage operate नहीं करना चाहते, और हर engineer SQL को code की तरह efficiently handle भी नहीं करता। फिर भी यह काफ़ी शानदार setup है
    • setup के लिए कम effort लगा, यह भी बढ़िया है। यह Java auto-instrumentation + ClickHouse exporter + Grafana ClickHouse plugin का combo है

  • OpenTelemetry से मुझे काफ़ी निराशा हुई। मेरे अनुभव में यह ज़रूरत से ज़्यादा डिज़ाइन किया गया, उलझा हुआ ढेर है, और इसका default usage experience बहुत user-hostile है
    यह खुद को universal tracing/metrics/logs format और plug-and-play libraries के ऐसे सेट की तरह promote करता है जिसमें हर ज़रूरत की चीज़ के लिए adapters हैं, लेकिन असल में यह आधा-अधूरा libraries का सेट ज़्यादा लगता है, जिसके internal implementation काफ़ी leak होते हैं, adapters की quality खराब है, और features भी बहुत ज़्यादा नहीं हैं

    • सहमत। हर बार SDK इस्तेमाल करते समय ऐसा लगता है कि common sense के orthogonal तरीके से सोचना पड़ता है। कुछ भी उम्मीद के मुताबिक काम नहीं करता, हर चीज़ में बेकार की abstraction की 3 layers होती हैं, और backdoor से access करना पड़ता है
      कई features के साथ ऐसे संकेत जुड़े होते हैं कि वे कब, कहाँ, कितना, चाँद की अवस्था कैसी हो, जब बृहस्पति आसमान में दिख रहा हो, और string length कितनी हो, तब काम करेंगे
      फिर भी leaking SDK API और आधे-अधूरे implemented features को ignore करें, तो replaceability का वादा कुछ हद तक पूरा करता है। OTel से पहले सब कुछ proprietary stack था, लेकिन अब एक standard SDK में अलग logging backend plug करके आम तौर पर काम करने की उम्मीद की जा सकती है। यह vertically integrated stack से कमतर है, लेकिन observability stack को पूरा बदले बिना हिस्सों में competition और evolution संभव बनाता है, इसलिए architecture के नज़रिए से यह partial win है
    • मैंने भी वही दर्द झेला है, लेकिन जिन alternatives का दावा है कि वे OpenAPI spec होने की वजह से बेहतर हैं, उन्हें इस्तेमाल करें तो वे भी कुछ खास बेहतर नहीं हैं: https://github.com/openzipkin/zipkin-api-example
      example सिर्फ़ यह दिखाता है कि swagger tools से OpenAPI spec (https://github.com/openzipkin/zipkin-api/blob/master/zipkin2...) को parse करके Go glue code auto-generate कैसे करें, और फिर एक auto-generated function call करके trace कैसे record करें
      documentation या कोई और example बिल्कुल नहीं था, इसलिए शक हुआ कि क्या इस approach को असल में कोई इस्तेमाल भी करता है, और अंत में REST calls के जरिए service API (https://zipkin.io/zipkin-api/#/) को सीधे इस्तेमाल करना पड़ा। OTel दर्दनाक है, लेकिन alternatives भी बेहतर नहीं हैं। SLO और SLI measurement जैसे-जैसे ज्यादा महत्वपूर्ण हो रहे हैं, उम्मीद है इस क्षेत्र में और रुचि बढ़ेगी
    • तो जानना चाहूँगा कि क्या आप कोई alternative recommend कर सकते हैं, या बस OTel को झेलते हैं
    • अच्छा होगा अगर specific experiences और improvement suggestions बताए जा सकें

  • OTel official libraries अभी web frontend में अच्छी तरह काम नहीं करतीं। उदाहरण के लिए, default state में errors को sourcemaps से जोड़ने का कोई तरीका नहीं है
    OTel project द्वारा deploy किया गया web browser collector Zone.js इस्तेमाल करता है और browser की लगभग हर चीज़ को context के रूप में intercept करता है। अगर आपने modern Angular इस्तेमाल किया है, तो आपको पता होगा कि Zone.js कभी-कभी काफी painful हो सकता है और globals को touch करके unpredictable behavior बना सकता है
    session replay जैसी चीज़ों के लिए OTel standard भी मुझे नहीं पता। Sentry, Rollbar, DataDog जैसे कई telemetry platforms इसे support करते हैं। backend teams इसे काफी पसंद करती दिखती हैं, और unique tags के साथ पूरे system में follow किए जा सकने वाले spans की boundary-crossing property मुझे पसंद है। हालांकि generate होने वाला payload कभी-कभी बहुत verbose होता है, और कुछ logging platforms ज्यादा compact हैं। practice में यह मुझे बड़ा issue नहीं लगा

    • native Promise और async/await environment में Zone.js जैसी चीज़ को सही से implement करने का फिलहाल कोई तरीका नहीं लगता
      direct instrumentation भी किया है, लेकिन वह error-prone और verbose था। browser में भी सच में https://nodejs.org/api/async_context.html#class-asynclocalst... जैसी चीज़ की ज़रूरत है
    • ज़्यादातर platforms पर Otel अच्छे instrumentation libraries बनाने के starting point के ज़्यादा करीब था
      हमारे package में हम Otel/Splunk browser SDK implementation के ऊपर session replay, improved exception tracking आदि जोड़ रहे हैं। दुर्भाग्य से ये चीज़ें default में मिलने से बहुत दूर हैं। फिर भी frontend sessions को backend traces/logs से जोड़ पाना developer experience में बड़ा बदलाव है, ऐसा मेरा मानना है: https://www.hyperdx.io/blog/browser-based-distributed-tracin...
    • Otel का यह document भी देखने लायक है: https://opentelemetry.io/docs/instrumentation/js/getting-sta...
      यह problem को पूरी तरह solve नहीं करता, लेकिन starting point है
    • DataDog की frontend instrumentation Real User Monitoring भी खास polished नहीं लगी। यह Duplo blocks से काम करने जितनी सूक्ष्मता वाला अनुभव है
      जानना चाहूँगा कि क्या किसी ने frontend tracing थोड़ा भी शुरू किया है
    • जानना चाहूँगा कि क्या आपने Grafana Faro देखा है। इसे Grafana Agent को भेजने के लिए configure किया जा सकता है, और Grafana Agent open source है और traces को दूसरी जगह store कर सकता है

  • कुछ सहकर्मियों के साथ हमने यह थोड़ा अजीब-सा विचार किया कि अब logs की ज़रूरत नहीं है। Log messages की जगह span events जोड़ दें: https://opentelemetry.io/docs/instrumentation/ruby/manual/#a...
    फिर बस span title और Jaeger में उस span का link log में छोड़ने जैसा तरीका। मैंने इसे सिर्फ़ personal project में आज़माया है, लेकिन काफ़ी ठीक लगा; बस अच्छा होगा अगर Jaeger UI इस तरह के उपयोग को बेहतर support करे
    असल में उन सहकर्मियों ने इसी topic पर talk भी दी है। अगर आप जर्मनी में Hannover के पास हैं, तो https://javaforumnord.de/2023/programm/ पर “Nie wieder Log-Files!” खोजें

    • आपका project कितना greenfield है, इस पर निर्भर करता है; अगर आपको किसी खास काम के सिर्फ़ timestamps चाहिए और duration नहीं चाहिए, तो शायद span events की भी ज़रूरत न पड़े
      हर meaningful काम के लिए spans इस्तेमाल करना, ज़्यादा powerful structured logs इस्तेमाल करने जैसा है। कई systems में यह मुश्किल है जहाँ existing logs को साथ रखना पड़ता है, लेकिन अगर project काफ़ी greenfield हो तो मैं इसकी सलाह दूँगा
    • मैंने भी इस तरीके के बारे में सोचा था, लेकिन मुझे यह अच्छा लगता है कि simple tools से मोटे तौर पर समझा जा सकता है कि क्या हो रहा है
      Traces इस्तेमाल करने के लिए बहुत-सी चीज़ों का सही तरह से काम करना ज़रूरी है। या शायद मेरा experience अभी कम है, इसलिए tools डरावने लगते हैं
    • यही Stripe के Veneur project का idea था। Spans, logs, और metrics को एक ही format में treat करना और ज़रूरत के हिसाब से cardinality को “automatically” roll up करना
      कुछ साल पहले presentation देखी थी तो यह cool लगा था, लेकिन लगा कि non-SRE developers को मनाना बहुत मुश्किल होगा: https://github.com/stripe/veneur
    • Traces को कहीं भेजने की ज़रूरत भी नहीं है। उन्हें process के अंदर रख सकते हैं और उस in-memory trace data के ऊपर API बना सकते हैं
    • हम कंपनी में भी यही बात कर रहे हैं। यह काफ़ी sense बनाता है, और मुझे लगता है कि logs को लगभग पूरी तरह हटाया भी जा सकता है

  • OpenTelemetry एक marketing-driven project है, committee-style design में भोलेपन और inefficient तरीके से implement किया गया है, और ऐसा लगता है कि इसका मुख्य लक्ष्य Fortune X00 CTOs को strategic roadmap documents में checkbox tick करने देना है
    जिसके पास choice हो, उसके इस्तेमाल करने लायक चीज़ नहीं है

    • इस thread के बाकी comments आम तौर पर अनुकूल या बहुत positive हैं; मैं और detail में सुनना चाहूँगा कि具体 तौर पर इसमें क्या खराब है
    • highlight.io के founder के तौर पर, consumer perspective से मैंने OTEL में बहुत value देखी है। हमने कई customers के लिए language support expand करने में इसका इस्तेमाल किया, और community भी बहुत receptive रही
      हमने जो changes submit किए उनका example यहाँ है: https://github.com/open-telemetry/opentelemetry-js/pull/4049
      अच्छा होगा अगर आप share करें कि आपको क्यों लगता है कि किसी को भी इसे इस्तेमाल नहीं करना चाहिए
    • मुझे नहीं लगता कि वह assessment सही है। बल्कि यह “open-source software Prometheus metrics और Jaeger traces export कर रहे हैं, और हम उनका alternative proprietary product बेचना चाहते हैं, लेकिन हर project में patches नहीं भेजना चाहते” के ज़्यादा करीब लगता है
      Datadog ने सच में OSS projects में Datadog support जोड़ने के लिए बड़ी संख्या में लोगों को लगाया था। अनजान codebases में कूद पड़ना एक strong skill है, इसलिए early career के लिए यह काफ़ी अच्छा भी रहा होगा
      OTel open-source projects को abstraction layer इस्तेमाल करने देता है, ताकि users self-hosting के बजाय खरीद सकें। यह मुझे बहुत पसंद नहीं है, लेकिन अगर service company के बाहर के लोग run कर रहे हों, तो अब शायद मैं OTel consider करूँगा। क्योंकि अगर कोई user Datadog इस्तेमाल करना चाहे, तो हम उसके रास्ते में नहीं आएँगे
      जब मैंने बहुत early OTel इस्तेमाल किया था, तो Go API बहुत inefficient था, इसलिए निराशा हुई थी। Counter increment करने के लिए context.Context चाहिए होता था, और Prometheus में export करते समय histogram buckets set करने का तरीका न होना जैसी abstraction leaks भी थीं। अब शायद उन्होंने इसे ठीक कर लिया होगा
    • यह बहुत कठोर है। मुझे लगता है data model सही दिशा में हुई प्रगति है
      Processors भी काफ़ी capable हैं, और receivers व exporters contrib collection भी कुल मिलाकर ठीक है। मैं यह नहीं कह रहा कि यह best solution है—use case पर निर्भर करता है—लेकिन इतनी तीखी आलोचना उचित नहीं लगती। संदर्भ के लिए, मैं fluent-bit maintenance team में हूँ
    • Services को OTLP में बात करने देना, और application config को OTEL collector को data भेजने तक simplify कर देना शानदार है
      Operations perspective से, developers code में जो भी observability जोड़ें, आप central filtering enforce कर सकते हैं, और applications के लिए एक ही central entry path होता है
      सब कुछ OTLP export करता है, इसलिए अगर नए backend पर जाना हो तो बस YAML file बदलनी होती है; नए logging backend को support करने के लिए application दोबारा लिखने की ज़रूरत नहीं होती। Vendor-specific logging libraries इस्तेमाल करने वाले पुराने तरीके पर लौटने की बजाय, कमियाँ हों तब भी 10 में से 10 बार मैं OTEL ही इस्तेमाल करता रहूँगा

  • इस blog का subscription popup मुझे सच में बहुत खराब लगा। x button नहीं है, इसलिए यह बिल्कुल clear नहीं है कि email दिए बिना इसे close किया जा सकता है
    Subscribe button के नीचे बहुत non-intuitive “continue reading” है; मुझे नहीं लगा था कि वह काम करेगा, और बाहर click करने पर भी यह close नहीं हुआ। ऐसी चीज़ों को बेहतर होना चाहिए
    OpenTelemetry के बारे में, मैं काफी समय से test करना चाहता था कि Datadog को data भेजते समय यह सारी ज़रूरी functionality देता है या नहीं। लेकिन अगर basic functionality के अलावा अब भी Datadog agent चाहिए, तो manage और train करने के लिए एक और चीज़ बढ़ जाएगी, इसलिए हिचकिचाहट है
    जानना चाहता हूँ कि क्या किसी ने इसे सच में Datadog से जोड़ा है। लक्ष्य ज़रूरी नहीं कि Datadog से हमेशा बंधे रहना हो, लेकिन अभी alerts और logs का अच्छा-खासा हिस्सा वहीं है, इसलिए अगर पहले OpenTelemetry पर switch करें तो theoretically बाद में किसी और चीज़ पर जा सकेंगे

    • वह popup medium.com की feature है। मैं सहमत हूँ कि यह बहुत irritating है
    • व्यक्तिगत तौर पर survey और भी खराब था। उसने opinion पूछा, मैंने एक option दबाया, तो reward के तौर पर full-screen account creation window मिल गई
      Back दबाया तो HN पर वापस चला गया

  • सोच रहा हूँ कि क्या अभी भी कोई ऐसा फ्रंटएंड है जो लोगों, इन्फ्रास्ट्रक्चर और लाइसेंस लागत के लिहाज़ से revenue stream को बुरी तरह नहीं खा जाता
    हमें प्रति सेकंड 2,000 से ज़्यादा requests मिलती हैं, और सिर्फ logs बनाए रखना भी महँगा है

    • अगर अभी तक नहीं कर रहे हैं, तो trace sampling की सलाह दूँगा। Datadog APM में कोई सस्ता setup नहीं है, इसलिए वह खास impressive नहीं लगा
      हम अपना Jaeger stack 0.1% sampling के साथ चला रहे हैं, और Datadog APM की तुलना में लागत नगण्य है
      metrics और logs के लिए sampling बहुत उपयोगी नहीं है, इसलिए कोई अच्छा जवाब नहीं है। अगर Datadog का gross margin 80% है, तो आपके भुगतान में infrastructure cost ज्यादा से ज्यादा 20% होगी, और अगर लोगों की लागत उस 80% से कम है, तो open source stack खुद चलाकर आप काफी खर्च घटा सकते हैं। Datadog इस्तेमाल करते हुए भी हम हर 3 महीने में usage घटाने का project करते हैं, इसलिए किसी भी हाल में इसे लगातार संभालना ही पड़ता है
    • जवाब sampling है। सफल requests में से सिर्फ 1% sample करें और errors सब collect करें
      लागत भी समस्या है, लेकिन यह देखकर हैरानी हो सकती है कि observability service पर उम्मीद से ज्यादा भारी पड़ती है। यह काफी CPU इस्तेमाल करती है
    • “काफी” का मानदंड तय करना होगा। पिछली कंपनी में हम traces को Cassandra में route करते थे और AWS Elasticsearch domain में store करते थे, और Jaeger से visualize करते थे
      slow queries ढूँढने के लिए basic reports बनाने को कुछ Elasticsearch queries भी लिखी थीं। OTEL/Jaeger tutorial follow करें तो यह काफी standard setup है
      traces प्रति सेकंड सैकड़ों के स्तर पर थे और downsampling के बिना सब collect किए जाते थे। retention period 7 दिन तक configure किया जा सकता था, और मेरे छोड़ने के समय वास्तविक optimization बहुत कम था। मासिक लागत शायद दसियों से सैकड़ों डॉलर के आसपास थी
      containers में set किए जा सकने वाले environment variables से tracing sampler का व्यवहार define किया जा सकता है। docs में OTEL_TRACES_SAMPLER देखें: https://opentelemetry.io/docs/specs/otel/configuration/sdk-e...
    • ज्यादातर observability vendors अब OTEL support करते हैं। जिस OSS project में मैं शामिल हूँ, वह भी OTEL collection support करता है: https://github.com/grafana/tempo/
    • समझ नहीं आ रहा कि इसे downvote क्यों किया जा रहा है। हमें भी यही परेशानी है, बस scale प्रति सेकंड 5 लाख requests का है
      अभी हम Datadog इस्तेमाल करते हैं, लेकिन सब जानते हैं कि यह बहुत महँगा है

  • इस thread का ज्यादातर हिस्सा OpenTelemetry के ज़रिए metrics/logs को self-hosted collector jobs में भेजने की बात कर रहा है
    ClickHouse जैसे कई collector tools द्वारा support की जाने वाली standard library इस्तेमाल करना अपने आप में उपयोगी है, लेकिन एक और फायदा यह है कि specification system boundaries के पार trace ID pass करने की सुविधा देती है
    अगर आप और आपकी dependencies सभी OpenTelemetry spec implement करते हैं, तो आपको ऐसे spans मिल सकते हैं जो journey के दौरान क्या हुआ इसका बारीक view देते हैं। उदाहरण के लिए, page loading में देर की वजह database में disk page load था या किसी cloud service के metadata plane span की high latency थी, यह पता चल सकता है

  • OpenTelemetry की प्रगति से बहुत संतुष्ट हूँ। कुछ साल पहले जब मैंने इसे अपनाने पर जोर दिया था, तो developers हिचक रहे थे कि यह नया है और उन्होंने इसका नाम नहीं सुना; लेकिन 1 साल पहले जब फिर देखा, तो OpenTelemetry हमारे system में हर जगह था और जिन logging/tracing vendors का हम इस्तेमाल करते हैं वे भी उसी तरफ जा रहे थे