Kibana’da Dashboard ve Görselleştirme Oluşturma

Yazar:komut.io ekibi ELK Stack ile Log Yönetimi ve Analizi
0 Yorum

Günlerce log dosyalarına bakıp “acaba bu sistem ne zaman patladı?” diye düşünmüşsünüzdür. Ben de öyle yaptım, ta ki Kibana’nın dashboard özelliklerini ciddiye alana kadar. Şimdi sabah işe geldiğimde bir ekrana bakıyorum ve sistemlerin gece nasıl davrandığını 30 saniyede anlıyorum. Bu yazıda sıfırdan Kibana dashboard’u nasıl kurarsınız, hangi görselleştirmeler gerçekten işe yarar, ve production ortamında nelere dikkat etmeniz gerektiğini aktaracağım.

Kibana’da Görselleştirme Mantığını Anlamak

Kibana’yı ilk açtığınızda göz korkutucu gelebilir. Lens, TSVB, Vega, Aggregation Based… Ne seçeceğinizi bilemezsiniz. Ama şunu bilin: günlük sysadmin işleri için Lens yüzde doksanını karşılar. TSVB (Time Series Visual Builder) zaman serisi verileri için güçlüdür, Vega ise çok özel görselleştirmeler isteyenler için neredeyse programlama gerektiren bir araç.

Kibana görselleştirme motoru Elasticsearch aggregation’larının üzerine oturur. Yani aslında siz her görsel oluşturduğunuzda arka planda bir ES sorgusu yazıyorsunuz, sadece bunu GUI üzerinden yapıyorsunuz. Bu yüzden Elasticsearch’te temel aggregation mantığını anlamak Kibana’yı çok daha iyi kullanmanızı sağlar.

Bir görselleştirme oluşturmadan önce şu soruları cevaplamanız gerekir:

  • Ne göstermek istiyorum? Anlık değer mi, trend mi, dağılım mı?
  • Zaman boyutu var mı? Zaman serisi mi yoksa anlık snapshot mi?
  • Kaç boyut var? Tek metrik mi, gruplandırılmış veri mi?

Bu soruları cevaplayınca doğru görsel tipine ulaşmak çok kolaylaşıyor.

Index Pattern ve Data View Kurulumu

Dashboard oluşturmadan önce Kibana’nın hangi veriyi kullanacağını bilmesi lazım. Kibana 8.x ile birlikte “Index Pattern” kavramı “Data View” olarak yeniden adlandırıldı, ama mantık aynı.

# Elasticsearch'te mevcut index'leri listele
curl -X GET "localhost:9200/_cat/indices?v&s=index" 
  -H 'Content-Type: application/json'

# Belirli bir index'in mapping'ini kontrol et
curl -X GET "localhost:9200/filebeat-*/_mapping?pretty" | head -100

Kibana arayüzünden Data View oluşturmak için Stack Management > Data Views > Create Data View yolunu izleyin. Ama bunu API üzerinden de yapabilirsiniz, özellikle birden fazla ortamda aynı konfigürasyonu tekrarlamanız gerekiyorsa bu çok daha pratik:

# Data View API üzerinden oluşturma
curl -X POST "localhost:5601/api/data_views/data_view" 
  -H 'kbn-xsrf: true' 
  -H 'Content-Type: application/json' 
  -d '{
    "data_view": {
      "title": "filebeat-*",
      "name": "Filebeat Logs",
      "timeFieldName": "@timestamp"
    }
  }'

Zaman alanı seçimi kritik. @timestamp standart Beats alanıdır ve genellikle doğru seçimdir. Ama bazı uygulamalar kendi timestamp formatlarını kullanır, bunları gözden kaçırmayın.

İlk Görselleştirme: Lens ile Hata Sayısı Grafiği

Gerçek dünya senaryosu ile gidelim. Nginx access loglarını Filebeat ile topluyorsunuz ve HTTP 5xx hatalarının saatlik dağılımını görmek istiyorsunuz.

Kibana’da Visualize Library > Create Visualization > Lens seçin. Sol panelde Data View olarak “filebeat-*” seçin. Şimdi:

  1. X eksenine @timestamp sürükleyin, interval’ı “Auto” bırakın
  2. Y eksenine Count metriği ekleyin
  3. Filtre olarak http.response.status_code >= 500 ekleyin

Ama bunu sadece arayüzden yapmak yerine, KQL (Kibana Query Language) kullanmak çok daha hızlı:

http.response.status_code >= 500 AND http.response.status_code < 600

