Kibana Lens ile Gelişmiş Veri Analizi

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

Üretim ortamında yüzlerce sunucudan akan log verisiyle boğuşurken Kibana’nın klasik görselleştirme araçlarının yetersiz kaldığı anları hepimiz yaşadık. “Bu veriyi nasıl daha anlamlı hale getiririm?” sorusunu sormaya başladığınız noktada Lens devreye giriyor. Kibana Lens, 7.x sürümüyle hayatımıza giren ve drag-and-drop mantığıyla çalışan görsel analiz editörü. Ama aldatıcı derecede basit görünen arayüzünün altında ciddi analitik güç yatıyor.

Bu yazıda salt “Lens nasıl kullanılır” anlatmayacağım. Gerçek bir production ortamında karşılaşacağınız senaryolar üzerinden, Lens’in sunduğu gelişmiş özellikleri elimden geldiğince pratik bir bakış açısıyla aktarmaya çalışacağım.

Lens’i Klasik Visualize Editöründen Ayıran Şey Ne?

Eski Visualize editörüyle çalışmış olanlar bilir: her görselleştirme tipi ayrı bir zihinsel model gerektiriyordu. Bar chart için şu adımlar, line chart için bu adımlar. Lens bunu kökten değiştirdi.

Lens’in temel farkı field-aware olması. Yani bir alanı sürüklediğinizde Lens o alanın veri tipini anlıyor ve size mantıklı agregasyon önerileri sunuyor. response_time gibi numeric bir alanı sürükleyince otomatik olarak Average, Median, Percentile önerileri geliyor. log.level gibi keyword bir alanı sürükleyince Top Values önerisi çıkıyor.

Ama asıl güç formula editöründe ve katmanlı görselleştirme yapısında saklı. Bunları sırasıyla inceleyelim.

Temel Index Pattern Ayarı ve Veri Hazırlığı

Lens’e geçmeden önce index pattern’larınızın düzgün yapılandırılmış olması gerekiyor. Özellikle zaman bazlı analizler için @timestamp alanının doğru tanımlanması kritik.

# ILM policy ile index pattern oluşturma
curl -X PUT "localhost:9200/_index_template/syslog-template" 
  -H "Content-Type: application/json" 
  -d '{
    "index_patterns": ["syslog-*"],
    "template": {
      "settings": {
        "number_of_shards": 1,
        "number_of_replicas": 1
      },
      "mappings": {
        "properties": {
          "@timestamp": {
            "type": "date"
          },
          "response_time": {
            "type": "float"
          },
          "status_code": {
            "type": "integer"
          },
          "log.level": {
            "type": "keyword"
          },
          "host.name": {
            "type": "keyword"
          },
          "bytes_sent": {
            "type": "long"
          }
        }
      }
    }
  }'

Mapping’i doğru tanımlamak Lens’in öneri sistemini doğrudan etkiliyor. Float olarak tanımlanmamış bir response_time alanı için Lens percentile önerisi sunmayabilir ya da yanlış agregasyon tipini default yapabilir.

Formula Editörü: Gerçek Güç Burada

Lens’in en az konuşulan ama en çok işe yarayan özelliği formula editörü. Önceden tanımlı agregasyonların ötesine geçip kendi hesaplamalarınızı yazabiliyorsunuz.

Tipik bir senaryo: Nginx log’larından error oranını hesaplamak istiyorsunuz. Yani toplam istek sayısı içinde 5xx dönen isteklerin yüzdesi. Bunu eski yöntemlerle görselleştirmek için ya iki ayrı görsel yapıp kendiniz yorumlardınız ya da painless script yazardınız. Lens formula editörüyle:

count(kql='status_code >= 500') / count() * 100

Bu kadar. Formülü yazıyorsunuz, Lens real-time olarak hesaplıyor. KQL sorgularını formula içine gömebilmeniz özellikle güçlü. Bazı kullanışlı formula örnekleri:

# P95 / P50 oranı - latency spike tespiti için
percentile(response_time, percentile=95) / percentile(response_time, percentile=50)

# Başarı oranı
count(kql='status_code < 400') / count() * 100

# Önceki dönemle karşılaştırma (shift fonksiyonu)
count() - count(shift='1d')

# Moving average ile düzleştirilmiş metrik
moving_average(count(), window=10)

shift fonksiyonu özellikle haftalık veya günlük karşılaştırmalar için müthiş. Cuma akşamı ani bir trafik artışı mı var? count() / count(shift='1w') * 100 formülüyle geçen haftayla yüzde bazlı karşılaştırma yapabilirsiniz.

Katmanlı Görselleştirme ile Anomali Tespiti

Lens’in katman (layer) sistemi, tek bir grafikte birden fazla metriği anlamlı şekilde bir araya getirmenizi sağlıyor. Bunu production ortamında en çok response time anomalisi tespitinde kullanıyorum.

Şöyle bir yapı düşünün: Birinci katmanda bar chart olarak request count, ikinci katmanda line chart olarak P95 latency. İkisini aynı grafikte gördüğünüzde yük artışının latency’ye ne zaman yansıdığını saniye saniye takip edebilirsiniz.

Bu tür analizleri desteklemek için Logstash pipeline’ınızda önceden bazı hesaplamaların yapılmış olması işinizi kolaylaştırır:

# logstash pipeline - response time kategorilendirme
filter {
  if [response_time] {
    ruby {
      code => "
        rt = event.get('response_time').to_f
        if rt < 100
          event.set('latency_bucket', 'fast')
        elsif rt < 500
          event.set('latency_bucket', 'normal')
        elsif rt < 2000
          event.set('latency_bucket', 'slow')
        else
          event.set('latency_bucket', 'critical')
        end
      "
    }
  }
}

Bu latency_bucket alanını Lens’te breakdown olarak kullandığınızda stacked bar chart ile latency dağılımını zaman içinde takip edebilirsiniz.

Dashboard’a Özel KQL Filtreleri ile Drill-Down Analizi

Lens görselleştirmeleri dashboard’a eklendiğinde filtreleme mekanizması devreye giriyor. Ancak Lens’in “by reference” ve “by value” kaydetme modları arasındaki farkı bilmek önemli.

“By reference” kaydettiğinizde görselleştirme birden fazla dashboard’da paylaşılır ama bir dashboard’da yaptığınız filter değişikliği diğerlerini etkilemez. “By value” kaydettiğinizde görselleştirme o dashboard’a özgü olur, daha esnek özelleştirme yapabilirsiniz. Production ortamında genel monitoring dashboard’ları için “by reference”, ekip bazlı özelleştirilmiş analizler için “by value” tercih ediyorum.

Dashboard seviyesinde kontrol amaçlı dinamik filtreler eklemek için:

# Kibana saved objects API ile dashboard filter tanımlama
curl -X POST "localhost:5601/api/saved_objects/dashboard" 
  -H "kbn-xsrf: true" 
  -H "Content-Type: application/json" 
  -d '{
    "attributes": {
      "title": "Production Monitoring",
      "kibanaSavedObjectMeta": {
        "searchSourceJSON": "{"query":{"language":"kuery","query":""},"filter":[{"meta":{"disabled":false,"negate":false,"alias":"Production Only"},"query":{"match_phrase":{"environment":"production"}}}]}"
      }
    }
  }'

Lens ile Cohort Analizi

Bu konuya çok az kaynak değiniyor ama Lens’te basit cohort analizleri yapmak mümkün. Örneğin belirli bir deployment sonrası error rate’in zaman içinde nasıl değiştiğini görmek istiyorsunuz.

Önce Elasticsearch’te gerekli veriyi hazırlayalım:

# Deployment event'ini index'leme
curl -X POST "localhost:9200/deployments/_doc" 
  -H "Content-Type: application/json" 
  -d '{
    "@timestamp": "2024-01-15T14:30:00Z",
    "version": "v2.4.1",
    "service": "payment-api",
    "environment": "production",
    "deployer": "ci-pipeline"
  }'

Lens’te bu yaklaşımı şöyle uygulayabilirsiniz: annotation katmanı ekleyerek deployment event’larını ana metrik grafiğinizin üzerine işaretleyin. Kibana 8.x ile gelen “Annotations” özelliği Lens içinde doğrudan çalışıyor. Böylece “v2.4.1 deploy edildikten 20 dakika sonra error rate %3’ten %8’e çıkmış” gibi ilişkiyi görsel olarak yakalayabilirsiniz.

Veri Tablosu Görünümünde Conditional Formatting

Lens’in tablo görünümü ilk bakışta sıradan görünse de conditional formatting özelliği onu gerçek bir monitoring aracına dönüştürüyor. Hangi sunucunun response time eşiğini aştığını renk kodlamasıyla anında görebilmek operasyonel hayatı kolaylaştırıyor.

Bu özelliği en iyi kullanan yapı, multi-host response time tablosu:

# Her host için P95 latency hesaplayan Elasticsearch aggregation
# Lens bunu otomatik yapıyor ama arka planda şuna benzer sorgu üretiyor
curl -X POST "localhost:9200/nginx-logs-*/_search" 
  -H "Content-Type: application/json" 
  -d '{
    "size": 0,
    "aggs": {
      "by_host": {
        "terms": {
          "field": "host.name",
          "size": 50
        },
        "aggs": {
          "p95_latency": {
            "percentiles": {
              "field": "response_time",
              "percents": [95]
            }
          },
          "error_rate": {
            "filter": {
              "range": {
                "status_code": {"gte": 500}
              }
            }
          },
          "total_requests": {
            "value_count": {
              "field": "request_id"
            }
          }
        }
      }
    }
  }'

Lens’te bu tabloyu oluşturduktan sonra P95 sütununa conditional formatting uygulayın: 500ms altı yeşil, 500-2000ms arası sarı, 2000ms üzeri kırmızı. Sabah geldiğinizde bir bakışta hangi sunucuların sorunlu olduğunu görürsünüz.

Runtime Fields ile Lens Entegrasyonu

Elasticsearch’ün runtime fields özelliği Lens analizlerini bambaşka bir boyuta taşıyor. Index’e veri yazmadan yeni hesaplanmış alanlar tanımlayabiliyorsunuz. Bu özellikle log formatını değiştiremediğiniz legacy sistemlerde altın değerinde.

# Runtime field tanımlama - Kibana Data View üzerinden
curl -X PUT "localhost:9200/nginx-logs-*/_mapping" 
  -H "Content-Type: application/json" 
  -d '{
    "runtime": {
      "is_slow_request": {
        "type": "boolean",
        "script": {
          "source": "emit(doc['''response_time'''].value > 1000)"
        }
      },
      "response_category": {
        "type": "keyword",
        "script": {
          "source": """
            int status = doc['status_code'].value;
            if (status < 200) emit('informational');
            else if (status < 300) emit('success');
            else if (status < 400) emit('redirect');
            else if (status < 500) emit('client_error');
            else emit('server_error');
          """
        }
      },
      "cost_per_request": {
        "type": "double",
        "script": {
          "source": "emit(doc['response_time'].value * 0.00001)"
        }
      }
    }
  }'

Runtime field olarak tanımladığınız response_category alanını Lens’te breakdown olarak kullandığınızda, orijinal integer status_code alanına dokunmadan kategori bazlı analizler yapabiliyorsunuz. cost_per_request gibi iş odaklı metrikler ekleyerek teknik verileri iş değerine dönüştürebilirsiniz.

Lens API ile Programatik Görselleştirme

Kibana’nın Saved Objects API’si ile Lens görselleştirmelerini programatik olarak yönetmek mümkün. Bu özellikle infrastructure-as-code yaklaşımı benimsemiş ekipler için önemli. Yeni bir servis deploy ettiğinizde otomatik olarak o servise ait monitoring dashboard’u oluşturabilirsiniz.

#!/bin/bash
# Yeni servis için otomatik Lens paneli oluşturma scripti

SERVICE_NAME=$1
KIBANA_URL="http://localhost:5601"

create_lens_visualization() {
  local service=$1
  
  curl -X POST "${KIBANA_URL}/api/saved_objects/lens" 
    -H "kbn-xsrf: true" 
    -H "Content-Type: application/json" 
    -d "{
      "attributes": {
        "title": "${service} - Error Rate",
        "visualizationType": "lnsXY",
        "state": {
          "datasourceStates": {
            "formBased": {
              "layers": {
                "layer1": {
                  "columns": {
                    "col1": {
                      "label": "@timestamp",
                      "dataType": "date",
                      "operationType": "date_histogram",
                      "sourceField": "@timestamp",
                      "params": {"interval": "auto"}
                    },
                    "col2": {
                      "label": "Error Rate %",
                      "dataType": "number",
                      "operationType": "formula",
                      "params": {
                        "formula": "count(kql='status_code >= 500 AND service.name: \\"${service}\\"') / count(kql='service.name: \\"${service}\\"') * 100"
                      }
                    }
                  },
                  "columnOrder": ["col1", "col2"]
                }
              }
            }
          }
        }
      }
    }"
}

create_lens_visualization $SERVICE_NAME
echo "Dashboard created for service: $SERVICE_NAME"

Bu tür script’leri CI/CD pipeline’ınıza entegre ettiğinizde, yeni bir mikroservis production’a alındığında otomatik monitoring görselleştirmeleri hazır hale gelir.

Performans Optimizasyonu: Lens Sorgularını Hızlandırma

Lens güçlü ama yanlış kullanıldığında Elasticsearch cluster’ınıza ciddi yük bindirebilir. Özellikle büyük zaman aralıkları ve granüler histogram’lar tehlikeli olabiliyor.

Lens’in ürettiği sorguları Kibana’nın “Inspect” panelinden görebilirsiniz. Yavaş bir görselleştirmede hemen oraya bakın. Genellikle sorun şu noktalardan birinden çıkıyor:

  • Wildcard index pattern’ı: logs- yerine logs-2024. kullanın, gerekirse tarih filtresi ekleyin
  • Yüksek cardinality breakdown: Top Values’da size değerini gereksiz yüksek tutmayın, 10-20 yeterli
  • Nested formula’lar: Çok katmanlı formula’lar birden fazla aggregation pass gerektirebilir
  • Küçük histogram interval: “auto” genellikle iyi çalışır, ama özellikle belirtirseniz çok küçük değer vermeyin
# Elasticsearch'te yavaş query'leri tespit etme
curl -X GET "localhost:9200/_nodes/hot_threads?threads=5&type=search" 
  -H "Content-Type: application/json"

# Index-level shard allocation ve cache durumu
curl -X GET "localhost:9200/nginx-logs-*/_stats/query_cache,request_cache" 
  | python3 -m json.tool | grep -A5 "query_cache"

Dashboard’larınızı production’a almadan önce mutlaka “Inspect > Request” panelinden üretilen sorguyu inceleyin ve Elasticsearch’ün ne kadar sürede yanıt verdiğini kontrol edin. 5 saniyeyi geçen görselleştirmeler hem kullanıcı deneyimini hem de cluster sağlığını olumsuz etkiler.

Gerçek Dünya Senaryosu: SLA Dashboard’u

Tüm bu özellikleri bir araya getiren gerçek bir senaryo anlatayım. E-ticaret platformu için %99.9 uptime SLA’sı olan bir sistemde aylık SLA raporunu Lens ile otomatik hale getirmiştik.

Hedef: Her ay son 30 günün SLA metriklerini gösterecek, otomatik güncellenen bir dashboard.

Bunun için üç temel görselleştirme:

1. Uptime Yüzdesi: Formula (count(kql='status_code < 500') / count()) * 100 ile hesaplanıyor, threshold annotation olarak %99.9 çizgisi işaretlenmiş.

2. Toplam Downtime Süresi: Her 5 dakikalık bucket’ta error rate %50’yi geçiyorsa o bucket “down” sayılıyor. Bu hesaplamayı Lens formula ile doğrudan yapamıyorsunuz, bunun için önceden Elasticsearch transform job’u hazırlanması gerekiyor:

# SLA hesaplama için Elasticsearch transform job
curl -X PUT "localhost:9200/_transform/sla-calculator" 
  -H "Content-Type: application/json" 
  -d '{
    "source": {
      "index": ["nginx-logs-*"]
    },
    "pivot": {
      "group_by": {
        "time_bucket": {
          "date_histogram": {
            "field": "@timestamp",
            "fixed_interval": "5m"
          }
        }
      },
      "aggregations": {
        "total_requests": {"value_count": {"field": "request_id"}},
        "error_requests": {
          "filter": {"range": {"status_code": {"gte": 500}}},
          "aggs": {
            "count": {"value_count": {"field": "request_id"}}
          }
        },
        "error_rate": {
          "bucket_script": {
            "buckets_path": {
              "errors": "error_requests>count",
              "total": "total_requests"
            },
            "script": "params.total > 0 ? params.errors / params.total * 100 : 0"
          }
        }
      }
    },
    "dest": {
      "index": "sla-metrics"
    },
    "sync": {
      "time": {
        "field": "@timestamp",
        "delay": "60s"
      }
    }
  }'

Bu transform job’u başlattıktan sonra sla-metrics index’ini Lens’te kaynak olarak kullanabilirsiniz. Artık Lens formula’larınız çok daha hafif sorgular üretiyor çünkü veriler önceden özetlenmiş halde.

3. P95 Latency Trend’i: Moving average ile düzleştirilmiş moving_average(percentile(response_time, percentile=95), window=12) formülü, anlık spike’ları filtreler ve gerçek trend’i gösterir.

Bu dashboard’u Kibana’nın reporting özelliğiyle PDF’e çevirip aylık otomatik email göndermek SLA raporlama sürecini tamamen otomatik hale getirebilir.

Sonuç

Kibana Lens, doğru kullanıldığında ELK stack’inizin en değerli analiz katmanına dönüşebilir. Formula editörü ile runtime fields kombinasyonu, data pipeline’ınıza dokunmadan inanılmaz derecede esnek analizler yapmanıza imkan tanıyor. Katmanlı görselleştirme yapısı ise tek bir grafik üzerinde bağlam zenginleştirmesi yapmanızı sağlıyor.

Benim tavsiyem: Lens’i öğrenmeye formula editörüyle başlayın. Basit bir count(kql='...') formülü yazın, nasıl davrandığını görün. Sonra shift fonksiyonunu ekleyin ve zaman karşılaştırmaları yapmaya başlayın. Runtime fields’ı keşfettiğinizde ise log pipeline’ınıza dokunmadan yapabileceğiniz şeylerin sınırını zorlayabilirsiniz.

Son olarak performans konusunu atlamamak gerekiyor. Güçlü bir araç her zaman dikkatli kullanım gerektiriyor. Özellikle 7/24 açık olan production dashboard’larınızda Inspect panelini düzenli kontrol edin, gereksiz yük bindiren görselleştirmeleri optimize edin. Cluster’ınıza iyi bakarsanız, Lens de size iyi bakar.

Bir yanıt yazın

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