ELK Stack Güncelleme ve Sürüm Yükseltme Rehberi

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

Üretim ortamında ELK Stack güncellemesi yapmak, gece 2’de telefonun çaldığı senaryolardan birini tetikleyebilir. Bunu bir kez yaşadıktan sonra insan artık bu işe daha ciddiye alıyor. Bu yazıda hem Elasticsearch, hem Logstash, hem de Kibana’yı sürüm yükseltme sürecini, gerçek dünya notlarıyla birlikte ele alacağız. Versiyon 7.x’ten 8.x’e geçiş senaryosunu merkeze alacağız ama genel prensipler diğer geçişler için de geçerli.

Neden Bu Kadar Dikkat Gerekiyor?

ELK Stack güncellemeleri, basit bir apt upgrade işlemi değil. Elasticsearch özelinde konuşursak, index mapping’leri, cluster state’i ve snapshot repoları gibi kritik yapılar söz konusu. Yanlış adım attığınızda veri kaybı değil belki ama saatler süren downtime çok mümkün.

Bir fintech müşterisinde 6 node’luk bir cluster’da 7.17’den 8.x’e geçiş yaparken yaşanan sorunların %80’i hazırlık aşamasında yapılan eksikliklerden kaynaklanıyordu. Snapshot almamak, deprecation uyarılarını görmezden gelmek, cluster health’i yeşil zannetmek ama aslında sarıda bırakmak gibi.

Güncelleme Öncesi Hazırlık

Bu aşamayı atlarsanız, geri kalan her şey şans oyununa dönüşür.

Mevcut Durumu Belgeleme

Önce neyle çalıştığınızı net bilin:

# Elasticsearch sürümünü ve cluster durumunu kontrol et
curl -s http://localhost:9200/ | python3 -m json.tool

# Cluster health durumu
curl -s "http://localhost:9200/_cluster/health?pretty"

# Node bilgileri
curl -s "http://localhost:9200/_nodes?pretty" | grep -A5 '"version"'

# Index listesi ve boyutları
curl -s "http://localhost:9200/_cat/indices?v&h=index,health,status,pri,rep,docs.count,store.size&s=store.size:desc"

Bu çıktıları bir yere kaydedin. Güncelleme sonrasında karşılaştırma yapacaksınız.

Deprecation API ile Sorunları Önceden Tespit Etme

8.x’e geçişin en sık sorun çıkaran noktası, 7.x’te çalışan ama 8.x’te kaldırılan özellikler. Bunu önceden görmek için:

# Deprecation uyarılarını listele
curl -s "http://localhost:9200/_migration/deprecations?pretty"

# Index bazlı deprecation kontrolü
curl -s "http://localhost:9200/_migration/deprecations/index_name?pretty"

Çıktıda critical seviyesinde uyarı varsa, bunları çözmeden geçiş yapmayın. warning seviyesindekiler de mümkünse temizlensin.

Snapshot Almak

Bu adımı “zaman kaybı” olarak görüyorsanız, yanlış düşünüyorsunuz. Snapshot olmadan güncelleme, emniyet kemeri takmadan araba kullanmak gibi.

# Önce snapshot repository tanımla (NFS mount veya S3 kullanıyorsanız ayarlı olmalı)
curl -X PUT "http://localhost:9200/_snapshot/my_backup" -H 'Content-Type: application/json' -d'
{
  "type": "fs",
  "settings": {
    "location": "/mnt/elasticsearch_backup",
    "compress": true
  }
}'

# Tüm index'lerin snapshot'ını al
curl -X PUT "http://localhost:9200/_snapshot/my_backup/snapshot_pre_upgrade?wait_for_completion=true" -H 'Content-Type: application/json' -d'
{
  "indices": "*",
  "ignore_unavailable": true,
  "include_global_state": true
}'

# Snapshot durumunu kontrol et
curl -s "http://localhost:9200/_snapshot/my_backup/snapshot_pre_upgrade?pretty"

state: SUCCESS görene kadar bir sonraki adıma geçmeyin.

Güncelleme Stratejisi: Rolling Upgrade vs Full Restart

Üretim ortamında rolling upgrade (yuvarlayan güncelleme) tercih edilmeli. Bu yöntemde cluster çalışmaya devam eder, node’lar tek tek güncellenir. Full restart ise downtime gerektirir, küçük ortamlar veya test sistemleri için kabul edilebilir.

Rolling upgrade için cluster’ın önce green durumda olması şart. yellow veya red durumdaki cluster’da rolling upgrade yapmayın.

Shard Allocation’ı Devre Dışı Bırakma

Güncelleme sırasında Elasticsearch’ün shard’ları başka node’lara taşımasını engellemeniz gerekiyor. Yoksa her node restart’ında gereksiz shard hareketleri olur ve hem zaman kaybedersiniz hem de I/O patlaması yaşarsınız.

# Shard allocation'ı devre dışı bırak
curl -X PUT "http://localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
  "persistent": {
    "cluster.routing.allocation.enable": "primaries"
  }
}'

