İçeriğe geç
OpenTelemetry

OpenTelemetry (OTel); CNCF tarafından yönetilen, metric, log ve trace üretmek için satıcı-bağımsız (vendor-agnostic) açık-kaynak standardıdır. 2019’da OpenTracing ve OpenCensus projelerinin birleşmesinden doğmuş; bugün Kubernetes’ten sonra CNCF’in en aktif ikinci projesi. Modern observability’nin lingua franca’sı olarak değerlendirilebilir.

OTel’in en önemli vaadi: kodunuza enstrümantasyon yazarsınız ve hangi backend’e (Datadog, Honeycomb, Grafana Tempo, AWS X-Ray, Jaeger) göndereceğiniz config meselesidir. Vendor değişimi kod değişimi gerektirmez. SDK’lar 11+ programlama dili için olgun durumda (Java, Python, Go, Node.js, .NET, Ruby, PHP, Rust, C++, Erlang, Swift).

Mono’nun yaklaşımı

Mono ekibi yeni yazılım projelerinde OpenTelemetry’i opsiyonel değil, varsayılan olarak kabul eder. Standart kurulumumuz:

  • SDK: Auto-instrumentation ile başla (Java agent, Python opentelemetry-instrument, Node OTEL_NODE_RESOURCE_DETECTORS); kritik iş akışlarına manuel span’lar.
  • Resource attributes: service.name, service.version, deployment.environment, service.instance.id minimum.
  • Collector pattern: Agent + Gateway. Agent (DaemonSet/sidecar) hızlı kabul; gateway batch + sampling + routing.
  • Sampling: Head 5% + tail 100% (error trace’leri); ihtiyaç olursa probabilistic + always_on for critical spans.
  • Exporter: OTLP gRPC tercih (HTTP/protobuf yedek); backend Grafana Stack default.
  • Log correlation: trace_id + span_id log JSON’unda zorunlu — log → trace tek tıkla.
  • Metric: Histogram aggregation type explicit_buckets veya exponential (yeni); cumulative vs delta seçimi backend’e göre.

Tipik akış

  1. Uygulama OTel SDK ile span/metric/log üretir → OTLP olarak local agent‘a (4317 gRPC) gönderir.
  2. Agent kabul eder, hafif transformasyon, gateway’e iletir.
  3. Gateway batch + tail-sampling + filtering yapıp backend’e yönlendirir.
  4. Backend (Tempo/Mimir/Loki) veriyi saklar; Grafana sorgular.
  5. Operatör bir trace’ten log’a, log’tan metric’e tek tıkla geçer.

Yaygın sorunlar ve çözümler

  • Yüksek cardinality: userId veya requestId resource attribute’a koyulamaz; sadece span attribute olarak.
  • Lost traces: Network MTU + gRPC timeout + retry config; collector buffer yeterli mi?
  • Yavaş uygulama: Auto-instrumentation overhead’ı genelde %5’ten az, ama yoğun loop’lar etkilenebilir; production’da profil al.
  • Vendor migration zor: Backend bağımlı attributes set’i kullandıysanız (örn. aws.region). Standart konvansiyonlara (semantic conventions) bağlı kal.
  • Log volume patlaması: OTel log signal yeni; eski stdout log’ları paralel toplamayı düşür.

İlgili hizmetlerimiz

Sıkça sorulan sorular

OpenTelemetry zorunlu mu?
Yeni uygulamalar için: kesinlikle evet. Vendor lock-in olmadan trace/metric/log üretmenizi sağlar — bugün Datadog’dasınız, yarın Grafana’ya geçmek istediğinizde sadece backend’i değiştirirsiniz, kodunuza dokunmazsınız. Bu, son 10 yılın en önemli observability standardıdır.
Auto-instrumentation mı manuel mi?
Başlangıçta auto (Java agent, Python opentelemetry-instrument, Node --require @opentelemetry/auto-instrumentations-node/register). Belirli iş süreçlerini detaylı izlemek için manuel span’lar (tracer.startSpan("operation")). İkisi birlikte kullanılır.
Sampling stratejisi ne olmalı?
Düşük trafikte %100. Yüksek trafikte head-based %1-5 + tail-based %100 hata trace’leri için. Tail-sampling Collector’da yapılır; uygulamada head-sampling SDK ayarıyla. Önemli: parent-based sampling ile child span’lar tutarlı olmalı.
Backend olarak ne öneriyorsunuz?
Açık-kaynak: Tempo (trace) + Mimir (metric) + Loki (log). SaaS: Grafana Cloud, Honeycomb, Datadog. OTLP standardı sayesinde backend bağımsızlığı korunur — Mono müşterilerimizin %80’i Grafana Stack tercih ediyor.

Bir sonraki dönüşümü birlikte planlayalım.

Ekibimiz teknik gereksinimlerinizi anlamak ve hızlıca prototip çıkarmak için hazır.

Bir sonraki dönüşümü birlikte planlayalım.

Ekibimiz teknik gereksinimlerinizi anlamak ve hızlıca prototip çıkarmak için hazır.