Gürültüden İçgörüye: Kibana'da Teşhis Odaklı API Dashboard Mimarisi

Günümüz yazılım mimarilerinde, yüksek trafikli ve yoğun yük altında çalışan sistemlerde -kısaca tüm bilişim dünyasında- en kritik sorulardan biri şudur: "Sistemimde şu an ne oluyor ve ben bunu gerçek zamanlı olarak görebiliyor muyum?"

Dağıtık sistemlerin, mikroservis mimarilerinin ve yüksek trafikli API'ların yaygınlaşmasıyla birlikte, tek bir işlem bile onlarca servisten geçerken arkasında dev bir log yığını bırakmaktadır. Bu ölçekte günlük log üretim miktarı milyonlarca hatta milyarlarca satıra ulaşabilmektedir. Bu noktada yalnızca log üretmek yeterli değildir; çünkü doğru veriye zamanında ulaşamayan bir ekip için o log satırları, çözümden çok gürültüye dönüşür.

Asıl kritik olan, üretilen bu devasa veriyi anlamlandırabilmek, eğilimleri ve anormallikleri erken fark edebilmek, sistem davranışlarını gerçek zamanlı olarak analiz edebilmek ve sorunları müşteriye yansımadan tespit edebilmektir. Aksi halde bir hata; loglar arasında saatlerce sürebilecek manuel bir arama sürecine, dolayısıyla ciddi zaman ve itibar kaybına dönüşebilir.

Milyonlarca satır log arasında kaybolmak bir tercih olabilir, ancak bu veriyi anlamlı trendlere, görselleştirilebilir metriklere ve aksiyona dönüştürülebilir içgörülere çevirmek artık bir seçenek değil, bir zorunluluktur. İşte bu zorunluluğu yerine getirmemizi sağlayan en güçlü araçlardan biri: Kibana.

Bu makalede, Kibana kurulumunun copy-paste detaylarında boğulmadan (merak edenler için makalenin devamına güzel bir kurulum rehberi bırakıyorum) doğrudan işin mutfağına gireceğiz. Kibana üzerinde dashboard'ların nasıl oluşturulduğunu, elastic sorgularının gücünü ve bu görselleştirmenin operasyonel süreçlerimize sağladığı katkıları pratik örneklerle ele alacağız.

Şimdi adet yerini bulsun diye Kibana'nın tanımını yapalım.

Kibana, Elastic Stack üzerinde bulunan verileri aramak, analiz etmek, görselleştirmek ve yönetmek için kullanılan web tabanlı bir kullanıcı arayüzü, yönetim panelidir. Farklı veri kaynaklarını tek bir kaynaktan görüntüleyebilmemizi, inceleyebilmemizi ve yönetebilmemizi sağlar.

Kibana, Elastic Stack ekosisteminin görselleştirme ve veri analiz katmanını oluşturan, web tabanlı açık kaynaklı bir platformdur. Elasticsearch üzerinde depolanan verilerin kullanıcı dostu bir arayüz üzerinden sorgulanmasını, analiz edilmesini, görselleştirilmesini ve yönetilmesini sağlar.

Bahsetmiş olduğum Kibana kurulum rehberi; Bu bağlantıyı ziyaret edebilirsiniz.

Bölüm 1: Doğru Metrik Doğru Aksiyon: API İzlemede KPI Seçimi

Kibana önümüzde açık ve elimizde görselleştirebileceğimiz yüzlerce farklı log alanı (field) var. Ancak bir dashboard tasarlarken düşülen en büyük hata, sadece "görselleştirebiliyoruz" diye sistemle ilgili her veriyi rastgele grafiklere dönüştürmektir.

Ekranda çok sayıda grafiğin olması, sistemi iyi izlediğimiz anlamına gelmez. Aksine, kriz anında asıl bakılması gereken kritik veriyi aramıza giren bu "veri gürültüsü" yüzünden kaçırabiliriz. Bir dashboard'un başarısı, sisteme bakan kişinin daha ilk birkaç saniyede bir problem olup olmadığını ve varsa bunun nereden kaynaklandığını anlayabilmesidir.

Bu yüzden, Kibana'da onlarca dashboard oluşturmaya başlamadan önce şu soruyu sorup bu sorunun cevabına göre dashboard oluşturmaya başlamak daha doğru bir yaklaşım olacaktır: "Sistemimin gerçekten sağlıklı ve performanslı çalıştığını bana hangi ölçümler kanıtlar?"

İşte bizi bu karmaşadan kurtaracak doğru metrikleri, KPI'lar sayesinde çok da zorlanmadan belirleyebiliriz.

Key Performance Indicator (KPI)

Bir Dashboard oluşturmaya başlamadan önce sormamız gereken ilk soru şudur: "Ben neyi ölçmek istiyorum?" İşte burada devreye KPI'lar giriyor.

Key Performance Indicator (KPI); bir sistemin, API'nin veya servisin başarısını, performansını, güvenilirliğini ve bunlara bağlı olarak iş süreçlerine olan katkısını ölçülebilir kriterlerle ortaya koyan göstergelerdir.

Sistemin darboğazlarını önceden tespit edebilmek için doğru KPI'ları izlemek hayati önem taşır.

KPI	Neyi cevaplar?
Response Time / Request Pipeline Time	API'lerin yanıt verme süreleri ve bu sürelerin iç bileşenlerde (gateway, network, backend) harcanan kırılımlar
Average Request/Response Size	Payload boyutlarındaki anomalileri yakalamak için ortalama veri büyüklükleri.
Success & Error Rate	2xx / 4xx / 5xx oranları anlık ve tarihsel olarak nasıl seyrediyor?
Response Size vs Response Pipeline Time	Büyük payload'lar yanıt süresini nasıl etkiliyor?
Top N Slowest Request	Sistemi en çok yoran endpoint'ler hangileri?
HTTP Status Code Distribution	Trafik durum kodlarına göre nasıl dağılıyor?
Throughput (RPS)	Sistem birim zamanda ne kadar istek karşılıyor?
Error Budget / SLA Uyumu	Belirlenen SLA hedefine (örn. %99.9) ne kadar yaklaşılıyor/uzaklaşılıyor?

Bir KPI'ı dashboard'a eklemeden önce kendinize şunu sorun: "Bu grafik alarm verdiğinde ben ne yapacağım?" Eğer bu sorunun net bir aksiyon planı yoksa, o KPI muhtemelen dashboard'da değil, ham veri olarak Discover'da kalmalı.

Bölüm 2: Görselleştirme Stratejisi: Hangi Metrik İçin Hangi Grafik?

Dashboard hazırlamanın amacı yalnızca verileri tek bir ekranda toplamak değil, bu verilerden anlamlı içgörüler üretebilmektir. Aynı veri kümesi, yanlış bir grafik türüyle görselleştirildiğinde önemli bilgileri gizleyebilir veya kullanıcıyı hatalı analizler yapmaya yönlendirebilir. Bu nedenle veri görselleştirmenin temelinde doğru görselleştirme tercihleri yer alır.

Her grafik türü belirli bir analiz ihtiyacına hizmet eder. Kibana'da hangi grafik türleri var ve bu grafik türlerinden hangileri hangi durumlar için kullanılabilir bunu ele alalım;

---

1-) Çizgi Grafikler (Line Charts)

Çizgi grafikleri, zaman içerisinde değişen metrikleri takip etmek için kullanılan en yaygın görselleştirme türüdür. Özellikle belirli bir periyottaki artışları, düşüşleri ve ani değişimleri kolayca fark etmeyi sağlar. Bu nedenle dashboard'larda en sık kullanılan grafiklerden biridir.

Kullanım Alanları

• API Response Time
• API Request Time
• Request Per Second

Örnek Senaryo

Bir API'nin 24 saat içerisindeki ortalama yanıt sürelerini (API Response Time) gösteren bir Line Chart'ımız olduğunu düşünelim. Saatler boyunca 150 ms civarında seyreden response time değerinin aniden 2.5 saniyeye yükseldiğini varsayalım.

Bu ani yükseliş; Veri tabanındaki bir kitlenmeye, yoğun trafik artışına, back-end servisinin yavaşlamasına, veya dış servis bağımlılıklarındaki gecikmelere işaret ediyor olabilir. Bu nedenle Line Chart'lar yalnızca metrikleri göstermekle kalmaz, aynı zamanda sistemdeki anomalilerin hangi zaman aralığında başladığını da hızlıca tespit etmemizi sağlar.