Bu sorguyu görselleştirmenin üst kısmındaki arama çubuğuna yazarsınız ve otomatik uygulanır.

Şimdi biraz daha gelişmiş bir şey deneyelim. 5xx hatalarını endpoint’e göre gruplandıralım:

# Bu aggregation'ın ES karşılığını anlamak için
curl -X POST "localhost:9200/filebeat-*/_search?pretty" 
  -H 'Content-Type: application/json' 
  -d '{
    "size": 0,
    "query": {
      "range": {
        "@timestamp": {
          "gte": "now-24h",
          "lte": "now"
        }
      }
    },
    "aggs": {
      "status_5xx": {
        "filter": {
          "range": {
            "http.response.status_code": {
              "gte": 500,
              "lt": 600
            }
          }
        },
        "aggs": {
          "by_endpoint": {
            "terms": {
              "field": "url.path",
              "size": 10
            }
          }
        }
      }
    }
  }'

Bu sorguyu direkt çalıştırıp sonuçlara bakmak, Kibana’da görselleştirme tasarlarken ne beklemeniz gerektiğini anlamanızı sağlar. Kibana arayüzünde Lens ile bunu yapmak için “Break down by” bölümüne url.path alanını sürükleyip bırakmanız yeterli.

TSVB ile Sistem Metrikleri Dashboard’u

Metricbeat kullanıyorsanız CPU, memory, disk I/O gibi sistem metriklerini görselleştirmek için TSVB çok daha uygun. Nedeni şu: TSVB panel içinde birden fazla metriği aynı zaman serisinde göstermenize ve matematiksel işlemler yapmanıza olanak tanıyor.

Create Visualization > Legacy > TSVB yolunu izleyin.

CPU kullanımını görselleştirmek için panel options’ta:

  • Index pattern: metricbeat-*
  • Time field: @timestamp

Metrics sekmesinde:

  • Aggregation: Average
  • Field: system.cpu.total.pct

Formül kullanarak bunu yüzdeye çevirin: değeri 100 ile çarpmanız gerekebilir, bu Metricbeat versiyonuna göre değişir. Kontrol etmek için:

# Metricbeat CPU field değerlerini kontrol et
curl -X GET "localhost:9200/metricbeat-*/_search?pretty" 
  -H 'Content-Type: application/json' 
  -d '{
    "size": 1,
    "_source": ["system.cpu.total.pct", "@timestamp", "host.name"],
    "sort": [{"@timestamp": "desc"}]
  }'

Eğer değer 0.85 gibi geliyorsa zaten 0-1 arasında normalize edilmiş demektir, 100 ile çarpmanız gerekir. Görselde “Formula” aggregation tipini seçip params.cpu * 100 yazarsınız.

Alerting Entegrasyonu için Referans Görselleştirmeler

Bir dashboard sadece bakılan bir şey olmamalı, aynı zamanda alarm sisteminin temelini oluşturmalı. Production’da kullandığım bir pattern şu:

# Kibana Alert API ile görselleştirme bazlı alarm oluşturma
curl -X POST "localhost:5601/api/alerting/rule" 
  -H 'kbn-xsrf: true' 
  -H 'Content-Type: application/json' 
  -d '{
    "name": "High Error Rate Alert",
    "rule_type_id": "metrics.alert.threshold",
    "schedule": {"interval": "1m"},
    "params": {
      "criteria": [
        {
          "aggType": "count",
          "comparator": ">",
          "threshold": [50],
          "timeSize": 5,
          "timeUnit": "m",
          "filterQuery": "http.response.status_code >= 500"
        }
      ],
      "sourceId": "default"
    },
    "actions": []
  }'

Bu alarm, 5 dakika içinde 50’den fazla 5xx hatası olduğunda tetiklenir. Dashboard’unuza bu alarma karşılık gelen görselleştirmeyi koyarsanız, alarm geldiğinde direkt ilgili panele bakıp ne olduğunu görebilirsiniz.

Gerçek Dünya Dashboard’u: Nginx + Application Logs

Şimdi tam bir dashboard senaryosu kuralım. E-ticaret sitesi, Nginx önünde, arkada bir uygulama sunucusu var. İzlemek istediğiniz şeyler:

  • Saniye başına istek sayısı (RPS)
  • Hata oranı yüzdesi
  • Response time dağılımı (p50, p95, p99)
  • En çok hata veren endpoint’ler
  • Coğrafi kaynak dağılımı

