Observability bir eklenti değil — orchestrator’dur.

Çoğu ekip önce orchestrator’ı kurar, observability’yi sonra ekler. Biz tersini yaptık. Trace zaman çizelgesi, herhangi bir uzman agent’tan önce vardı ve o zamandan beri yayına aldığımız her agent ona yazmak üzere kuruldu. Herhangi bir çalıştırmayı tekrar oynatabilmemizin, herhangi bir kararı denetleyebilmemizin ve herhangi bir değişikliği geri alabilmemizin sebebi bu sıralama.

Önce rayı kurun

Trace’i ikinci kurduğunuzda, ondan önce yayına aldığınız her agent’ın kendi ad-hoc loglama formatı olur. Sonraki çeyreği adapter yazarak geçirirsiniz. Trace’i önce kurduğunuzda, her yeni agent formatı miras alır çünkü seçilecek başka bir format yoktur.

Bir trace neler içerir

• Çalıştırma için trace_id ve parent_id.
• Her hand-off (hangi uzman, hangi girdiyle çağrıldı).
• Her tool çağrısı (verb, hedef, gecikme, idempotency-key).
• Her model çağrısı (prompt, yanıt, model, token, maliyet).
• Her karar (router niyeti, güven, eskalasyon durumu).
• Her sonuç (başarı, uyarı ile yumuşak hata, hata ile sert hata).

Replay öncelikli tasarım

Trace doğrunun kaynağı olduğu için herhangi bir çalıştırmayı uçtan uca tekrar oynatabiliriz. Agent’larda regresyon testini uygulanabilir kılan şey bu: yeni bir uzmanı yayına alın, dünkü 10 bin trace’i ona karşı tekrar oynatın, çıktıların farkını alın, yayınlayın veya geri alın.

Observability aynı zamanda bir ürün yüzeyidir

Trace’i müşteri panosunda gösteriyoruz. Bir kullanıcı garip bir sonuç bildirdiğinde destek trace_id’yi ister ve birlikte bakarız. Bu ‘destek talebi’ kavramının ne anlama geldiğini değiştirir: log’lar üzerinde tahmin yürütmüyoruz, müşterinin gördüğü aynı zaman çizelgesine bakıyoruz.

“Observability, panoda bir sekme değildir. Agent’larınızın içinde yaşadığı runtime’dır.”