Öneri: Eğer zaman serisi verisi inceleniyorsa ilk tercih edilmesi gereken grafik türü Line Chart olmalıdır.

---

2-) Çubuk Grafikler (Bar Chart)

Çubuk grafikleri, farklı kategoriler arasındaki sayısal değerleri karşılaştırmak için kullanılan en temel ve okunabilir görselleştirme türlerinden biridir. Kibana'da dikey (Vertical) veya yatay (Horizontal) çubuk grafikler oluşturulabilir. Özellikle servisler, endpointler, istemciler veya HTTP durum kodları gibi kategorik verilerin karşılaştırılmasında oldukça başarılı sonuçlar sunar.

Genellikle "En fazla hangisi?", "En çok hata hangi serviste oluşuyor?" veya "En yoğun trafiği hangi istemci oluşturuyor" gibi sorulara hızlı cevap bulmaktadır. Çubuk grafikleri bu tarz karşılaştırmalı analizler için en uygun görselleştirmelerden biridir.

Kullanım Alanları

• HTTP Status Code Dağılımı
• En çok istek alan API'ler
• En fazla hata üreten endpointler
• Servis bazlı istek sayıları

Örnek Senaryo

Hangi API'nin diğer API'lere oranla daha çok hata ürettiği, sahip olduğu hata sayısı ve hataların HTTP Status Code'ları gözlemlenmek istenebilir.

Böyle bir durumda X ekseninde API'lerin servis isimleri, Y ekseninde ise HTTP Status Code'ları gösteren bir çubuk grafik oluşturarak hangi API'nin problem ürettiği saniyeler içerisinde tespit edilebilir.

3-) Pasta ve Donut Grafikler (Pie & Donut Charts)

Pasta (Pie) ve Donut grafikleri, bir bütünü oluşturan parçaların birbirlerine olan oranlarını göstermek için kullanılan görselleştirme türleridir. Amaç, toplam veri içerisindeki her kategorinin ne kadar paya sahip olduğunu hızlı ve anlaşılır bir şekilde sunmaktır. Kibana'da özellikle trafik dağılımlarını, HTTP durum kodlarını veya istek türlerini yüzdesel olarak analiz etmek için sıklıkla tercih edilir.

Bu grafikler mutlak sayıları karşılaştırmaktan ziyade, dağılımı ve oranları göstermede başarılıdır. Bu nedenle "Toplam trafiğin ne kadarı başarılı?", "İsteklerin büyük çoğunluğu hangi HTTP metoduyla geliyor?" gibi soruların cevabını tek bakışta verebilir.

Kullanım Alanları

• HTTP Status Code Dağılımı
• HTTP Method (GET, POST, PUT, PATCH, DELETE) Oranları
• Başarılı ve Başarısız İstek Yüzdeleri
• API Tüketicilerinin Toplam Trafik İçerisindeki Payı

Bölüm 3: Teoriden Pratiğe — Kibana'da Adım Adım Dashboard Kurmak

Teoriyi bir kenara bırakalım ve Kibana üzerinde KPI'ları canlı projelere nasıl dönüştüreceğimize bakalım. Kibana'da dashboard oluştururken genellikle Lens veya Discover modlarını kullanırız. Biz en esnek ve modern yöntem olan Kibana Lens üzerinden ilerleyeceğiz.

Adım #1: Data View (Index Pattern) Seçimi

Kibana arayüzünde sol menüden Analytics > Dashboard sekmesine gidin ve "Create Dashboard" butonuna tıklayın. Ardından "Create visualization" diyerek Lens ekranını açın. İlk yapmanız gereken sol üst köşeden loglarınızın aktığı doğru "Data View"'ı (Eski adıyla Index Pattern) yapısını (örneğin: api-traffic-logs-*) seçmektir.

Adım #2: Görselleştirme Türü (Grafik) Seçimi (Bar/Line/Donut)

Data View'ı seçtikten sonra Lens ekranı bizi görselleştirme türü seçimiyle karşılar. Ekranın sağ üst tarafında yer alan panelde Bar, Line, Area, Donut, Pie, Table, Heat Map gibi birçok seçenek göze çarpar. İlk bakışta bu çeşitlilik kafa karıştırıcı gelebilir; ancak doğru soruyu sorduğumuzda seçim aslında oldukça netleşir.

