Zaman senkronizasyonu, çoğu ekipte “yürür gider” varsayımıyla bırakılır. Ta ki sertifika doğrulaması bozulana, Kerberos oturumları düşene, log korelasyonu şaşana veya dağıtık sistemlerde sıralama problemleri başlayana kadar. Üretimde saat hatası genelde birincil arıza değil; çok sayıda katmanı aynı anda etkileyen sessiz bir çarpandır.
Bu yazıda, Chrony ile kurumsal bir NTP hiyerarşisini nasıl kurduğumu ve özellikle drift/loss durumlarını nasıl alarm haline getirdiğimi anlatıyorum.
Neden Chrony?
Chrony, değişken ağ koşullarında ve VM/cloud gibi saat drift’inin yüksek olabildiği ortamlarda pratik avantaj sağlar. Benim için en kritik noktalar:
- Offset/drift’i daha iyi modelleyebilmesi
chronycile operasyonel gözlem kolaylığı- Sunucu/istemci modlarının net yönetimi
Mimari: tek katman değil, hiyerarşi
Kurumsal bir tasarımda en az üç katman düşün:
- Kaynak katmanı: Harici güvenilir zaman kaynakları (kurum politikasıyla)
- NTP core: İç ağda az sayıda, iyi korunan Chrony sunucuları
- İstemciler: Sunucular, cihazlar, cluster node’ları
Bu hiyerarşi iki problemi çözer: internet bağımlılığını azaltır ve istemcilerin “her biri dışarıya” çıkmasını engeller.
Core NTP sunucusu: örnek chrony.conf
Aşağıdaki örnek, temel bir “core” kurulum için iyi bir başlangıçtır (dağıtıma göre dosya yolu değişebilir):
# Upstream time sources
pool ntp.org iburst maxsources 4
# Local clock as last resort (ops kararına bağlı)
local stratum 10
# Allow only internal networks
allow 10.0.0.0/8
allow 192.168.0.0/16
# Hardening
cmdport 0
# Drift and logs
driftfile /var/lib/chrony/drift
logdir /var/log/chrony
log tracking measurements statisticsNotlar:
cmdport 0, Chrony’nin komut portunu kapatarak saldırı yüzeyini azaltır. Operasyon içinchronyckullanacaksan, bunu sadece yönetim ağından ve kontrollü biçimde açmayı tercih ederim.local stratum 10“her şey koptuğunda” stabilize eder; fakat yanlış kullanılırsa gerçek zamanı bozar. Kurumun risk iştahına göre karar ver.
İstemci konfigürasyonu: tek hedef, çok hedef mi?
İstemciler için iki yaklaşım var:
- Tek core hedefi: basit, ama core arızasında risk
- En az 2–3 core: daha güvenli, ama yönetimi biraz daha dikkat ister
İstemci örneği:
server ntp-core-1.example.local iburst
server ntp-core-2.example.local iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsyncmakestep 1.0 3: İlk üç senkron denemesinde 1 saniyeye kadar “step” düzeltmeye izin verir. Üretimde büyük sıçramalar için daha kontrollü politika gerekir, ama ilk boot senaryosunda hayat kurtarır.rtcsync: RTC ile daha stabil davranış sağlar (platforma bağlı).
Firewall ve segmentasyon
Minimum ağ kuralı:
- UDP/123 sadece istemci ağlarından core NTP’ye
- İnternete doğrudan NTP çıkışı istemcilerden kapalı
- Yönetim komutları (varsa) sadece yönetim segmentinden
Operasyon: Chrony sağlığı nasıl izlenir?
İki komut, incident anında hızlı durum verir:
chronyc tracking
chronyc sources -vtracking çıktısında özellikle:
Last offsetRMS offsetFrequencyLeap status
Buradan drift’in “yavaşça büyüyen” bir sorun mu, yoksa “kaynak kaybı” mı olduğunu anlayabilirsin.
Drift alarmı için pratik eşikler
Tek bir “doğru eşik” yok; ama aşağıdaki başlangıç seviyesinde işe yarar:
- Offset > 50ms: uyarı (bazı sistemler için daha düşük)
- Offset > 200ms: kritik (kimlik/sertifika etkileri başlayabilir)
- Source sayısı < 2: uyarı
Leap statusnormal değilse: kritik
Log korelasyonu: zaman hatası nasıl yakalanır?
Zaman sorunu çoğu zaman şu semptomlarla gelir:
- Sertifika hataları (mTLS/HTTPS)
- “token expired / not yet valid”
- Kerberos skew hataları
- Dağıtık loglarda “gelecekten gelen event”
Bu yüzden, SIEM/observability tarafında “clock skew” uyarısını sadece NTP metriğinden değil; uygulama error pattern’larından da korele etmek gerekir.
Sonuç
Chrony ile NTP’yi doğru hiyerarşiyle kurduğunda, saat senkronizasyonu “görünmez bir risk” olmaktan çıkar ve yönetilebilir bir servis haline gelir. Asıl farkı yaratan şey, konfigürasyon satırları değil; drift/loss durumlarını alarm ve runbook’a bağlamaktır. Üretimde güvenilirlik, çoğu zaman bu “küçük” servislerin doğru tasarlanmasıyla başlar.