Entuity ile İşletim Sistemi Servis İzleme: Mimari ve Teknik Detaylar

Genel Servis İzleme Neden Yetersiz Kalır?

Klasik bir servis izleme yaklaşımı, bir servis adını (örneğin Tomcat) tüm ağdaki sunuculara karşı kontrol eder. Ancak bir ağda 100 sunucudan sadece 10'u gerçekten Tomcat çalıştırıyorsa, bu yaklaşım geri kalan 90 sunucuda anlamsız "servis çalışmıyor" event'leri ve incident'leri üretir. Entuity'nin mimarisi bu sorunu iki katmanlı bir filtreleme modeliyle çözüyor: Whitelist Kuralları ve View-Based Profiller.

Platform Bazlı İzleme Modelleri

Entuity, "OS Service" terimini kendi dahili servis kavramından (Entuity Services) ayırmak için özellikle kullanıyor. v20.0 P03'ten itibaren bu kapsam dört platforma yayılmış durumda:

Her platform kendi native servis yönetim modeliyle konuşuluyor; yani Entuity, Linux'ta Systemd'nin unit state modelini, Solaris'te ise SMF'nin kendi state makinesini baz alıyor — tek bir soyutlama katmanına zorlamıyor.

Yetkilendirme Mimarisi

İzin modeli iki seviyeli: kural yönetimi ve veri görüntüleme birbirinden ayrılmış.

• Kural Ynt.
  Kural Yönetimi Sadece Administrator rolü, OS Service Management sayfasına erişip whitelist kuralları oluşturabilir/düzenleyebilir.
• Görüntüleme
  Veri Görüntüleme Tüm kullanıcılar, oluşan Service State ve Service Status attribute'larını ve event'leri görebilir — kural yazma yetkisi olmadan.

Whitelist Kural Motoru

OS Service Management sayfası, izlenecek servis/sunucu kombinasyonları için bir filtreleme kuralı seti oluşturur. Bu, "her şeyi izle ve sonra gürültüyü ele" modeli değil, "sadece açıkça tanımlananı izle" modelidir — yani varsayılan olarak kapalı (Deny-By-Default), açıkça eklenen servisler izlenir. Bu tasarım tercihi, büyük ölçekli ortamlarda event gürültüsünü kaynağında önlemeyi hedefliyor.

View-Based Profiller: Hassas Hedefleme

v21.0 P03 ile gelen bu katman, whitelist'in üzerine ikinci bir filtreleme boyutu ekliyor. Mantık şöyle işliyor:

Sonuç: Tomcat kontrolü artık sadece gerçekten Tomcat barındıran 10 sunucuya uygulanıyor, diğer 90 sunucu bu kuraldan hiç etkilenmiyor. Bir cihazın birden fazla View'da ve dolayısıyla birden fazla profilde yer alabilmesi, karma ortamlarda (örneğin hem web hem veritabanı servisi barındıran bir sunucu) esneklik sağlıyor — bu Many-To-Many bir eşleştirme modeli.

Görselleştirme Katmanı: Dashboard Ve Dashlet Farkı

İki farklı görünüm, iki farklı kullanım senaryosuna hizmet ediyor:

• Dashboard
  OS Services Dashboard Tek bir sunucu odaklı — o sunucudaki tüm servisleri ve durumlarını listeler.
• Dashlet
  OS Services Dashlet Whitelist'e göre izlenen tüm servisleri tek tabloda gösterir; bir servise tıklamak o nesnenin Summary Dashboard'una götürür.

Programatik Yönetim: RESTful API

Kural yönetimi UI üzerinden olduğu kadar API üzerinden de yapılabiliyor — bu, kuralların IaC (Infrastructure As Code) benzeri bir yaklaşımla sürüm kontrollü şekilde yönetilmesine veya toplu sunucu deploy süreçlerine entegre edilmesine imkân tanıyor:

Mimari Tercihlerin Getirdiği Sonuç

Entuity'nin OS Service Monitoring'i üç tasarım kararının bileşimi olarak okunabilir: platforma özgü native izleme (soyutlama zorlamak yerine), Deny-By-Default whitelist (gürültüyü kaynağında kesmek için) ve View-Based profiller (hedefleme hassasiyeti için). Bu üçü birlikte, büyük ve heterojen sunucu filolarında "servis izleme" ifadesinin pratikte anlamlı ve yönetilebilir kalmasını sağlıyor.

Sıkça Sorulan Sorular