Signals may be push or pull; back-end determines whether scraping/tailing is possible • If instrumentation direct to back-end then every application, and language-specific, needs to: ◦ Authenticate ◦ Batch ◦ Compress ◦ CRUD metadata ◦ Encryption ◦ Proxy ◦ Queue ◦ Retry • In addition, host telemetry is desirable and correlation can be challenging metrics logs
Signals may be push or pull; back-end determines whether scraping/tailing is possible • If instrumentation to collector then every application, and language-specific, needs to (everything else optional): ◦ Batch ◦ Queue ◦ Retry • In addition, the collector can capture host telemetry and correlate with application telemetry as well as convert between formats Collector metrics + logs traces metrics + logs
◦ Instrumentation responsible for full exporting lifecycle; requires even more resources ◦ Instrumentation export features are language-specific; mileage may vary ◦ Adding resource information may prove challenging or impossible ◦ Summary: great for proof-of-concepts, be careful in production environments
◦ Instrumentation responsible for full exporting lifecycle; requires even more resources ◦ Instrumentation export features are language-specific; mileage may vary ◦ Adding resource information may prove challenging or impossible ◦ Summary: great for proof-of-concepts, be careful in production environments • Application instrumentation to local Collector (agent) to back-end ◦ Instrumentation responsible for minimal exporting lifecycle ◦ Central location for most configuration changes: Collector ◦ Resource enrichment straightforward; able to translate between formats ◦ Summary: generally recommended
(agent) to remote Collector (gateway) to back-end ◦ Often used for advanced use-cases such as tail-based sampling or metric aggregations ◦ May help security by limiting egress and centralizing token management ◦ Can offer more queuing and retry ◦ Summary: not required, but may provide value depending on requirements
(agent) to remote Collector (gateway) to back-end ◦ Often used for advanced use-cases such as tail-based sampling or metric aggregations ◦ May help security by limiting egress and centralizing token management ◦ Can offer more queuing and retry ◦ Summary: not required, but may provide value depending on requirements • Application instrumentation to remote Collector (gateway) to back-end ◦ Pretty much same as application instrumentation direct to back-end ◦ Can offer client-side capabilities ◦ Summary: may be helpful for proof-of-concepts, be careful in production environments
With serverless, signals are typically pushed or handled by cloud provider telemetry. • If instrumentation direct to back-end then every application, and language-specific, needs to: ◦ Authenticate ◦ Batch ◦ Compress ◦ CRUD metadata ◦ Encryption ◦ Proxy ◦ Queue ◦ Retry • Common challenges with instrumenting serverless include cold boot time, resource consumption, and export latency
are typically pushed or handled by cloud provider telemetry. • If serverless instrumentation to collector then every application, and language-specific, needs to (everything else optional): ◦ Batch • In addition, export latency can be reduced using a Collector Collector traces metrics logs traces, metrics, logs
◦ Instrumentation responsible for full exporting lifecycle; requires even more resources ◦ Instrumentation export features are language-specific; mileage may vary ◦ Instrumentation and export latency may prove problematic ◦ Summary: generally recommended
◦ Instrumentation responsible for full exporting lifecycle; requires even more resources ◦ Instrumentation export features are language-specific; mileage may vary ◦ Instrumentation and export latency may prove problematic ◦ Summary: generally recommended • Serverless instrumentation to remote Collector to back-end ◦ Instrumentation responsible for minimal exporting lifecycle ◦ Central location for most configuration changes: Collector ◦ Summary: optional, but generally recommended
must be pushed. • Browser instrumentation needs to: ◦ Authenticate (publicly!) ◦ Batch ◦ Compress ◦ Encrypt ◦ Queue ◦ Retry Hosted traces metrics logs • RUM data and APM data can be sent separately (stitching via context propagation)
◦ Instrumentation responsible for full exporting lifecycle; authentication often different! ◦ Summary: generally recommended • RUM instrumentation to remote Collector to back-end ◦ Instrumentation responsible for full exporting lifecycle; authentication often different! ◦ Collector should not be exposed to the Internet today! ◦ Summary: possible, but not recommended at this time
to enable it ◦ https:/ /doordash.engineering/2021/04/07/optimizing-opentelemetrys-span-processor/ • Compression really matters so be sure to enable it (~6x typical)
to enable it ◦ https:/ /doordash.engineering/2021/04/07/optimizing-opentelemetrys-span-processor/ • Compression really matters so be sure to enable it (~6x typical) • Queuing is pay to play (more resources = more data) ◦ Instrumentation libraries: typically very small ◦ Collector as agent: moderate ◦ Collector as gateway: sky’s the limit
to enable it ◦ https:/ /doordash.engineering/2021/04/07/optimizing-opentelemetrys-span-processor/ • Compression really matters so be sure to enable it (~6x typical) • Queuing is pay to play (more resources = more data) ◦ Instrumentation libraries: typically very small ◦ Collector as agent: moderate ◦ Collector as gateway: sky’s the limit • Collector supports a wide range of use-cases ◦ CRUD metadata is very powerful ◦ Offers a lot of exporters
Already have instrumentation? Jaeger? Prometheus? Use it! ◦ Only want to use OpenTelemetry for tracing? That’s fine! ◦ Interested in semantic conventions? OTel has you covered! ◦ Looking for a unified and vendor-agnostic collector? Check! ◦ Need serverless or RUM support? No problem!
Already have instrumentation? Jaeger? Prometheus? Use it! ◦ Only want to use OpenTelemetry for tracing? That’s fine! ◦ Interested in semantic conventions? OTel has you covered! ◦ Looking for a unified and vendor-agnostic collector? Check! ◦ Need serverless or RUM support? No problem! • Reference architecture is OTLP all the way! ◦ Instrumentation library to Collector as agent? OTLP ◦ Collector as agent to Collector as gateway (optional)? OTLP ◦ Sending to back-end? Ideally OTLP (limited support today https:/ /opentelemetry.io/vendors/, but expect more soon!)
Join the conversation: ◦ Each SIG leverages GitHub discussions ◦ CNCF Slack: https:/ /cloud-native.slack.com • Submit a PR (consider good-first-issue and help-wanted labels)
chanyou0311
personabb
sonic
nobutomurata
kawaguti
dak2
elmodev09
kubode
hamukazu
you
seike460
jacopen
holman
mayatellez
marcelosomers
samlambert
tmiket
gurzu
jcasabona
joshbly
coloredviolet
sabderemane
keathley
kimpetersen
