Operasyonel görünürlük için panolar geliştirme

Hepimiz dizüstü bilgisayarlarımızda, tabletlerimizde ve akıllı telefonlarımızda uygulamalar çalıştırıyoruz. Cihazın açık, Wi-Fi ağ bağlantısının çevrimiçi olup olmadığını görmemiz oldukça kolay. Disk alanının azalması gibi kritik bildirimlerin ekranlarımızda gösterileceğini biliyoruz. Hatta kullanıcı arabiriminin (UI) genel hızı ve akıcılığı bile cihazdaki bellek ve CPU gibi kaynakların uygulamalarımızı çalıştırmak için yeterli olup olmadığını anlamamıza yetebiliyor.

Ailelerinin cihazları için uzaktan teknik destek sağlamış olanlar, cihazı göremeden ve cihazla doğrudan etkileşim kuramadan sorunları tespit etmenin biraz daha zor olduğunu bilir. Bulut tabanlı hizmetler çalıştırırken de benzer bir zorlukla karşı karşıya kalırız: Bu uzak hizmetleri nasıl izleyebiliriz ve müşterilerimizin mutlu olduğundan nasıl emin olabiliriz?

Tek ana sunucuya sahip bir hizmeti gözlemlemek için ana sunucuda oturum açarız, çeşitli çalışma zamanı izleme araçları çalıştırırız ve ana sunucuda olup bitenlerin temel nedenini belirlemek için günlükleri inceleriz. Ancak tek ana sunucuya sahip çözümler sadece kritik olmayan, aşırı derecede basit hizmetlerde uygulanabilir. İşin öteki tarafında da yüzlerce, hatta binlerce sunucu, container veya sunucusuz ortam üzerinde çalıştırılan, çok katmanlı, dağıtılmış mikro hizmetler bulunur.

Amazon, dünyanın çeşitli yerlerinde çok sayıda Bölgedeki birden fazla Erişilebilirlik Alanında çalışan tüm bu bulut tabanlı hizmetlerin gerçekte ne durumda olduğunu nasıl görebiliyor? Otomatik izleme, otomatik iyileştirme iş akışları (ör. trafik kaydırma) ve otomatik dağıtma sistemleri, bu ölçekteki sorunların büyük bir çoğunluğunu tespit etme ve giderme noktasında kritik öneme sahiptir. Ancak birçok farklı sebeple bu hizmetlerin, iş akışlarının ve dağıtımların herhangi bir anda ne durumda olduğunu da görebilmemiz gerekir.

Bulut hizmetlerimizdeki etkinlikleri kontrol altında tutma sorumluluğumuzu yerine getirme mekanizmalarından biri olarak panoları kullanıyoruz. Zaman serisi ölçümlerini, günlükleri, izlemeleri ve alarm verilerini göstererek sistemin ne durumda olduğuna dair kısa özetler sağlayan panolar, insanların sistemlerimizde olup bitenleri görebilmesine olanak tanır.

Amazon olarak bu panoları oluşturma, kullanma ve düzenli bakımlarını yapma süreçlerine pano oluşturma adını veriyoruz. Hizmetlerimizin başarısı açısından bakıldığında hizmetlerimizin tasarlanması, kodlanması, geliştirilmesi, test edilmesi, dağıtılması ve ölçeklendirilmesi gibi diğer tüm rutin yazılım teslimi ve operasyon etkinlikleri kadar önemli olduğundan, pano oluşturma da birinci sınıf bir etkinlik haline geldi.

Elbette, operatörlerimizin her an panoları izlemesini beklemiyoruz. Bu panoları çoğu zaman hiç kimse izlemiyor. Hatta panolar ne kadar sık incelense de panoların manuel olarak incelenmesini gerektiren her türlü operasyonel sürecin başarısızlık sebebinin insan hatası olduğunu gördük. Bu riski gidermek için sistemlerimizin sağladığı en önemli izleme verilerini devamlı olarak değerlendiren otomatik alarmlar oluşturduk. Bunlar genellikle ya sistemin bir sınıra ulaşmakta olduğunu (etki öncesinde proaktif saptama) ya da sistemin beklenmedik bir şekilde olumsuz etkilendiğini (etki sonrasında reaktif saptama) gösteren ölçümlerdir.

