Her şeye alarm veriyordum: tarayıcı hata gürültüsünü işe yarar üretim izlemeye nasıl dönüştürdüm

İstemci tarafı hata raporlamasını, gerçek kullanıcıların yaşadığı ve yerelde güvenilir biçimde yeniden üretemediğim sorunları görebilmek için kurdum. Raporlayıcı tam da istediğimi yapıyordu: hatayı yakalıyor ve bana gönderiyordu.

Sorun, neredeyse her şeyin aynı derecede önemli görünmesiydi.

Harici bir analiz betiği yüklenmedi mi? Kırmızı alarm. Reklam betiği engellendi mi? Kırmızı alarm. Bir tarayıcı botu Google Analytics’i yükleyemedi mi? Kırmızı alarm. Video önizlemesi play() çağırdı ve Promise tamamlanmadan durduruldu mu? Kırmızı alarm. Yararlı kaynak veya çağrı yığını olmayan Script error. geldi mi? Yine kırmızı alarm.

Aynı akışın içinde gerçekten müdahale gerektiren arızalar da vardı: kendi uygulamamın URL’si yanlışlıkla https://example.comhttps://example.com/... biçimine dönüşmüş, ayrıca tarayıcı /_next/static/chunks/... altındaki uygulamaya ait bir Next.js dosyasını yükleyememişti.

Veri toplama çalışıyordu. İzleme katmanı çalışmıyordu.

Bu ayrım, frontend gözlemlenebilirliğine bakışımı değiştirdi. Bir hata olayı yalnızca bir şeyin gerçekleştiğine dair kanıttır. Henüz teşhis, önem seviyesi veya olay değildir.

İlk hata, “error” kelimesini doğrudan “acil” saymaktı

İlk zihinsel modelim neredeyse şuydu:

tarayıcı hata bildirir
        ↓
CLIENT ERROR gönder
        ↓
geliştirici müdahale etmeli

Bu model birbirinden farklı soruları tek potada eritiyordu. Hata benim kodumda mı? Etkin rota gerçekten bozuldu mu? Bu beklenen bir iptal miydi? Tarayıcı kaynağı belirleyecek kadar bilgiye sahip mi? Uygulama toparlandı mı? On mesaj on ayrı olay mı, yoksa tek bir olayın on belirtisi mi?

Bu sorular yanıtlanmadan bir olay otomatik olarak alarma dönüşmemeli.

İlk incelemelerden birinde önümde yaklaşık on sekiz mesaj vardı. Çoğu üçüncü taraf kaynaklı gürültü veya normal yaşam döngüsü davranışıydı. İki tanesi açıkça farklıydı: uygulamama ait bozuk URL kesin bir hataydı; uygulamaya ait JavaScript parçasının yüklenmemesi ise sayfanın ihtiyaç duyduğu kodu erişilemez hâle getirebilirdi. Buna rağmen raporlayıcı, neredeyse hepsini engellenmiş bir reklamla aynı aciliyette gösteriyordu.

O noktada “tarayıcıdaki tüm hataları toplamak” ile “üretim izleme sistemi kurmak” benim için ayrı problemler oldu. Toplama katmanı kanıtı saklar; izleme katmanı bu kanıtı karara dönüştürür.

Tarayıcının bütün arızaları aynı anlamla taşıyan tek bir hata kanalı yoktur

İstemci tarafındaki farklı arızalar aynı anlamla gelmez.

window üzerindeki error olayı eşzamanlı betik hatalarında kullanılır ve kaynak yükleme hatalarında da rol oynar. İşlenmemiş Promise reddi başka bir yoldan gelir; tarayıcı unhandledrejection üretir. Betik, görsel veya medya yükleyen öğeler kendi error olaylarını da oluşturabilir. React ve Next.js bunun üzerine framework düzeyinde hata sınırı sinyalleri ekler.

window.error
→ senkron bir script hatası dışarı çıkmış olabilir