Her biri için ayrı görselleştirme oluşturup bir dashboard’da birleştireceğiz.

RPS hesabı için Lens ile:

# KQL filtresi yok, tüm istekler
# Aggregation: Count / Date histogram (1 dakika interval)
# Bu size dakika başına istek verir, saniyeye çevirmek için 60'a bölün

Lens’te formül özelliği kullanarak bunu doğrudan hesaplayabilirsiniz: count() / 60

Response time percentile için Elasticsearch sorgusu:

curl -X POST "localhost:9200/filebeat-*/_search?pretty" 
  -H 'Content-Type: application/json' 
  -d '{
    "size": 0,
    "aggs": {
      "response_times": {
        "date_histogram": {
          "field": "@timestamp",
          "fixed_interval": "5m"
        },
        "aggs": {
          "percentiles": {
            "percentiles": {
              "field": "http.response.time_ms",
              "percents": [50, 95, 99]
            }
          }
        }
      }
    }
  }'

Bu sorgu size her 5 dakikalık dilimde p50, p95 ve p99 response time değerlerini verir. Kibana Lens’te bunu yapmak için Metrics’e “Percentile” aggregation ekleyip field olarak http.response.time_ms seçin, yüzde değerini de belirtin. Üç ayrı metrik satırı açarak p50, p95 ve p99’u aynı grafikte gösterirsiniz.

Dashboard’u Düzenlemek ve Panel Yerleşimi

Görselleştirmeleri oluşturduktan sonra Dashboards > Create Dashboard ile yeni bir dashboard açın ve Add from library ile önceden oluşturduğunuz görselleştirmeleri ekleyin.

Panel yerleşimi için bir tavsiye: en kritik metrikler sol üstte, detaylar altta. Gözün doğal okuma akışı sol üsten sağ alta doğru gittiği için önemli bilgileri buraya koyun.

Dashboard’u JSON olarak export edip Git’te saklamayı ve ortamlar arasında taşımayı alışkanlık haline getirin:

# Dashboard export
curl -X POST "localhost:5601/api/saved_objects/_export" 
  -H 'kbn-xsrf: true' 
  -H 'Content-Type: application/json' 
  -d '{
    "type": "dashboard",
    "includeReferencesDeep": true
  }' > dashboard_backup.ndjson

# Dashboard import
curl -X POST "localhost:5601/api/saved_objects/_import?overwrite=true" 
  -H 'kbn-xsrf: true' 
  -F file=@dashboard_backup.ndjson

includeReferencesDeep: true parametresi kritik, bunu kullanmazsanız dashboard ile birlikte görselleştirmeler ve index pattern’lar export edilmez, sadece dashboard kabuğu gelir.

Spaces ve Erişim Kontrolü

Büyük ekiplerde herkes aynı Kibana instance’ını kullanıyorsa Spaces özelliği hayat kurtarır. Farklı ekipler (network ekibi, uygulama ekibi, güvenlik ekibi) kendi Space’lerinde çalışır, birbirinin dashboard’larını karıştırmaz.

# Yeni Space oluşturma
curl -X POST "localhost:5601/api/spaces/space" 
  -H 'kbn-xsrf: true' 
  -H 'Content-Type: application/json' 
  -d '{
    "id": "network-ops",
    "name": "Network Operations",
    "description": "Network ekibi dashboard ve görselleştirmeleri",
    "color": "#00BFB3",
    "initials": "NO"
  }'

Elastic Stack Basic lisansında bile Spaces kullanabilirsiniz. Role-based access control (RBAC) için ise minimum Gold lisansı gerekiyor. Açık kaynak alternatif olarak önüne reverse proxy koyup basic auth ile erişimi sınırlayabilirsiniz, ama bu uzun vadede sürdürülebilir bir çözüm değil.

Canvas ile Operasyonel Sunumlar

Dashboard’lar teknik ekip için mükemmel ama yönetim sunumları için bazen daha “temiz” bir görünüm istenir. Kibana Canvas tam bu iş için var.

Canvas’ta piksel piksel kontrol edebilirsiniz ve SQL benzeri ifadeler kullanabilirsiniz:

# Canvas'ta kullanabileceğiniz Elasticsearch SQL örneği
# Bu ifadeyi Canvas workpad element'ine yazarsınız
SELECT 
  COUNT(*) as total_requests,
  SUM(CASE WHEN http.response.status_code >= 500 THEN 1 ELSE 0 END) as errors
FROM "filebeat-*"
WHERE "@timestamp" >= NOW() - INTERVAL 1 HOUR

