- Log yönetimi bir kurulum değil, bir yönetim kararıdır
- Kaynak envanteri ve önceliklendirme
- Log politikası: ekipler arası sözleşme
- Saklama sınıfları ve maliyet sahipliği
- ELK mi, Loki mi, yönetilen hizmet mi?
- Erişim, sahiplik ve denetim
- Örnek: dağınık loglardan merkezi yapıya kademeli geçiş
- Mindset programlarında platform tarafı
- Sık sorulan sorular
Merkezi log yönetimini planlamak: politika, sahiplik ve platform seçimi
Merkezi log projeleri çoğu zaman araç kurulumuyla başlar, kurallar sonradan aranır. Hangi kaydın toplanacağını, ekiplerin hangi standarda uyacağını, kimin neyi göreceğini ve ELK ile Loki arasında nasıl seçim yapılacağını kurulumdan önce netleştirmeyi öğrenirsiniz.
Bir bakışta
- Merkezi log yönetimi bir kurulum değil, kurallar ve sahiplikle süren bir yönetim işidir. Araç kurulduğunda politika yoksa sonuç pahalı, gürültülü ve güvensiz bir kayıt yığınıdır.
- Log politikası, servis ekipleri ile platform ekibi arasındaki sözleşmedir. Seviyelerin anlamı, ortak alanlar, istek kimliği ve hassas veri yasağı burada yazılır.
- Her kayıt aynı süre ve aynı erişimle saklanmaz. Operasyonel, denetim ve hata ayıklama kayıtları ayrı saklama sınıflarına ayrılır.
- ELK ile Loki arasındaki seçim, arama biçimi ve işletme kapasitesine göre yapılır. Tam metin arama ve zengin analiz ELK'yi, etiketle süzme ve düşük işletme yükü Loki'yi öne çıkarır.
- Geçiş tek seferde değil, pilot servisten başlayarak kademeli yapılır. Pilotta politika denenir, kritik servislere ve tüm ekiplere sonra yayılır.
Log yönetimi bir kurulum değil, bir yönetim kararıdır
Birçok kurumda merkezi log projesi bir platform kurularak başlar: toplayıcılar dağıtılır, kayıtlar akmaya başlar, arayüz açılır. Bir süre sonra aynı sorunlar görünür: depolama beklenenden hızlı dolar, aynı alan her serviste başka adla geçer, bir uygulama parolaları loglamaya başlar, kimin hangi kaydı görebileceği belirsizdir. Bunların hiçbiri aracın eksikliği değil, kararların verilmemiş olmasıdır.
Merkezi log yönetimi dört kararın birlikte verilmesidir: hangi kaynakların toplanacağı (kapsam), kayıtların hangi kurallara uyacağı (politika), ne kadar ve kim tarafından erişilerek saklanacağı (saklama ve sahiplik) ve bunların hangi platformda işletileceği (platform). Toplayıcıların, ayrıştırma hattının ve indekslerin teknik kurulumu bu kararların uygulanmasıdır; kararlar verilmeden yapılan kurulum, sonradan yeniden yapılmak zorunda kalır.
Kaynak envanteri ve önceliklendirme
Planlamanın ilk adımı, log üreten kaynakların listesini çıkarmaktır. Her kaynak için üç soru sorulur: kaydın amacı ne (hata ayıklama, güvenlik izleme, yasal denetim), kaydın sahibi hangi ekip, kayıt bugün nerede tutuluyor? Tipik kaynak grupları şunlardır: • Uygulama kayıtları: servislerin ürettiği hata, uyarı ve bilgi kayıtları. • Erişim kayıtları: web sunucusu, ağ geçidi ve yük dengeleyici istek kayıtları. • Denetim kayıtları: kimin hangi veriye eriştiği ya da hangi yetkiyi değiştirdiği. • Altyapı kayıtları: işletim sistemi, konteyner platformu ve veritabanı kayıtları. • Güvenlik kayıtları: güvenlik duvarı, kimlik sağlayıcı ve uç nokta koruma kayıtları.
Envanter tamamlandığında önceliklendirme yapılır. Müşteriye dokunan kritik servisler ve yasal yükümlülük taşıyan denetim kayıtları önce gelir; değeri belirsiz, yüksek hacimli kayıtlar ise toplanmadan önce amacı sorgulanır.
Log politikası: ekipler arası sözleşme
Log politikası, servis ekiplerinin uyması gereken kuralları ve platform ekibinin sağlayacağı hizmeti birlikte tanımlar. Politikanın uzun bir belge olması gerekmez; önemli olan herkesin aynı kurala bakmasıdır. Tipik bir politika şunları içerir: • Seviyelerin anlamı: hata, uyarı, bilgi ve hata ayıklama seviyelerinin hangi durumda kullanılacağı. • Ortak alan sözlüğü: zaman damgası, servis adı, ortam ve istek kimliği gibi alanların tüm servislerde aynı adla bulunması. • Yapılandırılmış biçim: yeni servislerin kayıtları JSON gibi yapılandırılmış biçimde üretmesi. • Hassas veri yasağı: parola, kart bilgisi ve gereksiz kişisel verinin kayda hiç yazılmaması, yazılması kaçınılmazsa kaynakta maskelenmesi. • Zaman senkronizasyonu: tüm sunucuların saatinin aynı kaynaktan alınması. • Yeni servis kontrol listesi: bir servis merkezi yapıya bağlanmadan önce politikaya uyduğunun kontrol edilmesi.
Politika, platform ekibi tarafından tek başına yazılıp duyurulduğunda çoğu zaman uygulanmaz. Servis ekiplerinden temsilcilerle birlikte yazılması ve yeni servis açılış sürecine bağlanması, kuralın yaşamasını sağlar.
Saklama sınıfları ve maliyet sahipliği
Bütün kayıtları aynı süre ve aynı hızlı depolamada tutmak hem pahalı hem gereksizdir. Bunun yerine kayıtlar amaçlarına göre saklama sınıflarına ayrılır. Operasyonel kayıtlar sorun gidermede sık sorgulanır, kısa süre hızlı ortamda kalır. Denetim ve güvenlik kayıtları seyrek sorgulanır ama daha uzun saklanır ve değiştirilemez biçimde korunur. Hata ayıklama kayıtları yalnız gerektiğinde açılır ve en kısa süre tutulur. Sınıfların süreleri kurumun hukuk, güvenlik ve uyum ekipleriyle birlikte belirlenir; kişisel veri içeren kayıtlar gereğinden uzun tutulmaz.
Maliyetin görünür olması da yönetimin parçasıdır. Hangi servisin ne kadar kayıt ürettiğini ekip bazında gösteren düzenli bir rapor, ekiplerin gereksiz kaydı kendiliğinden azaltmasını sağlar. Maliyet görünmediğinde log hacmi kimsenin sorumluluğunda olmayan bir gidere dönüşür.
ELK mi, Loki mi, yönetilen hizmet mi?
Platform seçimi, politikadan sonra ve ihtiyaca göre yapılır. Elastic Stack (ELK) kayıt içeriğini indeksler; tam metin arama, ayrıntılı alan bazlı analiz ve güvenlik analitiği gereken yerlerde güçlüdür, ancak küme tasarımı ve işletimi deneyim ister. Grafana Loki ise kayıt içeriğinin tamamını değil yalnız etiketleri indeksler; depolama ve işletme yükü daha hafiftir, ama sorgular etiketlerle süzülerek yapıldığı için etiket tasarımı belirleyicidir ve yüksek kardinaliteli alanlar etiket yapılmaz. Kurum zaten Grafana ile izleme yapıyorsa Loki, metriklerle kayıtları aynı arayüzde ilişkilendirmeyi kolaylaştırır.
Üçüncü seçenek, bulut sağlayıcısının ya da bir hizmet şirketinin yönettiği log platformudur. İşletme yükü azalır; buna karşılık verinin hangi bölgede tutulduğu, hacimle artan maliyet ve sağlayıcıya bağımlılık ayrıca değerlendirilir. Hangi seçenek seçilirse seçilsin politika, saklama sınıfları ve erişim kuralları aynı kalır; değişen yalnız bunların hangi araçla uygulandığıdır.
Platformu arama biçimi ve işletme kapasitesi belirler
- Kayıt içeriğinde tam metin arama ve ayrıntılı analizELKKüme tasarımı ve işletimi için deneyimli ekip gerekir.
- Etiketle süzme, düşük işletme yükü, Grafana ile birlikte kullanımGrafana LokiEtiket tasarımı belirleyicidir; yüksek kardinaliteli alan etiket yapılmaz.
- Platformu işletecek ekip yokYönetilen log hizmetiVeri konumu, hacimle artan maliyet ve bağımlılık ayrıca değerlendirilir.
Erişim, sahiplik ve denetim
Merkezi yapıda kayıtlar tek yerde toplandığı için yanlış kişinin yanlış kayda erişme riski de tek yerde toplanır. Bu yüzden sahiplik üç role ayrılır. Platform ekibi altyapının çalışmasından, kapasiteden ve politikanın teknik uygulamasından sorumludur. Servis ekipleri kendi kayıtlarının içeriğinden, kalitesinden ve politikaya uyumundan sorumludur. Güvenlik ekibi ise denetim ve güvenlik kayıtlarının bütünlüğünü ve erişim kurallarını gözetir.
Erişim rol bazında verilir: ekipler varsayılan olarak yalnız kendi servislerinin kayıtlarını görür, denetim kayıtlarına erişim dar bir grupla sınırlanır. Kayıtlara kimin eriştiği de ayrıca kaydedilir. Hassas kayıtları ayrı bir indekste ya da ayrı bir kiracı alanında tutmak, yetki kurallarını yönetmeyi kolaylaştırır.
Örnek: dağınık loglardan merkezi yapıya kademeli geçiş
Örneğin kayıtların her sunucuda ayrı tutulduğu bir e-ticaret şirketi merkezi yapıya geçmeye karar veriyor. Önce kaynak envanteri çıkarılıyor ve ödeme servisi pilot olarak seçiliyor. Pilotta log politikasının taslağı uygulanıyor: ortak alanlar ekleniyor, istek kimliği ağ geçidinden başlayıp ödeme ve sipariş servislerine taşınıyor, kart bilgisi kaynakta maskeleniyor.
Pilot sırasında müşterilerin zaman zaman ödeme adımında hata aldığı bir olay yaşanıyor. İstek kimliği sayesinde ekip, aynı isteğin ağ geçidi, ödeme servisi ve veritabanı kayıtlarını tek sorguda sırayla görüyor ve sorunun bir zaman aşımından kaynaklandığını hızla buluyor. Bu sonuç, politikanın diğer ekiplere yayılmasında en ikna edici örnek oluyor. Ardından kritik servisler bağlanıyor, saklama sınıfları devreye alınıyor ve son aşamada tüm ekipler yeni servis kontrol listesine bağlanıyor.
Merkezi yapı pilot servisten başlayarak yayılır
- HazırlıkKaynak envanteriKaynaklar, amaçlar ve sahipler listelenir.
- TaslakLog politikasıOrtak alanlar, seviyeler ve hassas veri kuralları yazılır.
- PilotTek kritik servisPolitika ve istek kimliği gerçek trafikte denenir.
- YayılımKritik servislerSaklama sınıfları ve erişim kuralları devreye alınır.
- KalıcıTüm ekiplerYeni servis kontrol listesi açılış sürecine bağlanır.
Mindset programlarında platform tarafı
Platform kararı ELK'den yana çıkan ekipler için Elastic Stack (ELK) ile Merkezi Log Analizi eğitimi küme tasarımından güvenlik, erişim ve uyuma kadar uygulama tarafını çalışır.
Grafana ile izleme yapan ve Loki'yi seçen ekipler için Grafana Loki ile Log Toplama ve Sorgulama eğitimi etiket tasarımını, LogQL ile sorgulamayı ve ölçek ile maliyet konularını ele alır.
İlgili Mindset programı
Elastic Stack (ELK) ile Merkezi Log Analizi
Sık sorulan sorular
Log politikası kimin sorumluluğundadır?
Politikanın sahibi genellikle platform ya da altyapı ekibidir, ancak tek başına yazmaz. Servis ekiplerinden temsilciler, güvenlik ve uyum ekipleriyle birlikte hazırlanır. Uygulamanın sorumluluğu ise her servis ekibindedir; politikaya uymayan bir servisin merkezi yapıya bağlanmaması, kuralı uygulanabilir kılan en basit mekanizmadır.
Yönetilen bir log hizmeti kullanmak politikayı gereksiz kılar mı?
Hayır. Yönetilen hizmet platformun işletimini üstlenir, ama hangi kaydın toplanacağına, alanların nasıl adlandırılacağına, hassas verinin nasıl korunacağına ve kimin neyi göreceğine kurum karar verir. Politikasız kullanılan yönetilen hizmet, hacimle birlikte hızla artan bir faturaya dönüşebilir.
ELK ve Loki aynı kurumda birlikte kullanılabilir mi?
Kullanılabilir. Örneğin güvenlik ve denetim kayıtları tam metin arama gerektirdiği için ELK'de, yüksek hacimli uygulama kayıtları ise maliyet nedeniyle Loki'de tutulabilir. Bu durumda ortak alan sözlüğü iki platformda da aynı tutulur; aksi halde bir olayı iki sistem arasında izlemek zorlaşır.
Denetim kayıtları uygulama kayıtlarıyla aynı yerde tutulmalı mı?
Aynı platformda tutulabilir ama aynı kurallarla tutulmamalıdır. Denetim kayıtları değiştirilemez biçimde saklanır, erişimi dar bir grupla sınırlanır ve saklama süresi uyum gereksinimlerine göre belirlenir. Ayrı indeks ya da ayrı kiracı alanı kullanmak bu farklı kuralları uygulamayı kolaylaştırır.
Log hacmi beklenmedik biçimde artarsa ilk ne yapılmalı?
Önce artışın hangi servisten ve hangi seviyeden geldiği bulunur. Çoğu zaman neden, üretimde açık bırakılmış hata ayıklama seviyesi ya da hata döngüsüne girmiş tek bir servistir. Kısa vadede kaynakta süzme ya da örnekleme yapılır; kalıcı çözüm için ilgili ekip politikadaki seviye kurallarına göre kaydı düzeltir.
İlgili rehberler
İlgili eğitimler
Kategori: DevOps ve Bulut Teknolojileri