unhandledrejection
→ reddedilen Promise o anda işlenmemişti

element error
→ bir resource yüklenemedi veya kullanılamadı

framework boundary
→ render veya execution hata sınırına ulaştı

Küresel bir dinleyici sistem sınırında görülen belirtiyi yakalar; tüm nedensel zinciri bilmek zorunda değildir.

Bunu kabul ettikten sonra her olayı hemen tek bir genel Error nesnesine ve tek bir önem seviyesine sıkıştırmayı bıraktım.

İlk yararlı filtre: hata kime ait?

Gürültüyü azaltan ilk yararlı ayrım, bozulan kodun veya kaynağın kime ait olduğunu belirlemekti.

/_next/static/chunks/app/... yükleme hatası, başka bir origin üzerindeki reklam SDK’sının hata vermesiyle aynı şey değildir. Kendi URL üreticimin bozuk adres oluşturması, engellenmiş analiz isteğiyle aynı değildir. Tarayıcı eklentisi hataları da ayrı bir kategoridir.

• Uygulamanın kendisi: kendi JavaScript, CSS, API, medya kaynaklarım ve ürettiğim URL’ler;
• Framework ve çalışma zamanı: uygulamanın yürütme zincirindeki Next.js veya React;
• Harici entegrasyonlar: analiz, reklam, widget’lar ve harici SDK’lar;
• Ortam: tarayıcı eklentileri, tarayıcı botları, ağ durumu, gizlilik araçları ve tarayıcıya özgü davranışlar.

Bu, üçüncü tarafların önemsiz olduğu anlamına gelmez. Ödeme veya kimlik doğrulama sağlayıcısı kritik olabilir; reklam arızasının gelir etkisi olabilir. Ama entegrasyon sağlığının bozulması otomatik olarak uygulamanın çöktüğü anlamına gelmez.

Her şeyi aynı acil alarm kanalına gönderirsem kanalın ne anlattığı belirsizleşir.

Uygulamama ait iki arıza bana “eyleme dönüştürülebilir” sinyalin ne olduğunu öğretti

Bozuk URL basit vakaydı:

https://example.comhttps://example.com/resource

Bu durumda AdBlock, VPN veya tarayıcı politikaları hakkında teori üretmeye gerek yoktu. URL’nin kendisi geçersizdi. Kodun bir yerinde zaten mutlak URL olan bir değerin önüne origin bir kez daha ekleniyordu.

Bu olay eyleme dönüştürülebilirdi; çünkü kanıt belirgindi, kaynak bana aitti ve sorun kontrol ettiğim bir kod yoluna işaret ediyordu.

Next.js parçasının yüklenmemesi ise farklıydı:

Failed to load script:
/_next/static/chunks/9253.647385b4be0958e4.js

Bu da uygulamaya aitti ve sayfayı bozabilirdi, fakat olay tek başına nedeni kanıtlamıyordu. Eski bir istemci önceki dağıtımdan dosya isteyebilirdi; istek zaman aşımına uğrayabilirdi; ters proxy veya CDN hata verebilirdi; bağlantı kopabilirdi; ya da dosya gerçekten eksik olabilirdi.

Doğru tepki “nedeni buldum” değil, “yüksek öncelik ve daha fazla bağlam gerekiyor” olmalıydı.

Neden konusunda güven düşükken bile önem seviyesi yüksek olabilir.

Script error. bir ipucudur, çağrı yığını değildir

Error: Script error.
filename: unknown
line: 0
column: 0

Tehlikeli görünür ama neredeyse hiçbir bilgi taşımaz.

Tarayıcılar originler arası betik hatalarının ayrıntılarını bilerek sınırlar. MDN, doğru CORS ayarları olmadan window.onerror üzerinden sınırlı bilgi alınabildiğini belirtir; <script> içindeki crossorigin davranışı tam hata bilgisinin erişilebilir olup olmadığını doğrudan etkiler.