Canvas’ı her gün kullanan biri değilim ama aylık ya da haftalık operasyonel raporlar için çok işe yarıyor. Özellikle “her şey yolunda” yeşil ekran görüntüsü üst yönetime göstermek için.

Performans ve Optimizasyon

Kibana dashboard’larınız yavaş açılıyorsa genellikle üç neden vardır: çok fazla panel, kötü yazılmış aggregation’lar, veya Elasticsearch’te yetersiz kaynak.

Panel sayısını 15-20’nin altında tutmaya çalışın. Daha fazlası gerekiyorsa dashboard’ı bölün.

Index lifecycle management (ILM) ile eski verileri hot-warm-cold mimarisine taşımak dashboard performansını ciddi artırır:

# ILM policy oluşturma
curl -X PUT "localhost:9200/_ilm/policy/logs-policy" 
  -H 'Content-Type: application/json' 
  -d '{
    "policy": {
      "phases": {
        "hot": {
          "actions": {
            "rollover": {
              "max_size": "50GB",
              "max_age": "7d"
            }
          }
        },
        "warm": {
          "min_age": "7d",
          "actions": {
            "forcemerge": {
              "max_num_segments": 1
            },
            "shrink": {
              "number_of_shards": 1
            }
          }
        },
        "cold": {
          "min_age": "30d",
          "actions": {
            "freeze": {}
          }
        },
        "delete": {
          "min_age": "90d",
          "actions": {
            "delete": {}
          }
        }
      }
    }
  }'

Bu yapıyla son 7 günün verisi hızlı SSD’de, daha eskisi daha yavaş ama ucuz depolamada tutulur. Dashboard’larınızı genellikle son 24-48 saat üzerinde çalıştırıyorsanız performans farkı dramatik olur.

Dashboard açılış süresini ölçmek için tarayıcı developer tools kullanabilirsiniz, ama daha sistematik bir yaklaşım için Kibana’nın kendi task manager API’sini izleyin:

# Kibana task manager durumunu kontrol et
curl -X GET "localhost:5601/api/task_manager/_health" 
  -H 'kbn-xsrf: true'

Bu endpoint size task kuyruğunun ne kadar dolu olduğunu, hangi task’ların geciktiğini gösterir. Özellikle çok sayıda aktif alert varsa bu endpoint sürekli izlenmeli.

Saved Searches ve Cross-Filter

Dashboard’lara bir görselleştirme ile birlikte “Saved Search” (Discover paneli) eklemeyi ihmal etmeyin. Bir grafikte anomali gördüğünüzde alttaki log satırlarına direkt bakabilmek, ayrı bir sekme açmaktan çok daha hızlı.

Kibana’nın cross-filter özelliği de çok güçlü: bir panel üzerinde bir değere tıkladığınızda bu filtreyi tüm dashboard’a uygular. Örneğin “En çok hata veren endpoint’ler” grafiğinde bir endpoint’e tıkladığınızda, dashboard’daki tüm diğer paneller otomatik olarak o endpoint’e göre filtrelenir. Bunu aktif etmek için herhangi bir konfigürasyon gerekmez, varsayılan olarak çalışır.

Birden fazla index’ten veri göstermeniz gerekiyorsa Cross-cluster search veya birden fazla Data View’ı aynı dashboard’da kullanabilirsiniz. Her panel kendi veri kaynağını seçebilir.

Sonuç

Kibana dashboard’ları bir kez kurulup unutulan şeyler değil. Sistemler değiştikçe, yeni servisler geldikçe, eski servisler gitince dashboard’larınızı güncellemeniz gerekiyor. Bunu bir kültür haline getirin. Yeni bir servis deploy etmeden önce “bu servisin logları nasıl görselleştirilecek?” sorusunu sormak, production’da sorun çıktığında saatler kazandırır.

Başlangıç için şunu öneririm: önce tek bir servis seçin, o servisin log formatını iyice anlayın, beş altı temel görselleştirme yapın ve bir dashboard’da birleştirin. Bu dashboard’ı bir hafta aktif kullanın, eksik gördüklerinizi not alın, sonra geliştirin. Mükemmel dashboard yoktur, sadece işe yarayan dashboard vardır.

Export/import alışkanlığını da şimdiden kurun. Dashboard’larınızı Git’te saklayın, her büyük değişikliği commit edin. Kibana versiyon yükseltmesi sırasında bir şeyler ters giderse bu yedeğin kıymetini anlarsınız.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir