Hem genel (public) hem de özel (private) uç noktalar için bir API izleme stratejisi oluşturmak, bu iki API kategorisinin farklı tüketicilere, farklı arıza biçimlerine, farklı güvenlik kısıtlarına ve farklı izleme erişim gereksinimlerine sahip olduğunu kabul etmeyi gerektirir. Genel bir uç nokta, açık internet üzerinden harici kullanıcılara, iş ortaklarına veya müşteri uygulamalarına hizmet verir. Özel bir uç nokta ise bir ağ sınırının arkasındaki dahili mikroservislere, arka plan işçilerine, yönetim araçlarına veya altyapı bileşenlerine hizmet verir. Her ikisi de arızalandığında ciddi olaylara yol açabilir; ancak her birini izleme biçiminiz bu farklılıkları hesaba katmalıdır.
Çoğu ekip, müşteriler tarafından doğrudan görülebildikleri için işe genel API'lerini izleyerek başlar. Bu makul bir başlangıç noktasıdır, ancak tehlikeli bir kör nokta yaratır. Özel uç noktalar çoğu zaman genel uç noktaların dayandığı yükü taşır. Arızalı bir dahili kimlik doğrulama servisi, yavaş bir veritabanı ağ geçidi, bozuk bir servisler arası iletişim yolu veya performansı düşmüş bir mesaj kuyruğu API'si, genel uç noktaların kendisi teknik olarak erişilebilir olsa bile tüm genel yüzeyi çökertebilir. Eksiksiz bir izleme stratejisi her iki katmanı da kapsar; çünkü güvenilirlik yalnızca görünen kenara değil, zincirin tamamına bağlıdır.
Genel ve Özel Uç Noktalar Neden Farklı İzleme Yaklaşımları Gerektirir?
Temel fark, API'yi kimin tükettiği ve ona nasıl ulaştığıdır.
Genel uç noktalara harici istemciler internet üzerinden DNS çözümlemesi, CDN yönlendirmesi, yük dengeleyiciler ve TLS sonlandırma aracılığıyla erişir. Bu uç noktalar öngörülemeyen trafik desenleri, kötüye kullanım girişimleri, coğrafi çeşitlilik ve istemci ile sunucu arasındaki tüm ağ koşullarıyla karşı karşıyadır. Bu faktörlerin herhangi biri deneyimi etkileyebileceğinden izleme hepsini hesaba katmalıdır.
Özel uç noktalara ise kontrollü bir ağ ortamındaki dahili servisler erişir. Bunlar genellikle servis keşfi, dahili DNS ve özel ağ kullanır; çoğu zaman TLS'i atlar ya da kimlik doğrulama için karşılıklı TLS (mutual TLS) kullanır. Trafik desenleri daha öngörülebilirdir, ancak arıza biçimleri farklıdır: servis mesh yanlış yapılandırmaları, konteyner orkestrasyonu sorunları, dahili DNS arızaları ve bağımlılık grafiği boyunca yayılan zincirleme zaman aşımları.
Her iki türü aynı şekilde ele alan bir izleme stratejisi, özel uç noktaları gereksiz harici kontrollerle aşırı izler ya da dahili ağlara ulaşamayan aynı harici yoklayıcılara güvenerek yetersiz izler. Doğru yaklaşım, her tür için izlemeyi erişim modeline, risk profiline ve operasyonel önemine göre tasarlamaktır.
Adım 1: API Ortamınızı Haritalayın ve Sınıflandırın
İzlemeyi kurmadan önce mevcut olanın net bir envanterine ihtiyacınız vardır. Büyüyen kuruluşların çoğu, birden fazla servise, ortama ve ağ sınırına yayılmış, farkında olduklarından çok daha fazla API uç noktasına sahiptir.
Erişime Açıklık Düzeyine Göre Sınıflandırın
Her API uç noktasını aşağıdaki kategorilerden birine yerleştirerek başlayın:
- Genel harici: Kimlik doğrulama olmadan internetteki herkes tarafından erişilebilir. Pazarlama sayfaları, genel dokümantasyon API'leri, durum uç noktaları.
- Genel kimlik doğrulamalı: İnternet üzerinden erişilebilir ancak kimlik doğrulama gerektirir. Müşteriye yönelik ürün API'leri, iş ortağı entegrasyonları, mobil uygulama arka uçları.
- Özel dahili: Yalnızca dahili ağ veya VPC içinden erişilebilir. Mikroservisler arası iletişim, dahili yönetim API'leri, arka plan iş işlemcileri.
- Özel altyapı: Platformu destekleyen düşük seviyeli altyapı API'leri. Veritabanı proxy'leri, önbellek katmanları, mesaj kuyruğu arayüzleri, servis mesh kontrol düzlemleri.
Her kategorinin farklı izleme gereksinimleri, farklı kabul edilebilir gecikme eşikleri, farklı kimlik doğrulama yönetimi ve farklı sahiplik yapıları vardır.
İş Etkisine Göre Sınıflandırın
Her erişim kategorisi içinde uç noktaları iş etkisine göre sıralayın. Ödemeleri işleyen genel kimlik doğrulamalı bir API, pazarlama içeriği sunan genel bir uç noktadan daha kritiktir. Kimlik doğrulama token doğrulamasını yürüten dahili bir API, haftalık rapor üreten dahili bir API'den daha kritiktir. İş etkisi; izleme sıklığını, alarm önem derecesini ve SLO hedeflerini belirler.
Erişim sınıflandırması ile iş etkisinin birleşimi, tüm stratejiye yön veren bir izleme öncelik matrisi oluşturur.
Adım 2: Genel Uç Noktalar İçin İzleme Tasarlayın
Genel uç noktalar, onları tüketen kullanıcıların bakış açısından, yani harici olarak izlenmelidir. Bu, sentetik kontrollerin kullanıcı tabanınızla eşleşen coğrafi konumlardan, açık internet üzerinden ve gerçek trafiğin izlediği aynı DNS, CDN ve yük dengeleme yolundan çalıştırılması anlamına gelir.
Harici Sentetik Kontroller
Her kritik genel uç nokta için şu özelliklere sahip sentetik HTTP kontrolleri yapılandırın:
- DNS'i çözümleyip bağlantıları genel yol üzerinden kuran
- istemcilerin gönderdiğiyle eşleşen gerçekçi kimlik doğrulama (API anahtarları, OAuth token'ları, JWT'ler) kullanan
- durum kodlarını, yanıt süresini ve yanıt gövdesi içeriğini doğrulayan
- birden fazla coğrafi bölgeden 30 saniye ile 2 dakika arasındaki aralıklarla çalışan
- gerçek istemcilerin kullandığı aynı HTTP yöntemleri ve istek gövdeleriyle test eden
Bu harici bakış açısı vazgeçilmezdir; çünkü dahili sağlık kontrolleri genel teslimat yolundaki sorunları tespit edemez. Bir DNS yanlış yapılandırması, bir CDN önbellek hatası, bir yük dengeleyici sağlık kontrolü uyuşmazlığı veya bir TLS sertifikası sorunu ağın içinden görünmez olur, ancak harici izleme tarafından tamamen görülür.
Tüketici Deneyimini İzleyin
Genel API izlemesi, sunucunun ne sunduğunu düşündüğünü değil, tüketicinin ne deneyimlediğini ölçmelidir. Buna DNS çözümleme süresi, TLS el sıkışma süresi, ilk bayta kadar geçen süre (TTFB) ve toplam yanıt süresi dahildir. Bu katmanlardan herhangi biri yavaşsa, uygulama işleme hızlı olsa bile tüketici deneyimi kötüleşir.
Mobil istemciler tarafından tüketilen API'ler için gecikme eşikleri, mobil bağlantıların getirdiği ek ağ değişkenliğini hesaba katmalıdır. İş ortağı entegrasyonları tarafından tüketilen API'ler için izleme, hız sınırı başlıklarının, sayfalamanın ve hata yanıtı biçimlerinin belgelenmiş sözleşmeye uygun olduğunu doğrulamalıdır.
Hız Sınırlarını ve Kötüye Kullanım Desenlerini Takip Edin
Genel uç noktalar, dahili uç noktaların karşılaşmadığı trafikle karşı karşıyadır: bot taramaları, kimlik bilgisi doldurma (credential stuffing), veri kazıma ve kazara oluşan istemci döngüleri. İzleme, hız sınırlamanın doğru çalışıp çalışmadığını ve olağandışı trafik desenlerinin meşru kullanıcıları etkileyip etkilemediğini takip etmelidir. Çok agresif bir hız sınırı gerçek kullanıcıları engeller. Çok gevşek bir hız sınırı ise herkes için performansı düşüren kötüye kullanıma izin verir.
Genel Uç Noktalar İçin SLO'lar
Genel uç nokta SLO'ları, tüketicilere verilen deneyim taahhüdünü yansıtmalıdır. API dokümantasyonu %99,9 erişilebilirlik hedefi ve 500 ms altı yanıt süresi belirtiyorsa, izleme bu belirli taahhütleri ölçmeli ve bunlara göre raporlamalıdır. Sözleşmeye dayalı SLA'ları olan iş ortağına yönelik API'ler için izleme verileri, uyumluluk raporlamasının kanıtı hâline gelir.
Genel SLO'lar genellikle özel SLO'lardan daha sıkı hedeflere ihtiyaç duyar; çünkü harici tüketicilerin arızalara toleransı daha düşüktür ve bunları anlamak için daha az bağlama sahiptirler. Dahili bir servis otomatik olarak yeniden deneyebilir. Harici bir mobil uygulama ise kullanıcıya hemen bir hata ekranı gösterebilir.
Adım 3: Özel Uç Noktalar İçin İzleme Tasarlayın
Özel uç noktalar, harici izleme yoklayıcılarından erişilemedikleri için farklı bir izleme yaklaşımı gerektirir. İzleme altyapısının, bu servislerin iletişim kurduğu dahili ağa erişimi olmalıdır.
Dahili İzleme Yoklayıcıları
En yaygın yaklaşım, izleme ajanlarını veya sentetik kontrol yürütücülerini özel ağın içinde çalıştırmaktır. Bu yoklayıcılar, üretim servislerinin kullandığı aynı servis keşfi, dahili DNS ve kimlik doğrulama mekanizmalarını kullanarak dahili uç noktalara istek gönderir.
Kubernetes ortamlarında izleme yoklayıcıları, küme içinde pod olarak çalışabilir ve servislere dahili servis adları ve küme DNS'i üzerinden erişebilir. VPC tabanlı mimarilerde izleme ajanları, uygun güvenlik grubu erişimiyle VPC içinde çalışır. Hibrit ortamlarda yoklayıcıların birden fazla ağ bölgesinde çalışması gerekebilir.
Yoklayıcı, uç noktanın üretimde gerçekte nasıl çağrıldığını taklit etmelidir. Servisler karşılıklı TLS kullanan bir servis mesh üzerinden iletişim kuruyorsa, izleme yoklayıcısı da aynı kimlik doğrulama yolunu kullanmalıdır. Servisler kısa TTL'li dahili DNS üzerinden çözümleniyorsa, yoklayıcı da aynı şekilde çözümlemelidir. İzleme yolu üretim yoluna ne kadar yakın olursa, gerçek davranışı o kadar doğru temsil eder.
Servisler Arası Bağımlılıkları İzleyin
Özel uç nokta izlemesi, büyük ölçüde servisler arasındaki bağımlılık ilişkilerine odaklanmalıdır. Bir mikroservis mimarisinde tek bir kullanıcı isteği 5 ila 15 dahili API çağrısından geçebilir. Bu zincirin herhangi bir noktasındaki arıza veya performans düşüşü nihai yanıtı etkiler.
Bağımlılık farkındalığına sahip izleme, bu ilişkileri haritalar ve her dahili API'nin performansını ve erişilebilirliğini bağımsız olarak takip eder. Genel yüzeyde bir olay meydana geldiğinde bu dahili görünürlük, ekiplerin tüm zinciri manuel olarak incelemek yerine kök nedenin hangi dahili servis olduğunu hızla belirlemesine yardımcı olur.
Dahili Gecikme Bütçelerini Takip Edin
Her genel API yanıtı, dahili servis çağrılarında geçen süreyi içerir. Genel SLO 500 ms'lik bir yanıt gerektiriyorsa ve istek üç dahili servisten geçiyorsa, her servisin örtük bir gecikme bütçesi vardır. Dahili servislerden biri 500 ms'lik bütçenin 400 ms'sini tüketiyorsa, hiçbir dahili kontrol başarısız olmamış olsa bile genel SLO zaten risk altındadır.
Dahili uç noktaları genel SLO bütçesinden türetilmiş gecikme eşikleriyle izlemek, dahili performans düşüşünün harici deneyimi bozmadan önce tespit edilmesini sağlar. Bu bütçe tabanlı yaklaşım, her dahili servisi tek başına izlemekten daha etkilidir; çünkü dahili performansı gerçekten önemli olan sonuca bağlar.
Özel Uç Nokta İzlemesinde Kimlik Doğrulamayı Yönetin
Dahili API'ler çoğu zaman genel API'lerden farklı kimlik doğrulama mekanizmaları kullanır. Servisten servise iletişimde karşılıklı TLS, dahili JWT token'ları, servis hesabı kimlik bilgileri, dahili kullanıma özel API anahtarları ya da ağ sınırı güvenilir kabul ediliyorsa hiç kimlik doğrulama kullanılmayabilir.
İzleme yoklayıcılarının dahili kimlik doğrulama modeliyle eşleşen kimlik bilgilerine ihtiyacı vardır. Bu kimlik bilgileri, üretim servisi kimlik bilgileriyle aynı güvenlik uygulamalarıyla yönetilmelidir: düzenli olarak döndürülmeli, gereken asgari izinlerle sınırlandırılmalı ve gizli anahtar yönetim sistemlerinde saklanmalıdır. Aşırı geniş izinlere veya eskimiş kimlik bilgilerine sahip bir izleme yoklayıcısı hem güvenlik riski hem de izleme güvenilirliği riski yaratır.
Özel Uç Noktalar İçin SLO'lar
Özel uç nokta SLO'ları, bu uç noktaların genel hizmet seviyelerine katkısından türetilmelidir. Dahili bir kimlik doğrulama servisi her kullanıcı isteğinde çağrılıyorsa ve genel API'nin %99,9 erişilebilirlik SLO'su varsa, dahili kimlik doğrulama servisinin en az o kadar sıkı bir erişilebilirlik hedefine ihtiyacı vardır; çünkü arızaları doğrudan genel yüzeye yayılır.
Birden fazla genel uç nokta tarafından çağrılan dahili servisler için SLO, en yüksek kritikliğe sahip tüketiciye göre belirlenmelidir. Hem ödeme (checkout) API'sini hem de haftalık rapor üreticisini besleyen dahili bir veri servisinin SLO'su, rapor güvenilirliğine değil ödeme güvenilirliğine göre hizalanmalıdır.
Adım 4: Her İki Katmanda Birleşik Görünürlük Oluşturun
Hem genel hem de özel uç noktaları izlemenin en değerli sonucu, sinyalleri her iki katman arasında ilişkilendirebilme yeteneğidir. Genel bir API olayı meydana geldiğinde ekip, kök nedenin genel teslimat yolunda mı yoksa dahili bir bağımlılıkta mı olduğunu hemen görebilmelidir.
Birleşik Gösterge Paneli Tasarımı
İzleme gösterge paneli katmanlı bir görünüm sunmalıdır. Üst katman, harici kullanıcıların deneyimlediği şekliyle genel uç nokta sağlığını gösterir: erişilebilirlik, gecikme ve hata oranları. İkinci katman dahili uç nokta sağlığını gösterir: servisler arası iletişim, veritabanı erişimi ve altyapı API durumu. Katmanlar arasındaki ilişki görünür olmalıdır; böylece genel bir uç noktanın performansı düştüğünde ekip, herhangi bir dahili bağımlılığın da etkilenip etkilenmediğini kontrol edebilir.
Renk kodlu durum göstergeleri, bağımlılık okları veya yan yana karşılaştırma panelleri hızlı görsel ilişkilendirmeye yardımcı olur. Amaç, nöbetçi mühendisin tek bir ekrana bakarak sorunun harici teslimatta mı, dahili servislerde mi yoksa her ikisinin birleşiminde mi olduğunu anlayabilmesidir.
İlişkilendirilmiş Alarmlar
Alarm tasarımı, genel ve özel uç noktalar arasındaki ilişkiyi yansıtmalıdır. Genel bir API alarmı, dahili bir bağımlılık alarmıyla aynı anda tetiklenirse, alarm sistemi iki ayrı alarm akışı üretmek yerine bu olayları ilişkilendirmelidir. Müdahale eden kişinin, zihninde birleştirmesi gereken iki ilgisiz alarm değil, her iki sinyali içeren tek bir olay görmesi gerekir.
Bu ilişkilendirme, müdahale süresini önemli ölçüde kısaltır; çünkü müdahale eden kişi tüm tabloyu hemen anlar: genel ödeme API'si, dahili ödeme işleme servisi hata döndürdüğü için başarısız olmaktadır. İlişkilendirme olmadan müdahale eden kişi, dahili kök nedeni keşfetmeden önce genel API'yi incelemek için 10 dakika harcayabilir.
Ortak Olay Zaman Çizelgesi
Olaylar her iki katmanı da içerdiğinde, olay zaman çizelgesi genel ve özel izlemeden gelen olayları içermelidir. 14:02'de DNS değişikliği tespit edildi. 14:03'te dahili veritabanı API gecikmesinde ani artış. 14:04'te genel ödeme API'si hataları başladı. Bu zaman çizelgesi, ekiplerin nedenselliği ve sıralamayı anlamasına yardımcı olur; bu da hem gerçek zamanlı müdahale hem de olay sonrası inceleme için vazgeçilmezdir.
Adım 5: Güvenlik ve Uyumluluk Konularını Ele Alın
Hem genel hem de özel uç noktaları izlemek, stratejide ele alınması gereken güvenlik konularını beraberinde getirir.
İzleme Kimlik Bilgilerini Koruyun
Hem genel hem de özel uç noktalar için izleme yoklayıcıları kimlik doğrulama bilgileri kullanır. Bu kimlik bilgileri güvenli şekilde saklanmalı, planlı olarak döndürülmeli ve izleme için gereken asgari izinlerle sınırlandırılmalıdır. Genel bir API için ele geçirilmiş bir izleme kimlik bilgisi yazma erişimi sağlamamalıdır. Dahili bir yoklayıcı için ele geçirilmiş bir kimlik bilgisi üretim verilerini açığa çıkarmamalıdır.
İzleme Trafiğini Ayırın
Hassas ortamlarda izleme trafiği tanımlanabilir ve üretim trafiğinden ayrılabilir olmalıdır. Bu, özel izleme user agent'ları, ayrı API anahtarları veya ağ seviyesinde etiketleme ile sağlanabilir. Bu ayrım, izleme etkinliğinin üretime müdahale etmemesini ve güvenlik ekiplerinin izleme isteklerini potansiyel olarak şüpheli trafikten ayırt edebilmesini sağlar.
İzleme Erişimini Denetleyin
Uyumluluk gereksinimlerine tabi kuruluşlar için özel uç noktalara izleme erişimi belgelenmeli ve denetlenebilir olmalıdır. Hangi yoklayıcıların hangi dahili servislere erişimi olduğu, hangi kimlik bilgilerini kullandıkları ve hangi verileri okuyabildikleri güvenlik ve uyumluluk duruşunun bir parçası olmalıdır. İzleme bir tür otomatik erişimdir ve buna göre yönetilmelidir.
Dahili Yoklayıcılar İçin Ağ Güvenliği
Dahili izleme yoklayıcılarının özel uç noktalara ağ erişimine ihtiyacı vardır, ancak bu erişim kısıtlanmalıdır. Yoklayıcılar tüm dahili ağa değil, yalnızca izlemek üzere yapılandırıldıkları uç noktalara ulaşabilmelidir. Güvenlik grubu kuralları, ağ politikaları veya servis mesh yetkilendirmesi, yoklayıcı erişimini gereken asgari kapsamla sınırlamalıdır.
Adım 6: Sahipliği ve İnceleme Sıklığını Belirleyin
Hem genel hem de özel uç noktaları kapsayan bir izleme stratejisi birden fazla ekibi içerir. Genel API'ler ürün mühendisliği, platform ekipleri veya geliştirici deneyimi ekiplerine ait olabilir. Özel API'ler arka uç mühendisliği, altyapı ekipleri veya bağımsız mikroservis sahiplerine ait olabilir. İzleme stratejisi, her katmandan kimin sorumlu olduğunu tanımlamalıdır.
Uç Nokta Sahipliğini Atayın
İzlenen her uç noktanın, izleme yapılandırmasını sürdürmekten, alarmlara yanıt vermekten ve performans eğilimlerini incelemekten sorumlu belirlenmiş bir sahibi olmalıdır. Genel uç noktalarda sahiplik genellikle tüketici deneyimini yöneten ürün ekibiyle örtüşür. Özel uç noktalarda ise sahiplik, kodu ve altyapıyı sürdüren servis ekibiyle örtüşür.
Katmanlar Arası İncelemeler Yapın
Üç ayda bir yapılan bir inceleme, izleme kapsamını, alarm kalitesini, SLO uyumunu ve eksiklikleri değerlendirmek için genel ve özel uç nokta sahiplerini bir araya getirmelidir. Bu katmanlar arası inceleme, izleme stratejisinin mimari değiştikçe gelişmesini sağlar. Yeni servisler, kullanımdan kaldırılan uç noktalar, değişen bağımlılıklar ve kayan trafik desenleri, izleme güncellemeleri gerektirir.
Canlı Bir İzleme Envanteri Tutun
Adım 1'de oluşturulan uç nokta envanteri, servisler eklendiğinde, değiştirildiğinde veya kullanımdan kaldırıldığında güncellenen canlı bir belge olmalıdır. Kullanımdan kaldırılmış uç noktaları kontrol eden eskimiş izleme gürültü yaratır. Yeni uç noktalarda eksik izleme kör noktalar yaratır. Servis kataloğu ile izleme yapılandırması arasında düzenli bir mutabakat her iki sorunu da önler.
Çift Katmanlı API İzlemesinde Sık Yapılan Hatalar
Ekipler genel ve özel uç noktaları kapsayan izleme stratejileri oluştururken bazı hatalar tekrar tekrar karşımıza çıkar.
Birincisi, yalnızca genel uç noktaları izlemek ve dahili sağlığın bundan anlaşılacağını varsaymaktır. Dahili servisler, performans düşüşü bir eşiği aşıp ani bir genel arızaya yol açana kadar genel metriklerde hemen görünmeyen şekillerde bozulabilir.
İkincisi, dahili uç noktalar için harici izleme yoklayıcıları kullanmaktır. Harici yoklayıcılar özel ağlara ulaşamaz ve dahili uç noktaları harici izlemeye açmaya çalışmak, hiçbir operasyonel fayda sağlamadan güvenlik riski yaratır.
Üçüncüsü, her iki katmana aynı eşikleri uygulamaktır. Genel ve özel uç noktaların farklı performans özellikleri ve farklı kabul edilebilir gecikme aralıkları vardır. 50 ms'lik bir dahili servis çağrısı ile 300 ms'lik bir genel API yanıtı, aynı istek zincirinin parçası olsalar bile farklı izleme eşiklerine sahip olmalıdır.
Dördüncüsü, izleme yoklayıcıları için kimlik bilgisi yönetimini ihmal etmektir. Süresi dolmuş izleme kimlik bilgileri, izleme sistemine olan güveni zedeleyen yanlış kesinti alarmlarına neden olur. İzleme için kimlik bilgisi yaşam döngüsü yönetimi otomatikleştirilmeli ve düzenli olarak gözden geçirilmelidir.
Beşincisi, her katman için ayrı, birbirinden kopuk izleme sistemleri kurmaktır. Genel ve özel izleme, aralarında hiçbir ilişkilendirme olmayan farklı araçlarda yer alıyorsa ekip en değerli faydayı kaybeder: olayları katmanlar arasında izleyebilme ve kök nedenleri hızla belirleyebilme yeteneği.
Son Düşünceler
Genel ve özel uç noktalar için bir API izleme stratejisi oluşturmak, bu iki kategorinin farklı tüketicilere hizmet ettiğini, farklı risklerle karşılaştığını ve farklı izleme erişim yöntemleri gerektirdiğini, ancak güvenilirliklerinin birbirine derinden bağlı olduğunu anlamayı gerektirir.
Genel uç noktalar; coğrafi çeşitlilik, gerçekçi kimlik doğrulama, yanıt doğrulaması ve harici beklentilerle eşleşen SLO'larla, tüketicinin bakış açısından harici olarak izlenmelidir. Özel uç noktalar ise üretim iletişim desenlerini taklit eden yoklayıcılar, genel SLO'lardan türetilmiş gecikme bütçeleri ve dahili sağlığı harici sonuçlara bağlayan bağımlılık farkındalıklı görünürlük ile dahili olarak izlenmelidir.
Strateji, her iki katman ilişkilendirilmiş gösterge panelleri, bağlantılı alarmlar ve ortak olay zaman çizelgeleriyle birleştirildiğinde en güçlü hâline ulaşır. Bu birleşik görünürlük, ekiplerin olayları daha hızlı tespit etmesini, katmanlar arasında kök nedenleri belirlemesini ve kısmi bilgi yerine tam bağlamla müdahale etmesini sağlar.
Ürününüz API'lere dayanıyorsa (ki modern ürünlerin çoğu öyledir), yalnızca genel yüzeyi izlemek sistemin yalnızca yarısını izlemek demektir. Hem genel hem de özel uç noktaları kapsayan izleme stratejileri oluşturan ekipler, en fazla olayı önleyen, onları en hızlı çözen ve en güçlü uçtan uca güvenilirliği sürdüren ekiplerdir.