Bu yüzden belirsiz bir Script error. olayını otomatik olarak “uygulamam çöktü” diye yorumlamıyorum. Kaynak kendi kodum, üçüncü taraf kodu, enjekte edilmiş kod ya da tarayıcının originler arası kısıtlar nedeniyle ayrıntısını gösteremediği bir hata olabilir.

Olayı saklayıp sayfa, derleme, tarayıcı ve yakın olaylarla ilişkilendiriyorum; fakat tek bir 0:0 acil alarm üretmiyor. Aynı imza belirli bir sürüm veya rota çevresinde kümelenmeye başlarsa önceliği değişiyor.

Bilinmiyor demek zararsız demek değildir. Kritik demek de değildir.

AbortError tamamen gerçek bir hata olup yine de normal yaşam döngüsünün parçası olabilir

Bunun en net örneğini video önizlemelerinde gördüm:

AbortError:
The play() request was interrupted by a call to pause()

HTMLMediaElement.play() bir Promise döndürür ve bu Promise reddedilebilir. Medya yaşam döngüsü işlemleri bekleyen oynatmayı bilinçli olarak durdurabilir; MDN ayrıca load() çağrısının bekleyen play() Promise’larını AbortError ile iptal ettiğini açıkça belgeler.

Bir önizleme ızgarasında, kullanıcıya görünür hiçbir bozukluk olmadan bu durum kolayca oluşabilir. Öğe viewport’a girer, kod play() çağırır; kullanıcı kaydırır, öğe viewport’tan çıkar; oynatma başlamadan önce kod medyayı durdurur veya değiştirir.

Promise reddi gerçektir. Kullanıcının yaşadığı bir olay ise hiç olmayabilir.

Doğru çözüm genellikle çağrının yanındadır: Promise’ı orada ele almak ve beklenen iptali gerçek oynatma arızasından ayırmak. unhandledrejection bir güvenlik ağı olmalı; normal medya yaşam döngüsünü ilk kez yorumladığımız yer değil.

Üçüncü taraf arızalarının ayrı bir sağlık modeli olmalı

İlk loglarımda analiz ve reklam alanlarından çok sayıda hata vardı. Bazıları gizlilik odaklı tarayıcılardan, bazıları tarayıcı botlarından geliyordu. Acil alarm olarak özellikle anlamsız bir örnek, Google Analytics’i yükleyemeyen bir bot idi.

Bu yalnızca bir ağ isteğinin başarısız olduğunu söyler. İnsan kullanıcının uygulamayı kullanıp kullanamadığı hakkında neredeyse hiçbir şey söylemez.

Olayı saklamak hata değildi. Hata, onu uygulamaya ait yüklenemeyen JavaScript parçasıyla aynı olay akışına koymaktı.

• Uygulama kullanıcı için bozuldu mu?
• Harici entegrasyon sağlıklı mı?

Engellenen reklam betiği reklam teslimatı metriğine gidebilir. Analiz hatası analiz kapsamını ölçen bir metriğe gidebilir. Temel işlev gerçekten bunlara bağlı değilse hiçbiri “frontend çöktü” diye acil alarm üretmemeli.

Bu ayrım üçüncü taraf sorunlarını da daha görünür yapar: bunları rastgele kırmızı gürültü yerine sağlayıcı, tarayıcı ve bölgeye göre toplayabilirim.

navigator.onLine bağlamdır, bağlantı kanıtı değildir

Daha sonra tarayıcının kendini çevrimiçi sayıp saymadığını da kaydetmeye başladım. Faydalı bir alan, ama yalnızca ipucu olarak.

Ek mantığın ağ hatası saydığı bazı olaylarda aynı logda şunu görüyordum:

Online: true

