Kavramlar

Bu sayfayı bir kez, acele etmeden okuyun. Sonrasında Orbtrace'in her ekranı anlamlı gelecek. Hiçbir ön bilgi varsaymıyoruz.

Yazılımınızın neden "telemetriye" ihtiyacı var

Yazılımınızın yoğun bir restoran olduğunu hayal edin. Dışarıdan yalnızca müşterilerin girip çıktığını görürsünüz — başka bir şey değil. Hiçbir fikriniz yok:

• Mutfak hangi yemekleri hazırladı, her aşaması ne kadar sürdü?
• Bulaşık makinesi tıkalı mı?
• Geçen salı işe aldığınız aşçı eskisinden yavaş mı?

Bu soruları yanıtlamak için restoranın kayıtlara ihtiyacı var. Yazılımda bu kayıtlara telemetri denir. Orbtrace üç türünü yönetir:

1. 1

   Loglar — günlük

   Bir log satırı, yazılımınızın bir şey olduğunda yazdığı tek bir cümledir.

   2026-05-13 14:02:11.842  INFO   checkout-api    Kullanıcı 42, 19.99 ₺ sipariş verdi
   2026-05-13 14:02:12.103  ERROR  checkout-api    Ödeme sağlayıcı 503 döndü

   Her satırda şunlar vardır:

   • Zaman damgası (ne zaman olduğu).
   • Önem derecesi (INFO, WARN, ERROR, FATAL).
   • Servis adı (yazan program — checkout-api).
   • Mesaj (insan tarafından okunabilir cümle).
   • İsteğe bağlı öznitelikler (yapılı alanlar: user_id=42, order_total=19.99).

   Orbtrace'te logları Loglar ekranında arar ve süzersiniz.

2. 2

   Trace ve span — fiş

   Trace, tek bir isteğin ona dokunan her servisten geçişinin kaydıdır. Bu yolculuktaki her adıma span denir.

   Bir müşteri "satın al"a basarsa, istek şu yolu izleyebilir:

   • frontend (10 ms — buton tıklamasının çizimi)
     • checkout-api (140 ms — sepeti doğrula)
       • inventory-service (12 ms — stok kontrolü)
       • payment-provider (115 ms — kartı çek)
       • email-service (5 ms — fişi kuyruğa koy)

   Tüm yolculuk tek bir trace'tir (altında beş span yuvalanmıştır). Her span şunu bilir:

   • Ebeveynini (kim çağırdı).
   • Başlangıç zamanını ve süresini.
   • Başarılı mı başarısız mı olduğunu.
   • Özniteliklerini (örn. db.statement="SELECT * FROM orders").

   Orbtrace'te trace şelalesini görürsünüz; her yatay çubuk bir span'dir, çubukların derinliği iç içe geçmeyi gösterir.

   Trace'ler neden önemli?

   Loglar "bir servis ne dedi?" sorusuna yanıt verir. Trace'ler ise "bütün isteğin zamanı nereye gitti?" sorusuna yanıt verir. Bir sayfa yavaşken trace, tahmin etmenize gerek kalmadan hangi adımın yavaşladığını gösterir.

3. 3

   Metrikler — gösterge tablosu sayısı

   Metrik, düzenli aralıklarla ölçülen bir sayıdır.

   • "checkout-api'a saniyede istek" → her 10 saniyede bir ölçülür.
   • "inventory-service pod'unun bellek kullanımı" → her 15 saniyede.
   • "email-worker kuyruk derinliği" → her 5 saniyede.

   Metrikler üç çeşittir:

   On screen

   • Counter (sayaç)Yalnız yukarı gider. Örnek: servis başladığından beri toplam sipariş. "Dakikadaki sipariş" görmek için Orbtrace'e rate(orders_total[1m]) sorgusunu sorarsınız.
   • Gauge (ölçüm)Yukarı-aşağı oynar. Örnek: anlık kuyruk derinliği, anlık bellek, anlık CPU.
   • HistogramYalnız son değeri değil, değerlerin dağılımını kaydeder. Örnek: istek gecikmesi — "son dakikanın 99. yüzdebirliği" sorulabilir.

   Metrikleri Metrikler ekranında keşfeder, üstlerinden Panolarda pano kurarsınız.

SLO — verdiğiniz söz

SLO (Service Level Objective — Hizmet Düzeyi Hedefi), bir servisin ne kadar iyi çalışacağına dair ölçülebilir sözdür. Örnek: "Checkout isteklerinin %99,9'u, son 30 günlük yürüyen pencerede 500 ms altında tamamlanacak."

