Event language
UI language
<p>Getting started with OpenTelemetry [OTel] is accessible, but hardening it for production scale presents significant Day 2 challenges, especially around collector deployment, reliability, and cost control. This session provides a complete guide, beginning with the foundations and culminating in advanced, multi-layered architectural patterns.</p><p>We will start with a quick refresher on the OTel framework, covering basic manual/automatic instrumentation and the collector's role, and later venture out to explore various <strong>deployment patterns for the Opentelemetry collector specially in a Kubernetes environment,</strong> like:</p><ol><li><p><strong>Foundational Deployments:</strong> The trade-offs of using OTel Collectors as <strong>Sidecars</strong> [isolation] vs. <strong>DaemonSets</strong> [node-level collection].</p></li><li><p><strong>High-Scale Patterns:</strong> Deep-diving into resilient architectures:</p><ul><li><p><strong>Load-Balanced Gateways:</strong> Essential for high availability and enabling advanced features like <strong>tail-based sampling</strong> [which requires consistent hashing for trace stability].</p></li><li><p><strong>Multi-Cluster Architectures:</strong> Creating layered pipelines for regional aggregation, cross-cluster authentication, and cost-effective data egress.</p></li><li><p><strong>Multi-Tenant & Per-Signal Patterns:</strong> Using the Collector’s routing capabilities to isolate traffic by team or signal type [metrics/traces/logs] for optimal resource allocation. Basically, the collector acts as a central point and an ingress for various data points.</p></li></ul></li></ol><p>The latter half of the session will be dedicated to <strong>practical decision-making</strong>: providing a structured methodology for DevOps and SRE teams to weigh the pros and cons of each pattern and confidently select the most suitable architecture for their specific scale, complexity, and compliance needs. </p>