Bu bir çelişki değil. MDN, navigator.onLine değerinin tarayıcı ve işletim sistemi sezgilerine dayandığını açıkça uyarır. Bir cihaz yerel ağa bağlı olup benim originime ulaşamayabilir. VPN, güvenlik duvarı, DNS ve kısmi ağ kesintileri resmi daha da karmaşıklaştırır.

online === false
→ ortam kaynaklı sorun için güçlü ipucu

online === true
→ origin veya resource erişilebilirdi anlamına GELMEZ

Bu küçük ayrım, izleme sisteminin bir ipucunu kendinden emin ama yanlış teşhise çevirmesini önler.

Tek bir kök arıza birden fazla tarayıcı olayı üretebilir

Toplamayı iyileştirince başka bir gürültü türü görünür oldu: tek olay birden fazla mesaj üretebiliyordu.

Bir JavaScript parçası önce resource.error üretebilir, ardından modül yükleyici ChunkLoadError fırlatabilir, React veya Next.js hata sınırını aşabilir ve kurtarma mantığı yeniden yüklemeyi planlayabilir. Her katman ayrı alarm gönderirse tek kullanıcı eylemi birden fazla bağımsız üretim arızası gibi görünür.

Beş mesaj psikolojik olarak beş etkilenen kullanıcı gibi görünür; oysa hepsi tek oturum ve tek kaynaktan gelmiş olabilir.

Yalnızca mesaj metnine göre yinelenenleri silmek yetmez. Olay düzeyinde ilişkilendirme gerekir:

session
+ kısa zaman penceresi
+ normalize edilmiş error class
+ first-party resource
+ client build
+ route

Ham olayları saklarım, ama insana en güçlü sinyali taşıyan olay gösterimi gitmeli. Hata sınırında kendi koduma ait çağrı yığını ve parçanın tam URL’si zaten varsa, önce gelen genel kaynak hatasının ikinci bir acil alarm oluşturmasına gerek yok.

Alarmı olaya ver. Ham olayları sakla.

Hatanın çevresindeki bağlam, hata metninin kendisinden daha değerli hâle geldi

Daha sonraki telemetrim çok daha yapılandırılmıştı:

clientBuildId
resource URL
resourceResponseStatus
resourceTransferSize
resourceDurationMs
serviceWorkerVersion
serviceWorkerController
serviceWorkerState
chunkRecoveryScheduled
online
stack / component stack

Medya için ayrıca medya hata kodunu, bağımsız biçimde gözlenebiliyorsa HTTP durumunu, gerçek Content-Type değerini ve arızanın HTTP mi yoksa ağ teslimatı mı gibi göründüğünü kaydediyordum.

Bu alanlar tek bir istisna metninin yanıtlayamayacağı soruları sormamı sağladı: hatalar tek bir derlemeyle mi başladı? Tarayıcı HTTP yanıtı aldı mı? Service Worker sayfayı kontrol ediyor muydu? Kurtarma mantığı çalıştı mı? Birden fazla olay aynı kaynağa mı işaret ediyor? Etkin rota gerçekten bozuldu mu?

Resource Timing API kaynak süresi, aktarım bilgisi ve desteklenip izin verildiği yerlerde yanıt durumunu sağlayabilir. Bunun sınırları vardır: originler arası zamanlama kısıtlıdır, önbellekten gelen kaynaklarda transferSize: 0 olabilir ve responseStatus her yerde kullanılamaz. Bu nedenle null ve 0 anlamlı durumlar olarak kalmalı; sahte kesinliğe dönüştürülmemeli.

ChunkLoadError bir belirtidir, 404 dedektörü değildir

Daha sonraki bir olay, parça yükleme hatalarını yorumlama biçimimi değiştirdi.

Tarayıcı bir Next.js layout parçası için ChunkLoadError bildirdi; zenginleştirilmiş telemetride aynı anda şunlar da vardı:

resourceResponseStatus: 200
resourceDurationMs: 170523
serviceWorkerState: activated
chunkRecoveryScheduled: true