Bu alarmlar otomatik iyileştirme iş akışlarını yürütebilir ve operatörlerimize sorun hakkında bildirim gönderebilir. Bu bildirim, operatörü kullanması gereken panolara ve işletim kılavuzlarına yönlendirir. Ben nöbetteyken bir alarm bildirimi beni bir sorun hakkında uyardığında ilgili panoları hızla kullanarak müşterilerin ne kadar etkilendiğini anlayabiliyorum, temel nedeni doğrulayabiliyor veya önceliklendirebiliyorum, sorunu hafifletebiliyorum ve kurtarma süresini kısaltabiliyorum. Alarm bir otomatik iyileştirme iş akışını zaten başlatmış olsa bile otomatik iş akışının neler yaptığını ve sistemin nasıl etkilendiğini görmem, ayrıca nadiren de olsa emniyet açısından kritik adımlarda iş akışının ilerlemesi için bir insan olarak onay vermem gerekiyor.

Amazon, bir olay devam ederken genellikle nöbetteki birden fazla operatörü göreve çağırır. Bir dizi görevi tamamlama sürecindeki operatörler, farklı panolar kullanıyor olabilir. Bu görevler genellikle müşterilerin ne kadar etkilendiğini belirleme, önceliklendirme, birden fazla hizmeti takip ederek olayın temel nedenini bulma, otomatik iyileştirme iş akışlarını gözlemleme ve işletim kılavuzuna bağlı hafifletme adımlarını yürütme ve doğrulama gibi görevlerdir. Bunun yanı sıra, eş ekipler ve iş paydaşları da bir olay sırasında devam eden etkiyi izlemek için panoları kullanır. Bu farklı katılımcılar vaka yönetimi araçlarını, sohbet odalarını (AWS Chatbot gibi robotlarla) ve konferans görüşmelerini kullanarak iletişim kurar. Her paydaş, panolarda gördüğü verilere farklı bir bakış açısı getirir.

Amazon ekipleri ve daha geniş çaptaki kuruluşlar her hafta kıdemli liderlerin, yöneticilerin ve çok sayıda mühendisin katıldığı operasyon inceleme toplantıları da yapar. Bu toplantılarda bir çarkıfelek kullanarak geniş kapsamlı denetim panoları arasından seçim yaparız. Paydaşlar hem müşterilerimizin deneyimlerini hem de erişilebilirlik ve gecikme gibi temel hizmet seviyesi hedeflerini inceler. Bu paydaşların kullandığı denetim panolarında genellikle tüm Erişilebilirlik Alanlarından ve Bölgelerden operasyon verileri görünür.

Buna ek olarak Amazon, uzun vadeli kapasite planlaması yaparken ve tahminlerde bulunurken, sistemimizin uzun zaman aralıklarında sağladığı en geniş kapsamlı iş, kullanım ve kapasite ölçümlerini görselleştiren panolar kullanır.

İnsanlar panoları, hizmetleri manuel olarak izlemek için kullanır ancak elbette tüm kullanım senaryolarını karşılayan tek bir şablon yoktur. Çoğu sistemde, her biri sistemi farklı bir açıdan gösteren çok sayıda pano kullanırız. Bu farklı görünümler, farklı kullanıcıların farklı açılardan ve farklı zaman aralıklarında sistemlerimizin ne durumda olduğunu anlamasına olanak tanır.

Her bir hedef kitlenin istediği veriler, panodan panoya ciddi anlamda değişiklik gösterebilir. Panoları tasarlarken, ilgili hedef kitleye odaklanmamız gerektiğini öğrendik. Her bir panoya hangi verilerin ekleneceğine karar verirken panoyu kimin kullanacağını ve neden kullanacağını göz önüne alıyoruz. Amazon olarak, müşteriden başlayarak geriye doğru hareket ettiğimizi duymuşsunuzdur. Pano oluşturma bunun muhteşem bir örneğidir. Panoları kullanıcıların ihtiyaçlarına ve belirttikleri gereksinimlere dayalı olarak oluşturuyoruz.

Farklı panoların bütün sistemi nasıl farklı şekillerde gösterdiğini aşağıdaki diyagramda görebilirsiniz:

Amazon olarak en önemli ve en geniş kullanım alanına sahip panolarımız, müşteri deneyimi panolarıdır. Bu panolar, hizmet operatörlerini ve diğer birçok paydaşı içeren geniş bir kullanıcı grubunun kullanımı için tasarlanmıştır. Bunlar, genel hizmet durumu ve hedeflere bağlılık hakkındaki ölçümleri etkili bir şekilde sunar. Ayrıca, hem hizmetin kendisinden hem de istemcinin izlenmesinden, devamlı test yapan aracılardan (Amazon CloudWatch Synthetics canary'leri gibi) ve otomatik iyileştirme sistemlerinden elde edilen izleme verilerini gösterir. Bu panolar, kullanıcıların etkinin derinliği ve genişliği hakkındaki soruları cevaplamasına yardımcı olan veriler de içerir. "Kaç müşteri bundan etkileniyor?" ve "En çok hangi müşteriler etkileniyor?" soruları bunlardan bazıları olabilmektedir.

Web tabanlı hizmetlerimize giriş noktaları genellikle kullanıcı arabirimi ve API uç noktalarıdır. Bu nedenle sistem seviyesine tahsis edilmiş panolar, operatörlere sistemin ve müşteriye dönük uç noktalarının ne durumda olduğunu görme olanağı tanıyacak yeterli miktarda veri içermelidir. Bu panolar öncelikli olarak arabirim seviyesindeki izleme verilerini gösterir. Bu panolar, her API için üç ayrı kategoride izleme verileri görüntüler:

• Girdilerle ilgili izleme verileri. Alınan istek sayımları ya da kuyruklardan/akışlardan yoklanan işler, istek bayt boyutu yüzdelik dilimleri ve kimlik doğrulama/yetkilendirme hatası sayımları buna dahil olabilir.
• İşlemlerle ilgili izleme verileri. Çok modlu iş mantığı yolu/dalı yürütme sayımları, arka uç mikro hizmet istek sayım/hata/gecikme yüzdelik dilimleri, hata günlüğü çıktısı ve istek takip verileri buna dahil olabilir.
• Çıktılarla ilgili izleme verileri. Yanıt türü sayımları (müşterinin hatalı yanıtlarını içeren kırılımlar dahil), yanıtların boyutu ve ilk yanıt baytını yazma süresi ile tam yanıtı yazma süresi için yüzdelik dilimler buna dahil olabilir.

Genel olarak, bu müşteri deneyimi panolarını ve sistem seviyesindeki panoları olabildiğince geniş kapsamlı tutmaya çalışırız. Aşırı bilgi yüklemesi bu panoların iletmesi gereken ana mesajı ikinci plana atabileceğinden, bu panolara çok fazla ölçüm eklemekten özellikle kaçınıyoruz.

Müşterilerin tek bir hizmet bulut sunucusundaki (bölüm veya hücre) deneyiminin hızlı ve kapsamlı bir şekilde değerlendirilebilmesi için bazı panolar geliştiririz. Bu dar görünüm, tek bir hizmet bulut sunucusu üzerinde çalışan operatörlerin, diğer hizmet bulut sunucularına ait alakasız verilerle uğraşmadan asıl işlerine odaklanmasını sağlar.

Bir hizmetin tüm Erişilebilirlik Alanlarındaki ve Bölgelerdeki tüm bulut sunucularına dair veriler gösteren müşteri deneyimi panoları da geliştiririz. Bu hizmet denetimi panoları, operatörlerin tüm hizmet bulut sunucularındaki otomatik alarmları denetleyebilmesi amacıyla kullanılır. Bu alarmlar, yukarıda bahsettiğimiz haftalık operasyon toplantıları sırasında da incelenebilir.

Daha uzun vadeli kullanım senaryolarında, hizmetlerimizin büyümesini görselleştirmemize yardımcı olan kapasite planlama ve tahmin panoları da geliştiririz.

Amazon API'leri genellikle arka uç mikro hizmetlerinde isteklerin düzenlenmesiyle uygulanır. Bu mikro hizmetler, her biri isteği işlemenin farklı bir yönünden sorumlu olan birden fazla ekibe ait olabilir. Örneğin, bazı mikro hizmetler istek kimlik doğrulaması ve yetkilendirmesine, kısıtlama/sınır uygulanmasına, kullanım ölçümüne, kaynakların oluşturulmasına/güncellenmesine/silinmesine, kaynakların veri depolarından çekilmesine ve zaman uyumsuz iş akışlarının başlatılmasına tahsis edilmiştir. Ekipler genellikle her API'ye yönelik veya verileri hizmet zaman uyumsuz bir şekilde işliyorsa iş birimine yönelik ölçümleri gösteren, mikro hizmete özgü, tahsis edilmiş bir pano geliştirir.

Mikro hizmetlere yönelik panolarda genellikle sistemin uygulanma şekline özgü olan ve hizmete dair derinlemesine bilgi gerektiren izleme verileri gösterilir. Bu panolar öncelikli olarak hizmetlerin sahibi olan ekipler tarafından kullanılır. Ancak hizmetlerimiz yoğun bir şekilde izlendiğinden, bu izlemeden elde edilen verileri operatörleri boğmayacak bir şekilde sunmamız gerekmektedir. Dolayısıyla bu panolarda bazı veriler toplu olarak gösterilir. Toplu verilerde anormallikler tespit eden operatörler genellikle daha derine inmek için toplu hale getirilmemiş asıl izleme verileri üzerinde geçici sorgular yürütmek, istekleri takip etmek ve ilgili ya da bağıntılı verileri ortaya çıkarmak gibi birçok çeşitli araç kullanır.

Hizmetlerimiz, genellikle farklı ölçümler sağlayan AWS altyapısı üzerinde çalışır. Bu nedenle, tahsis edilmiş altyapı panolarımız bulunur. Bu panolar öncelikli olarak sistemlerimizin üzerinde çalıştığı Amazon Elastic Compute Cloud (EC2) bulut sunucuları, Amazon Elastic Container Service (ECS)/Amazon Elastic Kubernetes Service (EKS) container'ları ve AWS Lambda işlevleri gibi işlem kaynaklarının sağladığı ölçümlere odaklanır. Bu panolarda CPU kullanımı, ağ trafiği, disk G/Ç ve alan kullanımı gibi ölçümlerin yanı sıra bu işlem kaynaklarıyla ilgili küme, Otomatik Ölçeklendirme ve kota ölçümleri yaygın bir şekilde kullanılır.

Mikro hizmetler, birçok senaryoda işlem kaynaklarının yanı sıra başka mikro hizmetlere de ihtiyaç duyar. İlgili bağımlılıkların sahibi olan ekiplerin kendi panoları olsa bile, her mikro hizmet sahibi genellikle hem yukarı yönlü bağımlılıkların (ör. proxy'ler ve yük dengeleyiciler) hem de aşağı yönlü bağımlılıkların (ör. veri depoları, kuyruklar ve akışlar) ne durumda olduğunu kendi hizmetleriyle ölçerek gösteren, tahsis edilmiş bağımlılık panoları geliştirir. Bu panolar, güvenlik sertifikalarının son geçerlilik tarihleri ve diğer bağımlılık kotası kullanımları gibi diğer kritik ölçümleri takip etmek üzere de kullanılabilir.

Amazon olarak, veri sunumundaki tutarlığın, başarılı bir pano oluşturma konusunda kritik öneme sahip olduğunu düşünüyoruz. Panoların etkili olması için hem pano içinde hem de tüm panolar arasında tutarlılık yakalanmalıdır. Panoların mümkün olan en geniş hedef kitleye hitap etmesini sağladığını düşündüğümüz ortak tasarım kuralları ve ilkeleri belirleyerek bunları yıllar içerisinde uyarladık ve düzelttik. Bunlar sayesinde, panoların kuruluşumuza sunduğu değeri yükselttik. Hatta zaman içinde bu tasarım ilkelerini kullanıcıların iş akışlarını bozmadan ölçmenin ve iyileştirmenin yollarını bulduk. Örneğin, hizmetin nasıl çalıştığını öğrenmek isteyen yeni bir operatörün panolarda sunulan verileri hızlı bir şekilde anlayabilmesi ve kullanabilmesi, bize panoların doğru bilgileri doğru şekilde sunduğunu gösteriyor.

Panolar tasarlarken en sık yapılan yanlışlardan biri, hedef kullanıcının alan bilgisinin gerçekte olduğundan fazla veya az olduğunu düşünmektir. Geliştiren kişiye son derece mantıklı gelen bir pano geliştirmek oldukça kolaydır. Ancak aynı pano, kullanıcılara hiçbir değer sunmayabilir. Bu riski ortadan kaldırmak amacıyla, müşteriden (bu senaryoda pano kullanıcılarından) başlayarak geriye doğru hareket etme tekniğini kullanıyoruz.

Panolardaki verilerin yerleşimini standartlaştıran bir tasarım ilkesi benimsedik. Panolar üstten alta doğru gösterilir ve kullanıcılar genellikle ilk gösterilen (pano yüklendiği anda görünür olan) verileri en önemli veriler olarak yorumlar. Bu nedenle tasarım ilkemiz gereği, en önemli verilerin panonun en üstüne yerleştirilmesi önerilir. Toplu/özet erişilebilirlik grafiklerinin ve uçtan uca gecikme yüzdelik dilimi grafiklerinin web hizmetleri için genellikle en önemli panolar olduğunu gördük.

Foo Service adlı farazi bir hizmete ait panonun en üst tarafının ekran görüntüsü aşağıdaki gibi olacaktır:

Bir grafikte çok sayıda ölçümümüz varsa, grafikteki lejantların, görünen grafik verilerini dikey veya yatay olarak sıkıştırmamasına dikkat ederiz. Grafiklerde arama sorguları kullanıyorsak, normalden daha büyük bir ölçüm sonucu kümesine alan tanırız.

Bu sayede kullanıcılar yatay olarak kaydırma zorunluluğundan kurtulur. Sabah saat 3'te dizüstü bilgisayarıyla çalışan bir nöbetçi operatör, çok belirgin bir görsel ipucu olmadığı sürece, sağ tarafta daha fazla grafik olduğunu fark etmeyebilir.

Tarih ve saat verilerini gösteren panolarda, ilgili saat diliminin de panoda görünür olmasına dikkat ederiz. Farklı saat dilimlerindeki operatörlerin eş zamanlı olarak kullandığı panolarda, tüm kullanıcıların referans alabileceği tek bir saat dilimi (UTC) kullanırız. Bu sayede kullanıcılar, her defasında saat dilimlerini birbirine dönüştürme derdinden kurtulur ve birbirleriyle tek bir saat dilimi üzerinden iletişim kurabilir.

Varsayılan olarak, en yaygın kullanım senaryolarına uygun zaman aralığını ve veri noktası dönemini gösteririz. Bir panodaki tüm grafiklerin en başta aynı zaman aralığına ve çözünürlüğe ilişkin verileri göstermesine dikkat ederiz. Panonun belirli bir kısmındaki tüm grafiklerin yatay olarak aynı boyutta olmasının faydalı olduğunu görüyoruz. Bu sayede, grafikler arasında zaman bağıntısı kurmak kolaylaşır.

Bunun yanı sıra, panonun yüklenmesini yavaşlatması sebebiyle, grafiklerde çok fazla veri noktası çizmekten kaçınırız. Ayrıca kullanıcıya aşırı miktarda veri noktası göstermenin, anormalliklerin görünürlüğünü azaltabildiğini gözlemledik. Örneğin, üç saatlik bir aralığı bir dakikalık çözünürlükle gösteren ve dolayısıyla ölçüm başına sadece 180 değere sahip olan bir grafik, küçük pano widget'larında bile net bir şekilde görüntülenebilir. Bu veri noktası sayısı, devam eden operasyonel olayları önceliklendiren operatörlere yeterli bağlamı da sağlar.

Panolarımız, tüm grafiklerde hem zaman aralığını hem de ölçüm dönemini hızla ayarlamak için gerekli denetimleri sağlar. Panolarımızda yaygın bir şekilde kullandığımız aralık x çözünürlük oranlarımız şunlardır:

• 1 saat x 1 dakika (60 veri noktası): devam eden olayları gözlemlemek üzere verileri yakınlaştırmak için faydalıdır
• 12 saat x 1 dakika (720 veri noktası)
• 1 gün x 5 dakika (288 veri noktası): günlük trendleri görüntülemek için faydalıdır
• 3 gün x 5 dakika (864 veri noktası)
• 1 hafta x 1 saat (168 veri noktası): haftalık trendleri görüntülemek için faydalıdır
• 1 ay x 1 saat (744 veri noktası)
• 3 ay x 1 gün (90 veri noktası): üç aylık trendleri görüntülemek için faydalıdır
• 9 ay x 1 gün (270 veri noktası)
• 15 ay x 1 gün (450 veri noktası): uzun vadeli kapasite incelemeleri için faydalıdır
  

İlgili otomatik alarmları bulunan ölçümleri grafiklere dökerken, alarm eşikleri statikse, grafiklere yatay çizgilerle açıklama ekleriz. Alarm eşikleri dinamikse, yani yapay zeka (AI) veya makine öğrenimi (ML) kullanılarak oluşturulan öngörülere veya tahminlere dayalıysa, hem gerçek ölçümleri hem de eşik ölçümlerini aynı grafikte gösteririz. Bir grafikte hizmetin bilinen sınırlara (ör. "maksimum test" sınırı veya kesin kaynak sınırı) sahip bir yönünü ölçen herhangi bir ölçüm gösteriliyorsa, bilinen veya test edilen sınırların nerede olduğunu gösteren yatay bir çizgiyle grafiğe açıklama ekleriz. Hedefleri olan ölçümlerde, kullanıcının hedefleri açıkça görebilmesi için yatay çizgiler ekleriz.

Bu grafiklere yatay çizgiler eklerseniz, kullanıcılar yatay çizginin hangi y ekseniyle ilgili olduğunu anlamakta zorlanabilir. Bu belirsizlikten kaçınmak için bunun gibi grafikleri sadece tek bir yatay eksenin kullanıldığı iki ayrı grafiğe böleriz ve yatay çizgileri sadece ilgili grafiğe ekleriz.

Bir veya birden fazla ölçümdeki değişimin görünürlüğünü azaltabileceğinden, bu durumdan kaçınmaya özen gösteririz. Buna örnek olarak, p100 veri noktalarının p0 veri noktalarından onlarca kat daha büyük olabileceği tek bir grafikte p0 (minimum) ve p100 (maksimum) gecikme değerlerini çizmemiz verilebilir.

Y ekseni aralığının veri noktası değerleriyle sınırlandırıldığı bir grafiğe fazla dikkat etmeden baktığınızda, ilgili ölçüm gözlerinize gerçekte olduğundan çok daha değişken gibi görünebilir.

Tek bir grafikte çok fazla istatistiğe veya alakasız ölçümlere yer vermemeye özen gösteririz. Örneğin, istek işleme için grafikler eklerken, genellikle aşağıdakilerin her biri için panoda yan yana birbirinden ayrı grafikler oluştururuz:

• Erişilebilirlik Yüzdesi (Hatalar/İstekler * 100)
• p10, Ortalama, p90 gecikmeler
• p99,9 ve Maksimum (p100) gecikmeler
  

Bu özellikle sistemin uygulanma şekline özgü olan ölçümler için geçerlidir. Pano metinlerinde (ör. her bir grafiğin yanındaki veya altındaki açıklama metninde) yeterli bağlam vermek isteriz. Operatör, ölçümün neyi ifade ettiğini anlamak için bu metni okuyabilir. Ardından operatör, "normal" değerin nasıl olması gerektiğini ve "normal" olmayan bir durumun nasıl görüneceğini yorumlayabilir. Bu metinde, operatörün temel nedeni belirlemek üzere kullanabileceği ilgili kaynakların bağlantılarını veririz. Verdiğimiz bağlantı türlerinin birkaç örneği şunlardır:

• İşletim kılavuzları. Konunun uzmanları için panonun kendisi de işletim kılavuzu vazifesi görebilir.
• İlgili "derinlemesine inceleme" panoları.
• Diğer kümeler veya bölümler için eş değer panolar.
• Dağıtım işlem hatları.
• Bağımlılıklar için iletişim bilgileri.
  

Panonun kullanım senaryolarına bağlı olarak, tek bir sayı (ör. bir ölçümün en son değeri) veya alarm durumu içeren bir widget göstermenin, yakınlardaki tüm veri noktalarını içeren karmaşık bir zaman serisi grafiği göstermekten daha uygun olduğunu görüyoruz.

Seyrek ölçümler, sadece belirli hata koşulları meydana geldiğinde sağlanan ölçümlerdir. Sadece gerekli olduğunda bu ölçümleri sağlaması için hizmetleri izlemek verimli olabilse de boş veya çok az veri içeren grafikleri gören pano kullanıcılarının kafaları karışabilir. Panoları tasarlarken böyle ölçümlerle karşılaştığımızda, genellikle hizmeti modifiye ederek, herhangi bir hata koşulu olmadığında bu ölçümler için sürekli olarak emniyetli değerler (sıfır değeri) sağlayacak şekle getiririz. Bu sayede operatörler, herhangi bir veri olmadığında hizmetin doğru şekilde telemetri sağlamıyor olabileceğini anlayabilir.

Bunu, sistemlerimizdeki çok modlu davranışları bir araya getiren ölçümler için grafikler gösterirken yaparız. Bunu yapabileceğimiz durumlardan bazıları şunlardır:

• Bir hizmet değişken boyutlu istekleri destekliyorsa, isteklerin genel gecikmeleri için bir grafik oluşturabiliriz. Dahası küçük, orta ve büyük istekler için ölçümleri gösteren grafikler de oluşturabiliriz.
• Bir hizmet istekleri girdi parametrelerinin değerlerine (veya kombinasyonlarına) dayalı olarak değişken şekillerde yürütüyorsa, her bir yürütme modunu yakalayan ölçümler için grafikler ekleyebiliriz.