Her SLO'da üç sayı vardır:

• SLI (Service Level Indicator — Hizmet Düzeyi Göstergesi) — ölçtüğünüz şey. "500 ms altında biten isteklerin oranı."
• SLO — hedef. "%99,9'u."
• Hata bütçesi — bozulmaya izin verilen miktar. 30 günde %99,9 hedefi, %0,1 hata bütçesi demektir; yani ayda 43 dakikalık "sağlıksızlık" hakkı.

Hata bütçeniz olması gerektiğinden hızlı tükenirse (örneğin 14× hızla), Orbtrace bir burn-rate alarmı üretir. SLO'lar Yönetim → SLO'lar bölümünden yapılandırılır.

RCA — "neden?" sorusuna yapay zekânın cevabı

RCA = Root Cause Analysis (Kök Sebep Analizi). Orbtrace'te RCA bir yapay zekâ özelliğidir: bir olay sırasında trace'leri, logları ve son deploy'ları okur ve şunun gibi bir paragraf üretir:

"checkout-api p99 gecikmesi 14:02'de (Europe/Istanbul) 220 ms'den 2,1 s'ye fırladı. Değişim, 13:58'de yapılan ve OrderRepository.findByUser'i bir indeks ipucunu kaldıracak şekilde değiştiren a8f21b deploy'u ile örtüşüyor. b3f2… ve c81a… span'leri bu sorgunun orders tablosunda 1,8 s harcadığını gösteriyor (id 84210)."

Span ID'lerini kaynak olarak gösterir; tıklayıp doğrulayabilirsiniz. RCA sonuçları Olaylar (Incidents) ekranında yaşar.

Geriye Dönük Oynatma — varsayım motoru

Bir olay kapandıktan sonra Orbtrace'e şunu sorabilirsiniz: "a8f21b deploy'u yapılmasaydı ne olurdu?" — geçmiş veri, benzer geçmiş olaylar ve yapay zekâ ile olası bir cevap tahmin edilir. Tam bir simülasyon değil, temellendirilmiş bir sezgisel yöntemdir: güven aralıklı olasılıksal bir sonuç alır, karşılaştırılabilir geçmiş olaylar kaynak gösterilir. Post-mortem ve deploy öncesi canary kararları için biçilmiş kaftan. Geriye Dönük Oynatma.

OpenTelemetry — verinizin bindiği otobüs

Uygulamalarınız Orbtrace'le asla doğrudan konuşmaz. OpenTelemetry (OTel) konuşurlar — bütün sektörün telemetri verisi için üzerinde anlaştığı açık standart. Her büyük dilin bir OTel SDK'sı vardır (Java, Node, Python, Go, .NET, Ruby, Rust, …) ve eklemek çoğu zaman tek satır config'dir.

Oradan sonra verinizin izlediği yol kısadır ve hep aynıdır. Uygulamanız loglarını, trace'lerini ve metriklerini OpenTelemetry Collector denen küçük bir programa teslim eder. Collector tüm uygulamalarınızdan gelen veriyi toplar, verimli paketler hâlinde gruplar ve Orbtrace'in veritabanı Apache Doris'e yazar. Orbtrace'i açtığınızda Doris'ten okur ve ekranda gördüğünüzü çizer.

Bu dolaylılık niye var? Çünkü standart bize değil, sektöre aittir: uygulamalarınızı bir kez, OTel'e karşı enstrümante edersiniz ve satıcıdan bağımsız kalırlar — aynı veri OTel uyumlu herhangi bir backend'i besleyebilir.

Baştan anlaşılması gereken önemli bir nokta: Orbtrace, Collector'ı paketlemez. Orbtrace ürünü gönderir — sunucu, arayüz ve depolama — Collector'ı siz çalıştırırsınız (sağladığımız bir config ile standart, değiştirilmemiş otel/opentelemetry-collector-contrib image'ı). Bu kasıtlıdır ve diğer modern observability yığınlarının çalışma şekliyle örtüşür: Collector zaten OTLP alımını, batch'lemeyi, retry'ı ve geri-basıncı 100K+ olay/sn'de hallediyor, yeniden yazmak hiçbir şey katmaz. Bir tane ayağa kaldırmak tek bir docker run — bkz. Entegrasyon desenleri.

Dokümanların geri kalanında "OTLP", "OTel SDK" ve "Collector" sözcüklerine bu yüzden rastlayacaksınız.

Daha sonra karşınıza çıkacak terimler

Bunları ezberlemenize gerek yok. Bağlam içinde tekrar karşınıza çıkacaklar.

Sırada on dakikalık Hızlı başlangıç.