Kaydedilen süre yaklaşık 170 saniyeydi. O olayın tam kök nedeni ne olursa olsun, bu veri fazlasıyla basit bir kuralı reddetmeye yetiyordu:

ChunkLoadError === sunucu 404 döndürdü

Diğer parça hatalarında gözlenebilir yanıt durumu hiç yoktu. Bazıları zaman aşımı olarak geldi, bazılarında aktarım bilgisi vardı. Hata sınıfı aynıydı; çevresindeki kanıt değildi.

Next.js için bu özellikle önemlidir; çünkü /_next/static/ altındaki dosyalar genellikle içerik hash’i taşır ve immutable önbellekleme için tasarlanır. Güncel Next.js self-hosting belgeleri bu hash’lenmiş immutable varlıklar için uzun süreli cache header’larını açıklar. Dolayısıyla ChunkLoadError; dağıtım sürümü uyumsuzluğu, eski istemci, ağ teslimatı, ters proxy, CDN, önbellek, Service Worker veya gerçekten eksik bir derleme çıktısıyla ilgili olabilir.

Alarm katmanının neden uydurmasını istemiyorum. İnceleme için gerekli kanıtı korumasını istiyorum.

Medya hataları aynı dersi başka bir katmandan verdi

Bazı olaylarda medya öğesi şunu bildiriyordu:

MEDIA_ELEMENT_ERROR: Format error

Yalnızca bu mesaja bakınca codec uyumsuzluğu gibi görünüyor.

Ancak bazı olaylarda yaptığım ek teslimat kontrolü şunu gösterdi:

HTTP status: 410
Content-Type: text/html; charset=utf-8
failure kind: http

Tarayıcı video istedi, ancak HTML içeren bir HTTP hata yanıtı aldı. Medya öğesi HTML’i video olarak çözemediği için dışarıdaki belirti “Format error” oldu. Yararlı teşhis teslimat katmanındaydı.

Sorunu ilk gören katman, soruna neden olan katman olmak zorunda değildir.

“Codec arızası”, “ağ kesintisi”, “önbellek hatası” ve “eksik parça” sonuçtur. Telemetri önce gözlemleri kaydetmeli.

Tarayıcı arızalarını beş boyutta değerlendiriyorum

1. Sahiplik

Kaynak uygulamanın kendisi mi, framework/çalışma zamanı mı, harici entegrasyon mu, yoksa ortam mı?

2. Kullanıcı etkisi

Etkin rota, render, kimlik doğrulama, sohbet, ödeme veya başka bir temel akış bozuldu mu? Yoksa yalnızca isteğe bağlı reklam, analiz, ön yükleme veya önizleme başarısız olup sayfa kullanılabilir mi kaldı?

3. Kanıt kalitesi

Kendi koduma ait çağrı yığını, kaynak URL’si, HTTP durumu, derleme kimliği ve bileşen yığını var mı? Yoksa yalnızca 0:0 konumunda Script error. mı var?

4. Tekrar ve yayılım

Tek bir oturumdaki tek bir olay mı, yoksa aynı imza aynı sürümden sonra farklı kullanıcı, rota ve tarayıcılarda mı görülüyor?

5. Kurtarma

Uygulama kendiliğinden toparlandı mı? Parça yeniden yüklemesi planlandı mı? Yedek yol çalıştı mı? Kullanıcı hâlâ takılı mı?

net first-party
+ yüksek kullanıcı etkisi
+ güçlü kanıt
+ birden fazla session
+ recovery yok
= acil incident

third-party
+ opsiyonel fonksiyon
+ zayıf kanıt
+ izole olay
+ kullanıcı etkilenmedi
= metric veya düşük öncelik

Olayları bastırma politikası muhafazakâr olmalı

Gürültü rahatsız edici hâle gelince onlarca düzenli ifade yazıp can sıkan her şeyi atmak cazip gelir. Bu tehlikelidir.

Her AbortError olayını bastırırsam gerçekten iptal edilmiş API isteklerini gizleyebilirim. Her Script error. olayını silersem yalnızca toplandığında anlam kazanan tarayıcıya özgü bir kümeyi kaçırabilirim. Tüm üçüncü taraf hatalarını yok sayarsam bozuk ödeme, kimlik doğrulama veya onay sağlayıcısını gözden kaçırabilirim.

ALERT
→ müdahale gerektiren güçlü incident

RETAIN / AGGREGATE
→ sakla ve say; cluster oluştuğunda alert et

METRIC / SAMPLE
→ beklenen veya düşük etkili gürültü; trend ve örnekleri koru

Sistem sessizleşebilir ama körleşmemeli.

İyi bir sınıflandırıcı özünde koda yazılmış politikadır

Aşağıdaki kod üretim projemden kopyalanmış değil. Keşke baştan uygulamış olsaydım dediğim politikanın kısa bir örneği:

function classifyClientEvent(event) {
  const owner = classifyOwner(event);

  if (isExpectedMediaCancellation(event)) {
    return { severity: "metric", reason: "expected-cancellation" };
  }

  if (owner === "first-party" && breaksActiveRoute(event)) {
    return { severity: "alert", reason: "first-party-user-impact" };
  }

  if (isActiveFirstPartyChunkFailure(event)) {
    return { severity: "alert", reason: "application-chunk" };
  }

  if (owner === "third-party") {
    return { severity: "aggregate", reason: "integration-health" };
  }

  if (isOpaqueScriptError(event)) {
    return { severity: "aggregate", reason: "insufficient-evidence" };
  }

  return { severity: "aggregate", reason: "needs-correlation" };
}

Asıl zor iş breaksActiveRoute() gibi işlevlerin içindedir. Yalnızca istisna adı yeterli değildir; rota bağlamı, kaynağın sahipliği, hata sınırı verisi ve bazen ürüne özgü bilgi gerekir.

Parmak izi mesajı değil, olayı takip etmeli

Mesajların birebir eşitliğine göre yinelenenleri silmek kötü bir stratejidir. Minify edilmiş yığın ofsetleri derlemeyle değişir, parça hash’leri değişir, URL’lerde dinamik kimlikler bulunur ve tarayıcıların ifadeleri farklıdır.

{
  errorClass,
  normalizedFirstPartyResource,
  routeFamily,
  clientBuild,
  sessionId,
  shortTimeBucket
}

Uygulama genelinde çökmede kendi koduma ait en üst yığın çerçevesi daha yararlı olabilir. Parça hatasında normalize edilmiş parça kaynağı daha yararlıdır. Medya teslimatı olayında HTTP hata sınıfı ve medya rotası, tarayıcının dış hata mesajından daha değerli olabilir.

resource.error
→ ChunkLoadError
→ framework boundary
→ recovery scheduled

Böylece ilişkili olaylar dizisi dört gözlem içeren tek bir olaya dönüşebilir; dört ayrı acil arıza gibi görünmez.

Acil alarm kanalının görevi çok daha dar olmalı

Anlık alarmı şu durumlar için ayırırım: yararlı çağrı yığınıyla etkin rotayı bozan uygulamaya ait çalışma zamanı hatası; gerçek etkileşimi bozan React/Next.js hata sınırı; etkin rota için gereken uygulamaya ait JavaScript veya CSS’in yüklenmemesi; birden fazla oturum veya derlemede tekrarlayan ChunkLoadError; kullanıcıyı ilerleyemez hâle getiren temel API/veri hatası; ya da bozuk URL üretmek gibi kendi kodumun açık bir kuralını ihlal eden durum.

Tek bir belirsiz Script error., başarılı kurtarma olan uygulamaya ait kaynak hatası, kök katmanı henüz bilinmeyen medya hatası veya önce kümelenmesi gereken tarayıcıya özgü anomaliyi saklarım ama hemen alarm üretmem.

Genellikle metriklere veya örneklenmiş tanılamaya gönderirim: bilinen reklam/analiz kaynak hataları; beklenen medya AbortError iptalleri; yalnızca botlarda görülen üçüncü taraf hataları; güçlü çevrimdışı işareti olan arızalar; etkin rotayı etkilemeyen isteğe bağlı spekülatif kaynaklar.

Acil alarm, tarayıcı şikâyetlerinin ham sayısını değil, kullanıcı üzerinde eyleme dönüştürülebilir etkiyi temsil etmeli.

Tek bir toplam “hata sayısı” yerine olayları ölçmeyi tercih ederim

• Her 1.000 oturum başına uygulamaya ait olay sayısı;
• Derleme kimliğine göre etkilenen oturumlar;
• Rotaya göre hata sınırı olayları;
• Kaynak ve dağıtıma göre parça hataları;
• Sağlayıcıya göre harici entegrasyon hata oranı;
• Beklenen iptallerin hacmi; böylece ani artış yine görünür olur;
• Kurtarma başarı oranı;
• Benzersiz olay sayısı ile ham olay sayısını ayrı tutmak.

“Bir olay gerçekleşti” üretim alarmı için nadiren iyi bir eşiktir. “Yeni derlemede uygulamaya ait aynı olay artık birkaç bağımsız oturumu etkiliyor ve kurtarma da başarısız” çok daha anlamlı bir sinyaldir.

İstemci izleme tek başına kök nedeni kanıtlayamaz

Tarayıcı telemetrisinin açık sınırları vardır.

HTTP durumunun olmaması API’nin bu veriyi vermediği, tarayıcının alanı desteklemediği, originler arası kısıt olduğu, isteğin iptal edildiği veya gözlemlenebilirlikte başka bir boşluk bulunduğu anlamına gelebilir. Service Worker’ın etkin olması eski kaynağı onun döndürdüğünü kanıtlamaz. Dağıtımdan sonra ChunkLoadError görülmesi sürüm uyumsuzluğunu kanıtlamaz. online: true da originin erişilebilir olduğunu kanıtlamaz.

İstemci izleme olası nedenleri daraltır. Kök nedeni kanıtlamak için sunucu logları, ters proxy logları, dağıtım manifestleri, önbellek durumu ve gerçek yeniden üretim hâlâ gerekebilir.

Ayrıca gözlemlenebilirliğin sınırsız kullanıcı verisi toplamaya dönüşmesini istemiyorum. Her alan yalnızca arıza türlerini gerçekten ayırt etmeye yardımcı olduğu için var olmalı.

Daha iyi telemetri, daha fazla telemetri değildir; daha iyi ayrım yapan telemetridir.

Şimdiki kuralım: olayları topla, olayları incele, etkiye alarm ver

Başta raporlayıcının tek bir soruyu yanıtlamasını istiyordum: “Bir şey bozuldu mu?” Üretimde bu soru fazla geniş. Her zaman bir bot analitiğe ulaşamaz, gizlilik aracı reklamı engeller, medya Promise’ı bilerek iptal edilir, kullanıcı ağını kaybeder veya harici SDK kötü davranır.

Bizim mi?
Kullanıcı fonksiyon kaybetti mi?
Kanıt ne kadar güçlü?
Tekrar ediyor mu?
Uygulama toparlandı mı?
Bunlar birkaç event mi, tek incident mı?

İzlemeyi bu daha dar soruların etrafında kurunca kırmızı mesaj seli gürültü olmaktan çıkıp mühendislik aracına dönüştü.

Tarayıcı hatası bir gözlemdir. Olay, kullanıcı etkisinin ilişkilendirilmiş açıklamasıdır. Alarm ise artık bir insanın harekete geçmesi gerektiği kararıdır.

Bu üç kavramı artık eşanlamlı görmek istemiyorum.