01Sorun ve çözüm
Observability altyapısı hizmetimizde metrikleri, logları ve dağıtık izleri aynı bağlamda toplayan bir yapı kuruyoruz. Uygulamalarınız OpenTelemetry ile enstrümante edilir, her isteğe bir iz kimliği atanır ve bu kimlik log satırlarına kadar taşınır. Böylece bir alarmdan ilgili ize, izden de o andaki log kayıtlarına birkaç tıklamayla geçilir.
Devamını okuDaha az göster
Kurulum kadar önemli olan, neyin ölçüleceğine karar vermektir. Kullanıcı deneyimini temsil eden hizmet seviyesi göstergelerini sizinle birlikte tanımlıyor, alarmları bu göstergelere bağlıyoruz; nöbetçiyi gece boşuna uyandıran gürültülü alarmlar ayıklanır.
02Kimler için
Observability altyapısı kimler için gerekli
Sistem büyüdükçe “sunucu ayakta mı” sorusu yetmez hâle gelir; bu noktaya gelmiş ekipler için.
- Birden fazla servisten oluşan ve bir hatanın hangi serviste başladığını bulmakta zorlanan yazılım ekipleri
- Kubernetes üzerinde çalışan, podları sık sık yeniden başlayan ama nedenini göremeyen platform ekipleri
- Ödeme, kargo ya da SMS gibi dış servislere bağımlı olan ve gecikmenin kaynağını kanıtlamak isteyen işletmeler
- Ticari bir izleme ürününün faturası veri hacmiyle birlikte büyüyen ve açık kaynak seçenekleri değerlendiren şirketler
- Kurumsal müşterilerine hizmet seviyesi taahhüdü veren ve bunu ölçümle raporlaması gereken SaaS firmaları
03İhtiyaçlar
Görünürlük eksikliğinin yol açtığı sorunlar
Sorun çoğu zaman araç eksikliği değil, toplanan verinin birbirine bağlanmamasıdır.
- 01
Birbirinden kopuk veriler
Metrikler bir panelde, loglar başka bir araçta, hata kayıtları üçüncü bir serviste durduğunda aynı olayın parçaları zaman damgasına bakılarak elle eşleştirilir. Olay anında bu eşleştirme en çok zamanı alan iştir.
- 02
Alarm yorgunluğu
Kaynak eşiklerine bağlı yüzlerce alarm, gerçek bir kesinti olduğunda önemli uyarının gözden kaçmasına yol açar. Kullanıcıyı etkileyen belirtilere bağlı az sayıda alarm çok daha işe yarar.
- 03
Kontrolsüz veri hacmi
Her isteğin ayrıntılı logunu tutmak ve yüksek kardinaliteli etiketlerle metrik üretmek depolama maliyetini hızla büyütür. Örnekleme, saklama katmanları ve log seviyesi politikası bu maliyeti dengeler.
- 04
Loglara sızan kişisel veri
Hata ayıklamak için loglanan istek gövdeleri kimlik numarası, telefon ya da adres gibi verileri log sistemine taşıyabilir. Bu verinin toplanma aşamasında maskelenmesi gerekir.
- 05
Ölçülemeyen hizmet seviyesi
Sistemin ne kadar erişilebilir olduğu ve isteklerin ne kadarının hızlı yanıtlandığı ölçülmüyorsa, yayın hızı ya da güvenilirlik yatırımı hakkında veriye dayalı karar verilemez.
04Özellikler
Observability altyapısı hizmetinin kapsamı
Kurulumu mevcut araçlarınız ve ekibinizin çalışma biçimi üzerine inşa ederiz.
- 01
Enstrümantasyon
Uygulamalara OpenTelemetry SDK'ları ya da otomatik enstrümantasyon ajanları eklenir; HTTP istekleri, veritabanı sorguları ve kuyruk mesajları iz olarak kaydedilir. Sepet onayı ya da fatura oluşturma gibi kritik iş adımları için özel span ve metrikler tanımlanır.
- 02
Toplama ve yönlendirme katmanı
OpenTelemetry Collector ile veriler tek noktadan toplanır, zenginleştirilir, filtrelenir ve hedef sistemlere yönlendirilir. Bu katman, ileride arka uç aracını uygulamalara dokunmadan değiştirmeyi mümkün kılar.
- 03
SLI, SLO ve alarm kuralları
Gecikme, hata ve erişilebilirlik için hizmet seviyesi göstergeleri ve hedefleri tanımlanır. Alarmlar hata bütçesinin tükenme hızına göre kurulur ve nöbet çizelgesine bağlanır.
- 04
Panolar ve olay sonrası analiz
Servis bazında panolar, bağımlılık haritası ve olay zaman çizelgesi hazırlanır. Olay sonrası değerlendirmede ihtiyaç duyulacak veri, saklama politikası sayesinde erişilebilir kalır.
- 05
Saklama ve maliyet politikası
Hangi verinin ne ayrıntıda ve ne kadar süre tutulacağı belirlenir; sıcak ve soğuk depolama katmanları, iz tamamlandıktan sonra karar veren (tail-based) örnekleme ve metrik toplulaştırma uygulanır.
05Entegrasyonlar
Observability altyapısında kullanılan araçlar
Açık kaynak ve ticari seçenekleri ihtiyacınıza, ekibinizin deneyimine ve bütçenize göre birlikte seçeriz.
- 01
Metrik toplama ve saklama
Prometheus; uzun süreli saklama için Mimir, Thanos ya da VictoriaMetrics. Bulutta Amazon CloudWatch, Azure Monitor veya Google Cloud Monitoring.
- 02
Log toplama
Loki, Elasticsearch ya da OpenSearch tabanlı yapılar; toplama ve maskeleme için Fluent Bit veya Vector.
- 03
Dağıtık iz takibi
Tempo ya da Jaeger ile iz depolama, izlerden metrik üretimi ve izlerle loglar arasında bağlantı.
- 04
Görselleştirme ve bildirim
Grafana panoları ve Alertmanager; bildirimler için Slack, Microsoft Teams, e-posta ve nöbet yönetim araçları.
- 05
Ticari platformlar
Datadog, New Relic, Elastic Observability ya da Dynatrace kullanıyorsanız mevcut yatırım korunur; veriyi OpenTelemetry ile toplamak ileride sağlayıcı değiştirmeyi kolaylaştırır.
06Süreç
Observability altyapısı hizmeti nasıl ilerler?
Adım 01
Analiz
İş akışınızı, kullanıcılarınızı ve mevcut sistemlerinizi dinleriz; kapsamı, öncelikleri ve kabul ölçütlerini yazılı hâle getiririz.
Adım 02
Tasarım
Ekran akışlarını ve veri modelini çıkarırız. Arayüzü sizinle gözden geçirip onay almadan geliştirmeye geçmeyiz.
Adım 03
Geliştirme
Kısa döngülerle çalışırız; her döngü sonunda çalışan bir sürümü test ortamında görürsünüz.
Adım 04
Test
İşlevsel testler, entegrasyon testleri ve temel güvenlik kontrolleriyle hataları yayından önce yakalarız.
Adım 05
Yayın
Sunucu, alan adı, yedekleme ve izleme ayarlarını yaparak canlıya alırız; ekibinize kısa bir kullanım eğitimi veririz.
Adım 06
Bakım
İsterseniz bakım ve destek anlaşmasıyla güncellemeleri, izlemeyi ve yeni geliştirmeleri sürdürürüz.
07Teknoloji
Observability altyapısında veri güvenliği ve dayanıklılık
Log ve iz verisi sistemin en ayrıntılı kaydıdır ve bu yüzden hassastır. Toplama katmanında kimlik, e-posta, telefon ve oturum anahtarı gibi alanlar maskelenir; log sistemine erişim ekip ve servis bazında rollerle sınırlanır. Kişisel veri içerebilecek kayıtların saklama süresi KVKK kapsamındaki ilkelere uygun biçimde belirlenir.
Devamını okuDaha az göster
İzleme sistemi, izlediği sistemle aynı anda çökmemelidir. Bu nedenle gözlem bileşenlerini mümkün olduğunca uygulama kümesinden ayrı çalıştırıyor, izleme sisteminin kendisini de dışarıdan basit bir erişilebilirlik kontrolüyle takip ediyoruz.
Panolar ve alarm kuralları konsolda elle değil, kod olarak sürüm kontrolünde tutulur. Yeni bir servis devreye alındığında standart pano ve alarm seti otomatik oluşur. Bakım ve destek anlaşmasında kural ayarını, kapasite takibini ve araç güncellemelerini üstlenebiliriz.
08Çalışma modelleri
Bu hizmette çalışma modelleri
- 01
Proje bazlı
Sabit kapsam, sabit fiyat ve belirli teslim tarihi
Kapsamı belli, teslim tarihi olan işler için.
- Yazılı kapsam ve kabul ölçütleri
- Sabit fiyat ve belirli teslim tarihi
- Teslim ve kabul adımları sözleşmede
- 02
Bakım ve destek
Aylık sözleşmeli, SLA'lı bakım, destek ve geliştirme saati
Yayındaki bir sistemin sürekliliği için.
- Aylık sözleşme ve SLA
- İzleme, güncelleme ve hata düzeltme
- Aylık geliştirme saati
- 03
Danışmanlık
Saatlik veya günlük teknik danışmanlık
Karar, denetim veya yön belirleme gereken durumlar için.
- Saatlik veya günlük çalışma
- Yazılı rapor ve öneriler
- Ekibinizle birlikte çalışma
09Sık sorulan sorular
Observability altyapısı hakkında sık sorulan sorular
Observability altyapısı fiyatları neye göre değişir?
Servis sayısı, günlük üretilen log ve metrik hacmi, saklama süresi, açık kaynak mı ticari platform mu kullanılacağı ve kurulum sonrası işletme desteği isteyip istemediğiniz belirleyicidir. Ticari araçların lisans ve kullanım bedelleri ayrıca faturalandırılır.
İzleme ile observability arasındaki fark nedir?
İzleme önceden bildiğiniz soruları yanıtlar: sunucu ayakta mı, disk doluyor mu. Observability ise öngörmediğiniz bir sorunun nedenini, metrik, log ve iz verisini birlikte sorgulayarak bulabilmenizi sağlar.
Uygulama kodumuzu değiştirmemiz gerekecek mi?
Birçok dil ve çatı için otomatik enstrümantasyon, kod değişikliği olmadan temel izleri üretir. İş adımlarına özgü ölçümler ve logların yapılandırılmış biçime getirilmesi için ise küçük kod değişiklikleri gerekir.
Mevcut Zabbix ya da ELK kurulumumuzu bırakmak zorunda mıyız?
Hayır. Çalışan bileşenler korunabilir; eksik olan katman, genellikle dağıtık iz ve veriler arası bağlantı, sonradan eklenir. Bir aracı değiştirmeyi ancak bakım yükü ya da maliyet açısından açık bir gerekçe varsa öneririz.
Observability altyapısı firması olarak alarmlara siz de müdahale ediyor musunuz?
Alarmların kurgulanması ve nöbet çizelgesinin araçlara bağlanması kurulum kapsamındadır. İlk müdahaleyi bizim yapmamızı istiyorsanız bu, bakım ve destek anlaşmasında müdahale koşullarıyla birlikte tanımlanır.
Bu altyapı kendi sunucularımızda mı, bulutta mı çalışır?
İkisi de mümkündür. Veri hacmi, saklama gereksinimi ve verinin yurt içinde kalma tercihi bu kararı belirler; yönetilen servis işletme yükünü azaltırken kendi kurulumunuz maliyet ve konum üzerinde daha fazla denetim sağlar.
10İlgili hizmetler