Mimari ve çalışma modeli
Journald logları /run/log/journal altında volatile veya /var/log/journal altında persistent saklayabilir. Storage=auto, kalıcı dizin varsa diski; yoksa çalışma zamanı belleğini kullanır. Bu nedenle bir sunucuda reboot sonrası geçmiş görünürken aynı dağıtımın başka kurulumunda kaybolabilir. Etkin yapılandırmayı ve dizin varlığını birlikte okuyun.
RateLimitIntervalSec ve RateLimitBurst aşıldığında hizmet bazında ek mesajlar düşürülür ve bastırılan sayı için özet kayıt oluşur. Ayrıca SystemMaxUse, RuntimeMaxUse, KeepFree ve dosya sistemi doluluğu eski arşivlerin temizlenmesine yol açabilir. Uygulamanın hiç yazmaması, journald'ın mesaj düşürmesi ve retention temizliği farklı kök nedenlerdir.
journalctl --verify dosya bütünlüğünü denetler fakat uygulamanın beklenen her olayı ürettiğini kanıtlamaz. Uygulama sayaçları, bir test event-id ve journal cursor birlikte kullanılmalıdır. Merkezi log yönlendirmesi yerel journal'ın bağımsız yedeği değildir; ileri hedef kesintisinde kuyruk ve kayıp davranışı ayrıca tasarlanır.
- 1Uygulama stdout/syslog
- 2journald alımı ve rate limit
- 3Runtime veya persistent journal
- 4journalctl/forwarder
Tasarım parametreleri
- Storage
- persistent/volatile/auto seçimini reboot sonrası ihtiyaç ve disk bütçesiyle eşleyin.
- Boyut sınırı
- SystemMaxUse ile SystemKeepFree değerlerini gerçek /var kapasitesi ve diğer servis ihtiyaçlarıyla birlikte belirleyin.
- Rate limit
- Gürültülü servisin normal tepe hızını ölçün; limiti tamamen kapatmak yerine uygulama log fırtınasını düzeltin.
- Zaman ve cursor
- Boot ID, monotonic time ve cursor kullanarak reboot ile saat düzeltmesini sıradan veri kaybından ayırın.
Hesap ve uygulama örneği
Bir servis normalde 200 olay/saniye, hata anında 8.000 olay/saniye üretiyorsa 30 saniyelik pencerede 240.000 kayıt oluşabilir. Varsayılan/dağıtım limitleri bunun bir bölümünü bastırabilir. Önce hatanın benzersiz sayacını uygulamadan alın, sonra journal suppression mesajı ve disk kullanımını aynı zaman aralığında eşleyin.
Pilot doğrulamada logger ile event-id=doz-journal-001 yazın, cursor kaydedin, journald'ı flush edin ve kontrollü reboot yapın. Açılış sonrası cursor çevresinde olayı bulun. Bu test yalnız pilotta uygulanmalı; üretim reboot'u ayrı değişiklik onayı gerektirir.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
systemd-analyze cat-config systemd/journald.conf
journalctl --list-boots
journalctl --disk-usage
journalctl --verify
logger -t doz-journal 'event-id=doz-journal-001'
journalctl -t doz-journal -o short-iso-preciseHata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Reboot sonrası eski log yok | Storage volatile olabilir veya /var/log/journal oluşturulmamıştır. | systemd-analyze cat-config systemd/journald.conf, dizin ve boot listesini kontrol edin. |
| Yük altında saniyeler eksik | Rate limit ya da uygulama stdout pipe baskısı etkili olabilir. | Suppressed mesajlarını, servis log hızını ve uygulama sayaçlarını aynı pencerede karşılaştırın. |
| Journal beklenenden az gün tutuyor | SystemMaxUse, KeepFree veya harici vacuum çalışıyor olabilir. | journalctl --disk-usage, dosya sistemi boşluğu, timer ve config drop-in dosyalarını inceleyin. |
Kabul ve doğrulama kontrolleri
- Etkin Storage ve drop-in sırasını kaydedin.
- Test event-id'nin uygulamadan journal'a ulaştığını doğrulayın.
- Rate limit suppression olayını kontrollü pilotta üretin.
- Disk doluluğunda eski dosya silme davranışını ölçün.
- Reboot sonrası kalıcılığı ve boot sınırını kontrol edin.
- Merkezi forwarder kesintisinde yerel saklama davranışını sınayın.
İlgili kavramlar
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; log yokluğu, olay yokluğu şeklinde yorumlanmamalıdır.
Dosya sistemi ve depolama katmanları
Uygulama dizini, mount point, mantıksal disk ve fiziksel depolama aynı katman değildir. Boş alan kadar inode tükenmesi, read-only mount ve dosya sistemi hataları da yazmayı durdurabilir. Snapshot genellikle aynı depolama arızasını paylaşır ve bağımsız yedek sayılmaz. Mount seçenekleri ve kapasite genişletme yöntemi dosya sistemine göre değişir. İşletim sistemi yeniden açıldığında doğru depolamanın doğru dizine bağlandığını doğrulayın; mount edilmeyen dizine yazılan veri yanlış diski doldurabilir.
Kapasite ve kullanılabilir pay
Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.
Saklama politikası ve kapasite
Retention, hangi kurtarma noktalarının ne kadar süre tutulacağını tanımlar. Günlük, haftalık ve aylık noktalar aynı veri değişim oranını temsil etmez; tam kopya üretme şekli ve zincir bağımlılığı fiziksel kapasiteyi değiştirir. Saklama kararı, iş gereksinimi ve geçerli yükümlülükler ile teknik kapasitenin birlikte değerlendirilmesini gerektirir. Daha uzun saklama, otomatik olarak daha iyi kurtarma anlamına gelmez: doğru noktanın bulunması ve okunabilmesi gerekir. Politika değiştirildiğinde mevcut noktaların hemen silinip silinmediğini ürün davranışı üzerinden sınayın.
Servis yaşam döngüsü ve bağımlılıklar
Çalışan bir process, hizmetin kullanıcıya doğru yanıt verdiğini kanıtlamaz. Başlangıç sırası, ağ veya veritabanı bağımlılığı, ortam değişkenleri, dosya erişimi ve sağlık kontrolü birlikte incelenir. Servis yeniden başlatma döngüsü bazen gerçek nedeni gizler. Exit code, son loglar ve kaynak sınırlarını karşılaştırın. Uygulama dışında systemd veya container yönetim katmanının neden yeniden başlatma yaptığını da kaydedin. Kontrollü restart sonrasında oturum, veri yazma ve bağımlı servislerin davranışını doğrulayın.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve backup birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.