Gece saat 2:17 ve birisi uygulamamın bozuk olduğunu söylüyor. Nasıl bozuk olduğu konusunda bir bilgi yok. Sadece beyaz bir sayfanın ekran görüntüsü ve “hey, şeyin öldü lol” yazıyor. Şimdi bir sunucuya SSH ile bağlanmış, tail -f storage/logs/laravel.log komutunu çalıştırıyor ve iç içe geçmiş binlerce satırlık karmaşayı incelemeye çalışıyorum. Uzun zamandır göz ardı ettiğim deprecation uyarıları, silmeyi unuttuğum bazı debug çıktıları ve içinde, muhtemelen, bu kişiye 500 hatası veren gerçek hatanın bulunduğu satırları arıyorum. Sonunda buluyorum. Eager load etmeyi unuttuğum bir ilişkideki null pointer. Bu, herhangi bir türde izleme ayarlamış olsaydım iki saniye alacak bir şey için on beş dakikalık bir günlük arkeolojisi oldu.
Bu da yaklaşık üç yıl önce oldu. Ertesi gün bunu düzelttim demek isterdim. Ama düzeltemedim.
Log::error() dönemi
Log::error() dönemiBunun yerine, muhtemelen sizin de yaptığınız gibi, stratejik yerlere Log::error() çağrıları serpiştirdim. 500 yanıtı aldığımda tetiklenen bir Slack webhook’u ayarladım. Kendime bunun izleme olduğunu söyledim.
Dürüst olmak gerekirse? Bu bir süre için işe yaradı.
Fakat sorun şu ki, Log::error('Bir şey yanlış gitti', ['user' => $user->id]) çağrısı yalnızca bir veri noktası verir. Ne olduğunu biliyorum, ancak ne sıklıkla olduğunu, isteğin gövdesinin nasıl göründüğünü, kullanıcının hatadan önce ne yaptığını veya bunun geçen Salı gördüğüm aynı hata mı yoksa yeni bir hata mı olduğunu bilmiyorum. Her hata bir adadır. Gruplama, trend yok, bağlam yok.
Bir kez 40 kez günde bir hata yaşadım. Bunun farkında değildim. Slack kanalım “500 hatası /dashboard’da” yazıyordu ve ben ah, o yine, bu hafta düzelteceğim diyordum. Görünüşe göre “o” aslında aynı rotayı etkileyen üç farklı hataydı ve bu hatalar, farklı kullanıcıları farklı şekillerde etkiliyordu. Ancak bir hafta boyunca günlükleri tarayıp grep yaptığımda bunu öğrendim. Eğlenceli bir gündü.
Sentry Sorusu
Sentry Sorusu
Sentry iyi bir yazılım. Aksi iddia etmeyeceğim.
Ancak bir Laravel yan projem için bunu ekiyorken — muhtemelen 100 aktif kullanıcısı olan bir proje — bir şey garip hissettirdi. SDK, pek çok şey getiriyor. Dashboard, ölçekli mikro hizmetler kullanan takımlar için tasarlandı ve ödediğim ücretlerin yarısı (performans izleme, oturum tekrar oynatma, sürüm izleme) aslında ihtiyacım olan şeyler değil. Fiyatlandırma katmanları, bir $29/aylık Digital Ocean droplet’ı yöneten birisi değil, risk sermayesi ile yanıp sönen bir girişimci olduğunuzu varsayıyor.
Laravel uygulamasında yerini alacak bir hata izleme istedim. Laravel ile ilişkilendirilmiş bir platform bağımsız bir araç değil. Kurulumun dakikalar içinde yapılabileceği bir şey, “bu 12 adımdan oluşan yapılandırma kılavuzunu takip et ve yapılandırma dosyasını yayınlamayı unutma ve kuyruk sürücüsünü ayarla…” değil.
Bu nedenle, bir tane geliştirdim. (Bu, kendimi tanıtma kısmı ama açıkçası, ona ihtiyacım olduğu için yaptım ve sizin de buna ihtiyacınız olabileceğini düşünüyorum.)
Gerçekten Kurulum
Gerçekten Kurulum
PHP hataları için iki adım:
composer require oopsy/oopsy-laravel
Sonra .env dosyanıza DSN’inizi ekleyin:
OOPSY_DSN=http://[email protected]/api/v1/projects/1
Hepsi bu kadar. Yapılandırma dosyası yayınlama yok, kaydedilecek middleware yok, manuel olarak eklenecek hizmet sağlayıcı yok. Paket otomatik olarak keşfeder ve kendini kaydeder. Uygulamanızda bir istisna oluştuğunda, tam yığın izini, kod bağlamıyla, istek verileri, kullanıcı bilgileri, ortamla birlikte yakalar ve Laravel’in Http::async() özelliğini kullanarak asenkron bir şekilde gönderir. Cevap süreleriniz değişmez. İzlenen uygulama asla yavaşlamaz ve kendisi yüzünden asla çökmez (bu, ironik olurdu).
JavaScript hataları için — ve burada en çok memnun kaldığım kısım — tek bir script etiketi ekliyorsunuz:
"https://your-oopsy.dev/api/v1/js/oopsy_pub_xxx.js">
Hiçbir npm yüklemesi yok. Hiçbir derleme adımı yok. Ön uç hattınıza 200KB’lık bir paket eklenmiyor. Bu, yakalanmamış istisnaları, işlenmemiş promise reddetmelerini ve breadcrumb’ları — tıklama olayları, konsol hataları, XHR ve fetch istekleri, gezinme değişiklikleri — kaydeden belirli bir proje için sunulan bağımsız bir script. Kapanmakta olan bir sekme olduğunda bile hatalar raporlandığı için sendBeacon kullanılıyor. Tüm bu şey belki birkaç kilobayt.
Breadcrumb kaydını doğru almak için utanç verici derecede fazla zaman harcadım. fetch ile ilgili bir kenar durumu var; globali monky-patch etmeniz gerekiyor ama aynı zamanda başkalarının monkey-patching işlemlerini de bozmayacak şekilde… ve bu başka bir blog yazısı.
Diğer Uçta Ne Görünüyor
Diğer Uçta Ne Görünüyor
Bir hata geldiğinde, parmak izi çıkartılması ve otomatik olarak gruplaması yapılır. Yani 500 kullanıcı aynı null pointer istisnasına hitap ettiğinde, 500 ayrı giriş değil, 500 olay sayısı olan bir sorun görüyorsunuz. Parmak izi, istisna sınıfı, dosya ve satır numarasına göre çalışır — ilk uygulama çerçevesi, vendor kodu değil — bu da olayları üzerinde düşündüğünüz şekilde gruplar.
Her sorun, tam yığın izini, çevresindeki kodu, bu hatayı tetikleyen HTTP isteğini, hangi kullanıcının etkilendiğini, önem seviyesini ve ortamı gösterir. JavaScript hatalarının bir JS rozeti vardır, böylece bir şeyin sunucu tarafında mı yoksa tarayıcıda mı patladığını hemen anlayabilirsiniz. Durum (çözülmemiş, çözüldü, göz ardı edildi), ciddiyet, kaynak ve ortamına göre filtreleyebilirsiniz.
Ayrıca e-posta ve Telegram bildirimleri de mevcut. Çünkü Laravel istisna izleme sistemi, sizi sabah 2’de uyandırmıyorsa, ne işe yarar ki? (şaka yapıyorum. Lütfen bildirim programınızı ayarlayın.)
Para Düşüncesi
Para Düşüncesi
Ücretsiz plan, bir proje için ayda 1.000 hata ve 7 günlük saklama süresi sunar. Bir yan proje için bu muhtemelen yeterlidir — eğer bir yan projede ayda 1.000’den fazla hata alıyorsanız, izleme dışında daha büyük sorunlarınız olabilir. Hobi planı, 30 günlük saklama süresi ile 5 proje için 50.000 hata ayda 5 dolardır; çoğu küçük üretim uygulaması burada yer alır. Eğer daha fazla ihtiyacınız varsa Pro planı 19 dolara çıkıyor, ama burada onu satmaya çalışmayacağım.
Özellikle istemediğim şey, hata hacminizi görünce diye düşündüren bir tür fiyatlandırmaydı. Laravel istisna izleme sistemi, her hatayı görmenizi istemeli, faturalardan korkmamanız için değil.
Neyse
Neyse
Size temiz bir sonuç sunmuyor. Hata izleme, bir şeyin gereksiz olduğu yaparken, bir anda olmaması gerektiği ana kadar, sonra da 2’de günlük dosyalarına bakarken kendinizi neden altı ay önce bir şey kurmadığınızı sorgularken bulduğunuz bir şey. Ben bu kişi oldum. Birden fazla kez.
İki satırlık yapılandırma. Gerçekten tüm satım bu.
Dan
Kaynak: Orijinal Makale