# Sync flush (7.x için, 8.x'te kaldırıldı)
curl -X POST "http://localhost:9200/_flush/synced"

Elasticsearch Güncelleme Adımları

Şimdi gerçek işe geliyoruz. Debian/Ubuntu tabanlı sistemler için:

# Önce servis durdur
sudo systemctl stop elasticsearch

# GPG anahtarını güncelle (8.x için yeni anahtar gerekebilir)
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg

# 8.x repo ekle
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list

# Güncellemeyi yap
sudo apt-get update
sudo apt-get install elasticsearch=8.11.0

# Konfigürasyon dosyasını kontrol et
# Güncelleme sırasında .dpkg-new uzantılı yeni config dosyası oluşur
ls -la /etc/elasticsearch/

# elasticsearch.yml değişikliklerini birleştir
diff /etc/elasticsearch/elasticsearch.yml /etc/elasticsearch/elasticsearch.yml.dpkg-new

8.x’e geçişte elasticsearch.yml dosyasında dikkat edilmesi gereken önemli değişiklikler var. Özellikle xpack.security.enabled artık varsayılan olarak true geliyor. Bu, iç ağda güvensiz kurulum yapıyorsanız, ilk başlatmada sizi şaşırtabilir.

# Servisi başlat ve logları izle
sudo systemctl start elasticsearch
sudo journalctl -u elasticsearch -f

# Birkaç dakika sonra cluster durumunu kontrol et
curl -s "http://localhost:9200/_cluster/health?pretty"

Node başarıyla başladıktan ve cluster’a katıldıktan sonra bir sonraki node’a geçin. Aralarında en az 5-10 dakika bekleyin, shard dengelemesinin tamamlanmasını izleyin.

Tüm node’lar güncellendikten sonra allocation’ı tekrar açın:

# Shard allocation'ı yeniden etkinleştir
curl -X PUT "http://localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
  "persistent": {
    "cluster.routing.allocation.enable": null
  }
}'

Logstash Güncelleme

Logstash tarafı biraz daha affedici ama yine de dikkat gerektiriyor. Pipeline konfigürasyonlarınız 8.x ile uyumlu mu, bunu kontrol etmeniz lazım.

# Önce mevcut pipeline config'ini yedekle
sudo cp -r /etc/logstash/conf.d/ /root/logstash_backup_$(date +%Y%m%d)/

# Servisi durdur
sudo systemctl stop logstash

# Güncelle
sudo apt-get install logstash=1:8.11.0-1

# Config test et (kritik adım, atlamayın)
sudo /usr/share/logstash/bin/logstash --config.test_and_exit -f /etc/logstash/conf.d/

# Test geçtiyse servisi başlat
sudo systemctl start logstash

# Log takibi
sudo journalctl -u logstash -f

Logstash’te 8.x ile gelen önemli bir değişiklik: Java 11 minimum gereksinim. Sistemde eski Java sürümü varsa Logstash başlamaz. Bunu önceden kontrol edin:

java -version
# Çıktı en az "openjdk version 11" olmalı

# Gerekirse Java güncelle
sudo apt-get install openjdk-17-jdk

Kibana Güncelleme

Kibana, Elasticsearch ile aynı sürümde olmalı. Bu kural esnek değil. Kibana 8.11 ile Elasticsearch 7.17 çalışmaz.

# Kibana'yı durdur
sudo systemctl stop kibana

# Mevcut saved objects'ları dışa aktar (Kibana UI'dan da yapılabilir)
# API ile:
curl -s "http://localhost:5601/api/saved_objects/_export" 
  -H 'kbn-xsrf: true' 
  -H 'Content-Type: application/json' 
  -d '{"type": ["dashboard","visualization","index-pattern"], "includeReferencesDeep": true}' 
  > /root/kibana_objects_backup_$(date +%Y%m%d).ndjson

# Kibana'yı güncelle
sudo apt-get install kibana=8.11.0

# kibana.yml'yi gözden geçir
# 8.x'te enrollment token mekanizması geldi, bunu anlamanız gerekiyor
sudo nano /etc/kibana/kibana.yml

# Servisi başlat
sudo systemctl start kibana

# Logları izle, migration işlemi başlayana kadar bekle
sudo journalctl -u kibana -f

Kibana ilk başladığında .kibana index’ini 8.x formatına migrate eder. Bu işlem index boyutuna göre birkaç dakika alabilir. Log’da [savedobjects-service] READY görene kadar sabırlı olun.

7.x’ten 8.x’e Geçişte Güvenlik Değişiklikleri

8.x’in en büyük kırılma noktası güvenlik. Daha önce xpack.security.enabled: false ile çalışan ortamlar için bu geçiş ciddi konfigurasyon gerektiriyor.

Eğer iç ağda, güvenlik olmadan çalışıyorsanız ve bunu korumak istiyorsanız:

# elasticsearch.yml dosyasına ekle
# DİKKAT: Bu üretim ortamı için önerilmez, sadece iç ağ test ortamları için
xpack.security.enabled: false
xpack.security.http.ssl.enabled: false
xpack.security.transport.ssl.enabled: false

Güvenliği açık tutmak istiyorsanız (önerilen), ilk kurulumda üretilen şifreyi kaydetmeniz gerekiyor:

# Elasticsearch kurulumu sırasında ekrana yazılan şifreyi kaçırdıysanız
sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic

# Kibana'nın Elasticsearch'e bağlanması için service account token oluştur
sudo /usr/share/elasticsearch/bin/elasticsearch-service-tokens create elastic/kibana kibana-token

Bu token’ı kibana.yml dosyasına ekleyin:

# kibana.yml
elasticsearch.serviceAccountToken: "AAEAAWVsYXN0..."

Sorun Giderme: Sık Karşılaşılan Durumlar

Cluster Kırmızıya Düştüyse

# Hangi shard'lar unassigned?
curl -s "http://localhost:9200/_cluster/allocation/explain?pretty"

# Red index'leri bul
curl -s "http://localhost:9200/_cat/indices?v&health=red"

# Gerekirse shard'ları manuel olarak yeniden tahsis et
curl -X POST "http://localhost:9200/_cluster/reroute?retry_failed=true"

Eski Index’ler 8.x’te Açılmıyorsa

Elasticsearch 8.x, 6.x veya öncesinde oluşturulmuş index’leri doğrudan açmıyor. Bu durumda reindex gerekiyor:

# Eski index'i yeni bir index'e kopyala
curl -X POST "http://localhost:9200/_reindex" -H 'Content-Type: application/json' -d'
{
  "source": {
    "index": "eski_index_v6"
  },
  "dest": {
    "index": "eski_index_v8"
  }
}'

Logstash Pipeline Durdu

# Pipeline durumunu kontrol et
curl -s "http://localhost:9600/_node/pipelines?pretty"

# Dead letter queue dolu mu?
ls -lh /var/lib/logstash/dead_letter_queue/

# DLQ temizle (gerekirse)
sudo systemctl stop logstash
sudo rm -rf /var/lib/logstash/dead_letter_queue/*
sudo systemctl start logstash

Güncelleme Sonrası Doğrulama

Güncelleme tamamlandı, her şey yeşil görünüyor. Ama bitmedi. Doğrulama adımlarını atlamayın:

# Tüm node'ların aynı sürümde olduğunu kontrol et
curl -s "http://localhost:9200/_nodes?pretty" | grep '"version"' | sort | uniq -c

# Cluster istatistiklerini öncesiyle karşılaştır
curl -s "http://localhost:9200/_cluster/stats?pretty" | grep -E '"count"|"docs"'

# Index mapping'lerinin sağlam olduğunu kontrol et
curl -s "http://localhost:9200/_all/_mapping?pretty" | head -100

# Kibana'da dashboard'ların açılıp açılmadığını test et
# Logstash'e birkaç test log'u gönder ve Kibana'da göründüğünü doğrula

Özellikle Logstash pipeline’larını stres testine tabi tutun. Güncelleme sonrası ilk saatte trafik altında beklenmedik davranışlar olabilir.

Rollback Planı

Her zaman geri dönüş planınız olsun. Snapshot aldıysanız rollback yapılabilir, ama bu pahalı bir operasyon.

Daha pratik yaklaşım: Güncelleme öncesinde VM snapshot’ı alın (Elasticsearch snapshot’ından farklı). Bir şeyler ters giderse birkaç dakikada geri dönebilirsiniz. Elasticsearch snapshot restore ise saat alabilir.

# Snapshot'tan restore (son çare)
curl -X POST "http://localhost:9200/_snapshot/my_backup/snapshot_pre_upgrade/_restore?pretty" 
  -H 'Content-Type: application/json' -d'
{
  "indices": "*",
  "ignore_unavailable": true,
  "include_global_state": false,
  "rename_pattern": "(.+)",
  "rename_replacement": "restored_$1"
}'

Sonuç

ELK Stack güncellemesi, adım adım gidildiğinde yönetilebilir bir işlem. Panikle yapılan, hazırlıksız atlatılmaya çalışılan güncellemeler sorun çıkarıyor. Şu üç prensibi aklınızdan çıkarmayın:

Önce snapshot, sonra her şey. Snapshot almadan güncelleme yapmayın, ne kadar acil görünse de.

Deprecation uyarılarını ciddiye alın. 7.x’te sessiz sedasız çalışan bir şey, 8.x’te startup’ı tamamen engelleyebilir.

Bir node’u güncelleyip gözlemleyin, acele etmeyin. Rolling upgrade’in gücü burada. İlk node’da sorun görürseniz geri adım atma şansınız var.

Büyük bir cluster’da ilk güncellemeyi mesai saatlerinde değil, düşük trafik saatlerinde yapmanızı öneririm. Sabah 3-5 arası ideal pencere. Ve evet, o saatte de alarmlarınız açık olsun.

Bir yanıt yazın

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