Sorulması gereken soru şu: "Ben bu veriyle ne anlatmak istiyorum?"

KPI'lar burada yol gösterici oluyor. Çünkü her KPI aslında farklı bir monitoring ihtiyacını ele alır, her bir monitoring ihtiyacı da bazı grafiklerle daha net anlaşılır:

• Zaman içindeki bir değişimi mi izliyoruz? (Örn: Response Time'ın saatlere göre dalgalanması, Request Per Second'ın gün içindeki artış-azalışı) → Line Chart
• Kategoriler arası bir karşılaştırma mı yapıyoruz? (Örn: Hangi endpoint en çok hata üretiyor, hangi servis en yoğun trafiği alıyor) → Bar Chart
• Bir bütünün parçalara dağılımını mı görmek istiyoruz? (Örn: HTTP metodlarının yüzdesel dağılımı, başarılı/başarısız istek oranı) → Donut/Pie Chart
• Zaman içindeki değişimi, aynı zamanda hacmi de vurgulayarak mı göstermek istiyoruz? (Örn: Toplam trafik hacmi artarken hata oranının da nasıl seyrettiği) → Area Chart

Burada dikkat edilmesi gereken küçük ama önemli bir ayrım var: Line Chart ile Area Chart çoğu zaman birbirine karıştırılır. İkisi de zaman serisi gösterir, ancak Area Chart grafiğin altını doldurarak hacmi de vurgular. Eğer sadece bir trendi (yükseliş/düşüş) göstermek istiyorsanız Line Chart yeterlidir; ama "bu trendin arkasındaki hacim ne kadar büyük" sorusuna da cevap vermek istiyorsanız Area Chart daha doğru bir tercih olur.

Kibana Lens'in Akıllı Öneri Sistemi (Suggestions)

Siz field'larınızı (X ekseni, Y ekseni, break down vs.) seçtikçe, ekranın alt kısmında "Suggestions" adı verilen küçük önizleme kartları belirir. Kibana, seçtiğiniz veri tipine bakarak "Bu veri için muhtemelen şu grafik daha anlamlı olur" diyerek size alternatif görselleştirmeler önerir. Örneğin bir tarih alanı ve sayısal bir metrik seçtiğinizde, Lens otomatik olarak Line Chart'ı öncelikli öneri olarak sunar; kategorik bir alan seçtiğinizde ise Bar Chart öne çıkar.

Adım #3: Metrik ve Alan (Field) Seçimi, Agregasyon (avg, sum, count)

Grafik türünü seçtikten sonra sıra, "hangi veriyi, nasıl özetleyerek göstereceğiz" sorusuna geliyor. Ben örnek dashboard'umu Apinizer API Gateway logları üzerinde çalışacağım için Apinizer log yapısını referans alarak dashboardlar oluşturacağım.

Makalenin devamında göreceğiniz log field'ları siz okurlar için herhangi bir anlam ifade etmeyecektir diye tahmin ediyorum. Hangi field hangi veriyi refere ediyor ? Hangi field'ın veri tipi ne? Hangi field neden kullanıldı ? gibi sorularınıza cevap verebilmesi adına Apinizer Log Yapısı'nı buraya tıklayarak inceleyebilirsiniz..

Cevaplamak istediğimiz soruları / izlemek istediğimiz metrikleri netleştirerek başlayalım;

Aşağıdaki her soru, dashboard'da ayrı bir panel/widget olarak hayat bulacak:

• Trafik Hacmi : Son 24 saatte API'lere gelen toplam istek sayısı nedir? (Zaman serisi grafiği)
• Servis Bazlı Dağılım : Hangi API/servis en çok çağrılıyor? (Pasta veya bar grafik — servis adına göre)
• Endpoint Bazlı Dağılım: Hangi Endpointler en çok çağrılıyor?
• Hata Oranı : HTTP Status Code'lara göre dağılım nedir? (4xx / 5xx oranı zaman içinde nasıl değişiyor?)
• Yavaş Endpoint'ler : Response time'ı en yüksek olan ilk 10 endpoint hangileri? (Top N tablo)
• Ortalama Response Time (Latency) : Zaman içinde ortalama/95p yanıt süresi nasıl değişiyor?
• En Çok Hata Veren Tüketiciler (Consumer/Client) : Hangi API key veya client en çok 4xx/5xx alıyor? (Olası kötüye kullanım/entegrasyon hatası tespiti)
• En Çok Rate Limit'e Takılan Tüketiciler
• En Yoğun Saatler

Bu grafikleri oluştururken her grafikte kullanacağımız bazı alanlar var. Grafikleri incelemeye başlamadan önce bunlardan da bahsetmek istiyorum;

• Metric (Y ekseni)
• Bucket (X ekseni / break down).

Metric (Y ekseni) — "Neyi ölçüyoruz?"

Bir alanı metrik olarak sürüklediğinizde Kibana size uygulanabilecek agregasyon fonksiyonlarını listeler:

• Count: Belirli bir zaman diliminde kaç doküman (log kaydı) geldiğini sayar. Request Per Second gibi trafik hacmi metrikleri için idealdir.
• Average (avg): Sayısal bir alanın ortalamasını alır. response_time alanı için Average, "API'lerimiz ortalama ne kadar sürede yanıt veriyor?" sorusunu cevaplar.
• Sum: Toplam değeri hesaplar. Örneğin toplam response boyutu (response_size) için kullanılabilir.
• Median / Percentile (p50, p95, p99): Ortalama tek başına yanıltıcı olabilir; birkaç aşırı uç (outlier) değer ortalamayı yukarı çekebilir. Bu yüzden performans analizlerinde p95 veya p99 gibi percentile metrikleri tercih edilir; "isteklerin %95'i şu sürenin altında tamamlanıyor" gibi çok daha gerçekçi bir tablo çizer.
• Unique Count (Cardinality): Bir alandaki benzersiz değer sayısını verir. "Kaç farklı kullanıcı bu API'yi çağırdı?" sorusuna cevap verir.
• Min / Max: En düşük ve en yüksek değerleri gösterir; anlık zirve (spike) tespiti için kullanışlıdır.

Bucket (X ekseni / Break down by) — "Nasıl gruplayacağız?"

• Date Histogram: Veriyi zaman aralıklarına (dakika, saat, gün) böler; Line ve Area Chart'ların temelini oluşturur.
• Terms: Kategorik bir alanın (örneğin service.keyword, status_code) en sık geçen değerlerine göre gruplama yapar; Bar ve Pie/Donut grafiklerinin temelidir.
• Filters: Kendi tanımladığınız KQL ifadelerine göre özel gruplar oluşturmanızı sağlar (örneğin "Başarılı" ve "Hatalı" olarak iki grup tanımlamak gibi).
• Range: Sayısal bir alanı kendi belirlediğiniz aralıklara böler (örneğin response time'ı 0-100ms, 100-500ms, 500ms+ şeklinde gruplamak).

Özetle Kibana Lens; doğru Data View, doğru Metric (agregasyon) ve doğru **Bucket** (gruplama) üçlüsüyle yönetilir. 

Ancak elimizdeki verileri ve metrikleri tek tek tanımlamak resmin sadece yarısıdır. Asıl operasyonel başarı, bu panelleri ekrana rastgele dizmek yerine, kriz anında bilişsel yükü azaltan bir yapıyla birleştirmektir.

Şimdi bu teorik altyapıyı, Apinizer API Gateway logları üzerinde 4 katmanlı gerçek bir dashboard mimarisine dönüştürelim.

Bölüm 4: Saha Uygulaması - API Gateway Dashboard

Teoriyi somutlaştırmak için Apinizer API Gateway trafiğini izlemek üzere kurduğumuz gerçek dashboard'u paylaşıyorum. apinizer-log-apiproxy-* index'i üzerinde çalışıyor; üstte API Proxy, Endpoint, Status Code ve Response Type filtreleriyle (control panel) her paneli anlık daraltabiliyorsunuz.

Dashboard'u rastgele panellerin / widget'ların üst üste dizilmesi olarak değil, birbirini tamamlayan dört katman olarak kurguladık: Genel Sağlık Özeti → Trafik Analizi → Performans Analizi → Detay Tabloları.

4.1 — Genel Sağlık Özeti: "Sistem şu an iyi mi, kötü mü?"

Dashboard'a bakan bir paydaşın ilk 3 saniyede alması gereken cevap budur. Bu yüzden bu katmandaki paneller bilinçli olarak Metric ve Pie türlerinden seçildi — yorum gerektirmeyen, tek bakışta okunan görseller.

Toplam İstek / Başarı Oranı Bu görselleştirmede rt (response type) alanı hem Count metriğinde hem de Top 3 values breakdown'ında kullanılıyor. İlk bakışta aynı alanın hem metrik hem de breakdown olarak kullanılması garip görünebilir; ancak burada her biri farklı bir amaca hizmet ediyor. Count, seçilen zaman aralığındaki toplam log (yani toplam istek) sayısını gösterirken, Top 3 values aynı logları success, error ve blocked değerlerine göre gruplandırarak dağılımını ortaya koyuyor. Böylece tek bir görselleştirme üzerinden hem toplam istek hacmini hem de bu isteklerin başarı, hata ve engellenme durumlarına göre nasıl dağıldığını kolayca analiz edebilirsiniz.

En Çok İstek Gelen API'ler

Aynı veri bu kez bir Pie Chart alanını baz alarak API'lerin toplam istek hacmindeki payını yüzdesel olarak göstermektedir. Bar Chart mutlak istek sayılarını sunarken, Pie Chart aynı veriyi oransal bir bakış açısıyla değerlendirmenizi sağlar. Böylece sistem trafiğinin belirli API'lerde yoğunlaşıp yoğunlaşmadığı kolayca analiz edilebilir. Örnekte toplam trafiğin yaklaşık %87.75'inin tek bir API (testm) üzerinde toplandığı görülmektedir. Bu tür bir dağılım, kapasite planlaması, darboğaz analizi ve yüksek trafikli servislerin izlenmesi açısından değerli bilgiler sağlar.

En Çok Hata Alan 3 API

apn (API proxy adı) alanının Terms breakdown'ı ile, rt üzerinden Count metriği kullanılarak en çok hata üreten 3 servis tek kartta listeleniyor. Bu panel doğrudan "Success & Error Rate" KPI'sinin servis kırılımı — genel hata oranını görmek yetmez, hangi servisin hata ürettiğini bilmek gerekir.

Toplam Request / Response Body (Legacy Metric)

sr1t (request size) ve sr2t (response size) alanlarının Sum toplamları, renk skalalı (yeşil → sarı → kırmızı) iki ayrı Legacy Metric kartında gösteriliyor. Renk eşikleri, "normal" ile "anormal" payload hacmi arasındaki sınırı görsel olarak işaretliyor — sayıyı okumak zorunda kalmadan skalanın rengi bile size bir sinyal veriyor.

Genel Durum: SUCCESS / ERROR / BLOCKED

Görseldeki renk kodlaması basit bir tasarım tercihi değil, doğrudan kullanıcı algısını yönlendiren bir okunabilirlik hamlesidir. apn verilerini oransal olarak gruplayan Pasta Grafik (Pie Chart); ERROR dilimindeki koyu kırmızı ve SUCCESS dilimindeki yeşil kullanımı sayesinde, kullanıcının sorunları "kırmızı alanın büyüklüğünden" anında teşhis etmesini sağlar.

3.2 — Trafik Analizi: "Trafik zaman içinde nasıl davranıyor?"

Genel sağlık özetinden sonraki soru zaman boyutudur: bir anomali ne zaman başladı?

Trafik (zaman serisi)

@timestamp üzerinde Date Histogram bucket'ı ile Count metriği kullanan klasik bir zaman serisi grafiği. Bu panel, saatler boyunca stabil seyreden bir trafiğin aniden sıçraması ya da düşmesi gibi durumları saniyeler içinde yakalamak için var — Bölüm 2'de bahsettiğimiz "zaman içindeki değişim → Line/Area Chart" kuralının birebir uygulaması.

Proxy'lere Göre İstek Sayısı

apn (API proxy) Terms bucket'ı, apmn breakdown'ı ile birlikte stacked bar olarak veriliyor. Bu grafik, API Gateway üzerinden geçen toplan trafiğin API Proxy ve Endpoint'lere göre dağılım profilini çıkarmak, en yüksek istek hacmine sahip servisleri tespit etmek için var.

4.3 — Performans ve Darboğaz Analizi: "Yavaşlık nerede?"

Bu katman, ortalamanın yeterli olmadığı, max ve median gibi daha keskin metriklerin devreye girdiği bölüm.

En Yüksek Request Pipeline Time'a Sahip API ve Endpointler

trqpt (request pipeline total time) üzerinde Max metriği, apn ve apmn (Top 3) kırılımlarıyla bar chart olarak veriliyor. "Ortalama" değil "maksimum" seçilmesi bilinçli: bir kullanıcı deneyimini bozan tekil zirve olayları, ortalamanın içinde kaybolup gidebilir.

Api Proxy / Endpoint Response Pipeline Max Time

Aynı mantık, bu kez trspt (response pipeline total time) için uygulanıyor. Request ve Response pipeline'ının ayrı panellerde tutulması önemli — gecikmenin gateway'e girişte mi, yoksa backend'den dönüşte mi oluştuğunu ayırt etmenizi sağlıyor.

Api Proxy Süreleri — Median

tapt (toplam API proxy time) üzerinde Median, apn'nin Top 10 kırılımıyla bir line chart olarak veriliyor. Burada Max yerine Median tercih edilmesi bilinçli bir karşıt örnek: bir önceki iki panel "en kötü senaryo"yu (max) gösterirken, bu panel "tipik kullanıcı deneyimi"ni (median) gösteriyor. İyi bir performans dashboard'u ikisini birden barındırmalı — sadece ortalamaya güvenmek yanıltıcı olabileceği gibi, sadece maksimuma bakmak da paniğe yol açabilir.

4.4 — Detay Tabloları: "Ham veriye ihtiyaç duyduğumda nereye bakarım?"

Bazı sorular grafikle değil, sıralı bir listeyle daha iyi cevaplanır. Dashboard'un son katmanı bilinçli olarak Data Table panellerinden oluşuyor:

• En Çok İstek Atan IP'ler / En Çok İstek Atan Client'lar — xff (client IP) alanının Top 5 değeri, Count ile / uok (client/consumer key) alanının Top 10 değeri

• En Yüksek Request / Response Size'a Sahip 20 API — apn Top 20 + sr1t(request size) / sr2t(response size) üzerinde Max

Bu paneller olası kötüye kullanımı (aşırı istek atan bir client, anormal büyük payload gönderen bir entegrasyon) yakalamak için var. Grafik değil tablo seçilmesinin sebebi net: burada amaç trendi görmek değil, spesifik bir kaydı — hangi IP, hangi API, hangi boyut — isim/değer bazında bulabilmek.

---

Sonuç

Kibana'yı sadece "loglara bakılan yer" olarak değil, sistemin nabzını tuttuğumuz bir kokpit olarak düşünmek işin özünü değiştiriyor. Elimizdeki yüzlerce field'ı rastgele grafiklere dönüştürmek yerine önce "sistemim gerçekten sağlıklı çalıştığını bana neyle kanıtlar?" sorusunu sormak, dashboard'u anlamlı kılan asıl adım. Response Time, Error Rate, Throughput gibi doğru KPI'ları belirledikten sonra grafik seçimi de kendiliğinden netleşiyor: zaman içindeki bir değişimi mi izliyoruz, Line/Area Chart; kategoriler arası bir karşılaştırma mı yapıyoruz, Bar Chart; bir bütünün parçalara dağılımını mı görmek istiyoruz, Pie/Donut Chart.

Kibana Lens üzerinden ilerlerken de Data View seçimi, grafik türü ve metrik/bucket (Count, Average, Sum, Percentile, Terms, Date Histogram vb.) yapılandırması aslında birkaç adımda hallediliyor.

Bunu somutlaştırmak için Apinizer API Gateway logları üzerine kurduğumuz gerçek dashboard'u da paylaştık. Bu dashboard'u dört katman halinde kurguladık:

1. Genel sağlık özeti — ilk 3 saniyede "iyi mi kötü mü" sorusuna cevap veren Metric/Pie panelleri
2. Trafik analizi — anomalinin ne zaman başladığını gösteren zaman serisi grafikleri
3. Performans analizi — Max ve Median metrikleriyle hem en kötü senaryoyu hem tipik deneyimi gösteren paneller
4. Detay tabloları — spesifik bir kaydı (hangi IP, hangi API, hangi boyut) bulmak için Data Table'lar

Sonuç olarak iyi bir dashboard, ekrana sığdırdığımız grafik sayısıyla değil, kriz anında doğru soruya saniyeler içinde cevap verebilme yeteneğiyle ölçülüyor.