Elasticsearch 8.1.3’ten 9.3.0’a Yükseltme Rehberi: Adım Adım Versiyon Geçiş Stratejisi

Elasticsearch cluster’ınızı 8.1.3 gibi eski bir sürümden 9.3.0 nesline taşımak, sıradan bir güncelleme değil; veri motorunun (Lucene), güvenlik protokollerinin ve küme yönetiminin evrimleşmesidir. Bu rehberde, 2 Node’lu bir yapıda sıfır veri kaybı hedefleyerek uyguladığımız “Bridge Upgrade” (Köprü Yükseltme) stratejisini inceliyoruz.

---

Bölüm 1: Operasyon Öncesi Hazırlık ve “Veri Sigortası” (Snapshot)

Sistem yöneticiliğinde “deneme-yanılma” veri katmanında yapılmaz. Majör geçişlerde geri dönüşün tek yolu fiziksel ve mantıksal yedeklemedir.

1.1. Cluster Sağlık Kontrolü (Health Check)

Upgrade maratonuna başlamadan önce, kümenizin nefes alışını kontrol etmelisiniz. Eğer cluster durumunuz “Yellow” veya “Red” ise, sorunu çözmeden asla bir üst sürüme geçmeyin.

Terminal üzerinden kontrol:

curl -X GET "localhost:9200/_cluster/health?pretty"

Burada görmeniz gereken tek değer “status”: “green” olmalıdır.

1.2. Fiziksel Yedekleme Dizinini Tanımlama (path.repo)

Multi-node (çoklu düğüm) mimarilerde en kritik nokta, tüm node’ların aynı yedekleme dizinine erişebilmesidir. Biz bu senaryoda, kurumsal standartlara uygun olarak her iki node’a da mount edilmiş paylaşımlı bir disk alanı (NFS, SAN veya Shared Disk) kullanıyoruz.

Her iki node üzerinde de şu adımları izleyin:

1. Dizini Oluşturun ve Yetki Verin:

mkdir -p /data/elasticsearch/backup
chown -R elasticsearch:elasticsearch /data/elasticsearch/backup

2. /etc/elasticsearch/elasticsearch.yml Dosyasını Güncelleyin: Dosyanın en altına şu satırı ekleyin. Bu ayar olmadan Elasticsearch güvenlik gereği yedekleme işlemini reddedecektir.

# Snapshot repository dizini tanımlama
path.repo: ["/data/elasticsearch/backup"]

3. Servisleri Restart Edin: Ayarların okunması için node’ları sırayla yeniden başlatın:

systemctl restart elasticsearch.service

1.3. Snapshot Repository: Dijital Sigortanız

Şimdi Elasticsearch’e bu fiziksel dizini bir “mantıksal repository” olarak tanıtalım.

Kibana Dev Tools üzerinden:

PUT /_snapshot/full_backup_repo
{
  "type": "fs",
  "settings": {
    "location": "/data/elasticsearch/backup",
    "compress": true
  }
}

1.4. Tam Yedekleme (Full Snapshot) Başlatma

Şimdi, 8.1.3 versiyonundaki tüm verilerimizi koruma altına alıyoruz. Bu işlem, majör sürüm yükseltmesindeki en büyük can simidimizdir.

PUT /_snapshot/full_backup_repo/pre_upgrade_snapshot?wait_for_completion=true
{
  "indices": "*",
  "ignore_unavailable": true,
  "include_global_state": true
}

Kritik Not: wait_for_completion=true parametresi hayati önem taşır. Bu sayede yedekleme işlemi bitene kadar terminal oturumu kapanmaz ve işlemin sonunda "state": "SUCCESS" ibaresini görmeden bir sonraki aşamaya (paket güncellemesine) geçmenizi engeller.

---

Bölüm 2: Ara Durak Stratejisi – 8.19.x Köprüsü

Elasticsearch dünyasında 8.x sürümünden 9.x sürümüne geçmek, sadece yeni özellikler kazanmak değil, altyapıdaki veri motorunun (Lucene) standartlarını tamamen değiştirmek demektir. 8.1.3 sürümü ile 9.3.0 arasında ciddi bir “versiyon boşluğu” bulunur ve bu boşluğu doğrudan atlamaya çalışmak küme bütünlüğünü (cluster integrity) bozabilir.

2.1. Neden Doğrudan Geçiş Yapılamaz? (Lucene Uyumluluğu)

Elasticsearch 9.3.0, kendinden bir önceki majör sürümün (8.x) sadece en güncel haliyle optimize edilmiş indexlerini hatasız okuyabilir. 8.19.x sürümü, 8.x serisinin “final” noktasıdır ve 9.x nesline geçiş için gereken Upgrade Assistant aracının en gelişmiş versiyonunu barındırır.

• Stratejimiz: 8.1.3 ➔ 8.19.x (Köprü) ➔ 9.3.0

2.2. Rolling Upgrade (Kesintisiz Güncelleme) Nedir?

Sistemimizi kapatmadan, kullanıcılarımızı üzmeden güncelleme yapmak için “Rolling Upgrade” yöntemini izleyeceğiz. Bu yöntemde node’ları teker teker güncelleyeceğiz:

1. Node-2’yi durdur ve güncelle.
2. Node-2’yi cluster’a dahil et ve verilerin senkronize olmasını bekle.
3. Aynı işlemi Node-1 için tekrarla.

2.3. Adım Adım 8.19.x Güncellemesi (Uygulama Fazı)

1. Shard Allocation’ı Devre Dışı Bırakın ve Bellekteki verileri diske kalıcı olarak yaz:

Node-2’yi kapattığımızda Master’ın (Node-1) “Eyvah, bir node gitti! Verileri hemen kopyalamalıyım!” diyerek network ve disk trafiğini yormasını istemiyoruz. Sadece ana verilerin (primary) çalışmasına izin verip kopyalamayı durduruyoruz:

# Shard allocation kısıtla (Sadece primary shard'lara izin ver)
curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
{
  "persistent": {
    "cluster.routing.allocation.enable": "primaries"
  }
}'

# Bellekteki verileri diske kalıcı olarak yaz
curl -X POST "localhost:9200/_flush?pretty"

2. Node-2’yi Güncelleyin (Önce Slave Node): Node-2 üzerinde Elasticsearch servisini durdurun ve 8.17.x paketini kurun:

# Servisi nazikçe durdurun
sudo systemctl stop elasticsearch

# 8.19.x paketini indirin ve kurun
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.19.0-x86_64.rpm
sudo rpm -Uvh elasticsearch-8.19.0-x86_64.rpm

“Exit Code 78” hatasının burada karşımıza çıkması muhtemeldir. İşi şansa bırakmadan yetkileri verelim:

sudo chown -R elasticsearch:elasticsearch /etc/elasticsearch/
sudo chown elasticsearch:elasticsearch /etc/elasticsearch/elasticsearch.keystore
sudo chmod 660 /etc/elasticsearch/elasticsearch.keystore

3. Kritik Sistem Ayarları (Timeout ve RAM Yönetimi)

Burada iki büyük engelle karşılaşabiliriz: Timeout ve Exit Code 137 (OOM Killer). Bunları önceden çözmeliyiz.

• Timeout Ayarı: Yeni versiyon ilk açılışta eski indexleri tarayacağı için 90 saniyelik standart açılış süresi yetmeyebilir. Süreyi 10 dakikaya çıkaralım:

sudo systemctl edit elasticsearch
# Açılan dosyaya şu iki satırı güncelleyin ve kaydedin:
[Service]
TimeoutStartSec=600
NotifyAccess=all

• JVM Heap Size Ayarı: Eğer sunucunuzun RAM’i kısıtlıysa, /etc/elasticsearch/jvm.options dosyasını kontrol edin. Toplam RAM’in %50’sinden fazlasını ayırmadığınızdan emin olun (Örn: 8GB RAM için -Xms4g -Xmx4g).

4. Servisi Başlatma ve Manuel Debug

Servisi başlatırken arka planda neler döndüğünü canlı görmek için manuel başlatma yöntemini tercih edebilirsiniz:

# Önce systemd'yi yenileyin
sudo systemctl daemon-reload

# Hataları canlı izlemek için manuel başlatma (Opsiyonel ama tavsiye edilir)
sudo -u elasticsearch /usr/share/elasticsearch/bin/elasticsearch

Loglarda [Node-2] started yazısını gördüğünüzde, node 8.19.x sürümüyle hizmete hazır demektir.

5. Shard Allocation’ı Tekrar Açın

Node-2 ayağa kalktığında, kısıtlamayı kaldırarak cluster’ın verileri senkronize etmesine izin veriyoruz:

curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
{
  "persistent": {
    "cluster.routing.allocation.enable": null
  }
}'

6. KRİTİK ADIM: Recovery (İyileşme) Takibi

“Wait for the node to recover” kısmını buradan izliyoruz. Shard’lar v9 formatına uyum sağlarken bu adımı bitirmeden başka bir işlem yapma:

# 1. Cluster sağlığını izle (status 'yellow' veya 'green' olmalı)
curl -X GET "localhost:9200/_cat/health?v"

# 2. Shard recovery durumunu detaylı gör
curl -X GET "localhost:9200/_cat/recovery?v&active_only=true"

Eğer active_only=true komutu boş dönüyorsa, tüm shard’lar başarıyla v9.3.0 üzerinde kurtarılmış demektir.

7. Son Kontroller

“Güncelleme sonrası sadece loglara güvenmeyin; cluster’ın yeni sürümü gerçekten tanıyıp tanımadığını API üzerinden doğrulayın. _cat/nodes çıktısında Node-2’nin karşısında 8.19.0 yazısını görmek, bir sonraki node’a geçmek için en güvenli yeşil ışıktır.”

curl -X GET "localhost:9200/_cat/nodes?v&h=name,version,node.role,master,status"
name     version node.role master
elastic1 8.1.3   dimr      *
elastic2 8.19.0  dir       -

curl -X GET "localhost:9200/_cluster/health?pretty"
{
  "cluster_name" : "elastic-cluster",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 2,
  "number_of_data_nodes" : 2,
  "active_primary_shards" : 20,
  "active_shards" : 40,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0,
  "unassigned_primary_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}

7: Manuelden Servis Moduna Geçiş

Eğer terminalde hala loglar akıyorsa CTRL + C ile durdur. Eğer terminali çoktan kapattıysan ama arka planda çalışıyorsa şu komutla süreci bul ve bitir:

# Elasticsearch'ün PID'sini (kimlik numarası) bul ve durdur
ps -ef | grep elasticsearch | grep -v grep | awk '{print $2}' | xargs -r sudo kill -9

Manuel başlatırken bazen dosya sahiplikleri değişebilir. Servis olarak çalışması için her şeyin elasticsearch kullanıcısına ait olduğundan emin olalım:

sudo chown -R elasticsearch:elasticsearch /var/lib/elasticsearch
sudo chown -R elasticsearch:elasticsearch /var/log/elasticsearch
sudo chown -R elasticsearch:elasticsearch /etc/elasticsearch
sudo chown -R elasticsearch:elasticsearch /usr/share/elasticsearch

Şimdi işletim sistemine “Elasticsearch’ü sen yönet” diyoruz:

# Yapılandırmayı yenile
sudo systemctl daemon-reload

# Başlangıçta otomatik çalışması için etkinleştir
sudo systemctl enable elasticsearch

# Servis olarak başlat
sudo systemctl start elasticsearch

2.4. Master Node (Node-1) İçin Süreci Tekrarlayın

Önceki adımda elastic2 (data node) için yaptıklarının aynen aynısını şimdi elastic1 (master node) için de uyguluyoruz. Elasticsearch mimarisinde “yükseltme” mantığı rollerden bağımsızdır.

---

Bölüm 3: Elastic Stack’te Uyumun Gücü – Kibana ve Logstash v8.19 Upgrade Rehberi

Elasticsearch’ü v8.19 sürümüne başarıyla yükselttikten sonra (Bölüm 2’de yaptığımız gibi), sıra ekosistemin diğer iki devine geldi: Kibana ve Logstash. Unutulmamalıdır ki; Elasticsearch her zaman stack içerisindeki en yüksek sürüme sahip olmalı veya diğer bileşenlerle aynı sürümde tutulmalıdır.

Bu yazıda, v8.1.3 sürümünden v8.19 sürümüne güvenli geçiş prosedürlerini adım adım inceleyeceğiz.

3.1. Kibana Yükseltme (8.1.3 → 8.19)

Kibana, Elasticsearch ile doğrudan konuşan görselleştirme arayüzüdür. Versiyon farkı oluştuğunda “Version Mismatch” hataları kaçınılmazdır.

A. Servis Durdurma ve Yedekleme

İşleme başlamadan önce mevcut servisleri durduruyoruz.

sudo systemctl stop kibana

Not: Kibana’nın kendi veri dizini yoktur, tüm ayarları Elasticsearch içindeki .kibana indekslerinde tutulur. Bu yüzden Elasticsearch yedeğinizin olması Kibana’nın da güvende olması demektir.

B. Paket Güncelleme

Repo üzerinden veya RPM paketleri ile güncellemeyi başlatıyoruz:

sudo rpm -Uvh kibana-8.19.0-x86_64.rpm

C: Servisi Başlatma ve Log Takibi

Yeni binary dosyalarını tanıtıp servisi ayağa kaldıralım. Kibana ilk açılışta bazı sistem indekslerini optimize edebilir:

sudo systemctl daemon-reload
sudo systemctl start kibana
sudo journalctl -u kibana -f

3.2. Logstash Yükseltme (8.1.3 → 8.19)

Logstash, veri boru hattınızdır (pipeline). Bu adımda en kritik nokta, veri kaybını önlemek için mevcut akışın (ingest) düzgün kapatılmasıdır.

A. Servis Durdurma

İşleme başlamadan önce mevcut servisleri durduruyoruz.

sudo systemctl stop logstash

B. Paket Güncelleme

Repo üzerinden veya RPM paketleri ile güncellemeyi başlatıyoruz:

sudo rpm -Uvh logstash-8.19.0-x86_64.rpm

C: Servisi Başlatma ve Log Takibi

Yeni binary dosyalarını tanıtıp servisi ayağa kaldıralım. Kibana ilk açılışta bazı sistem indekslerini optimize edebilir:

sudo systemctl daemon-reload
sudo systemctl start logstash
sudo journalctl -u logstash -f

🔍 Upgrade Sonrası Kritik Kontroller

Tüm Stack 8.19.0 olduktan sonra v9’a geçmeden önce şu 3 noktayı mutlaka kontrol edin:

1. Versiyon Kontrolü: curl -X GET "localhost:9200" ile ES sürümünü, Kibana arayüzünde “About” kısmından Kibana sürümünü teyit edin.
2. Cluster Health: _cat/health üzerinden durumun green veya yellow olduğunu görün.
3. Upgrade Assistant: Kibana içerisinde Stack Management > Upgrade Assistant menüsüne gidin. Burası size v9.x’e geçiş için “Critical” veya “Warning” veren tüm maddeleri listeleyecektir.

---

Bölüm 4: Büyük Dönüşüm Başlıyor – Elasticsearch v9.x Upgrade

8.19.0 durağında tüm hazırlıklarımızı tamamladık. Şimdi sistemin kalbi olan Elasticsearch’ü v9.x sürümüne taşıyoruz. Bu aşama, v8 serisine veda ettiğimiz ve v9’un getirdiği performans iyileştirmelerine (Synthetic Source, Vector Search geliştirmeleri vb.) kapı açtığımız yerdir.

4.1: Upgrade Assistant Kontrolü

Yükseltme işlemine başlamadan önce Kibana üzerinden Stack Management > Upgrade Assistant menüsüne giriyoruz. Bu araç, v9’a geçişte “ölümcül” bir engel olup olmadığını denetler.

Az önce yaptığımız analizde gördüğümüz gibi, ekranımızdaki tablo şu an oldukça umut verici:

• System Indices Migration: “System indices migration not needed” uyarısı, v8.19.0’ın tüm iç hazırlıkları tamamladığını gösteriyor. Bu, v9’a geçişin teknik olarak “temiz” bir zeminde olduğunu kanıtlar.
• Critical Issues: Hiçbir kırmızı (Kritik) hata yok. Sadece Elasticsearch ve Kibana tarafında birkaç adet Warning (Sarı) uyarısı mevcut. Bu uyarılar upgrade işlemine engel değildir; sadece v9 sonrası bazı ayarların modern isimleriyle güncellenmesi gerektiğini hatırlatır.

4.2. Adım: Cluster’ı Güvene Alma (Snapshot ve Shard Kilidi)

Sistemi durdurmadan önce verilerin güvenliği ve hızlı kurtarma (recovery) için şu iki komutu çalıştırmalısınız:

1. Senkronize Flush (Veriyi Diske Yazma)

Hafızadaki (memory) tüm verilerin diske güvenle yazıldığından emin olmak için:

POST _cache/clear

POST _flush/synced

> Not: v8.x ve üzerinde _flush/synced komutu bazen uyarı verebilir, eğer hata alırsanız sadece POST _flush komutunu kullanabilirsiniz.

2. Mevcut Durumu Sorgulama (Opsiyonel)

Ayarların başarıyla uygulanıp uygulanmadığını kontrol etmek için:

GET _cluster/settings

{
  "persistent": {
    "cluster": {
      "routing": {
        "allocation": {
          "enable": "primaries"
        }
      }
    },
    "xpack": {
      "monitoring": {
        "collection": {
          "enabled": "true"
        }
      }
    }
  },
  "transient": {}
}

4.3. Adım: İlk Hamle – Master Olmayan (Data) Node Upgrade

Rolling Upgrade kuralı gereği, cluster bütünlüğünü bozmamak için her zaman önce Master rolü olmayan node’dan başlıyoruz.

v8’den v9’a geçerken node’lar arasındaki sürüm farkı geçici bir dengesizlik yaratabilir. Bu trafiği yönetmek için Master node (Node-1) üzerinden şu komutları verin:

# Shard hareketliliğini sadece primary shard'lara kısıtla
curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
{
  "persistent": { "cluster.routing.allocation.enable": "primaries" }
}'

Node’u Durdurun:

sudo systemctl stop elasticsearch

Manuel Paketi Yükleyin:

sudo rpm -Uvh elasticsearch-9.3.0-x86_64.rpm

Yükleme sonrası /etc/elasticsearch/elasticsearch.yml dosyanızı kontrol edin. Bizim gibi güvenliksiz (No-Security) modda çalışan sistemler için şu satırın varlığı hayati önem taşır:

xpack.security.enabled: false

Elasticsearch v9 varsayılan olarak ML özelliklerini çok daha agresif bir şekilde başlatmaya çalışır. Eğer ML kullanmıyorsan (ki genelde bu aşamada kapalı tutmak en sağlıklısıdır), şu adımları izle: vi /etc/elasticsearch/elasticsearch.yml

xpack.ml.enabled: false

Sistem servislerini yenileyip Elasticsearch v9.3.0’ı uyandırıyoruz:

sudo systemctl daemon-reload
sudo systemctl start elasticsearch

Cluster’daki node’ların durumunu sorgulayın. Burada elastic2‘nin sürümünü 9.3.0, elastic1‘in sürümünü ise hala 8.19.0 olarak görmelisiniz.

curl -X GET "localhost:9200/_cat/nodes?v&h=name,version,role,master"
name     version role master
elastic1 8.19.0  dimr *
elastic2 9.3.0   dir  -

Not: master sütununda elastic1 yanında yıldız (*) işareti olmalı. Bu, v9 olan node’un v8 olan master’a başarıyla bağlandığını gösterir.

Node-2 servisini başlattıktan sonra, v9 yüklü node’un verileri kabul edebilmesi için Master üzerinden kısıtlamayı kaldırmalısınız:

curl -X PUT "localhost:9200/_cluster/settings?pretty" -H 'Content-Type: application/json' -d'
{
  "persistent": { "cluster.routing.allocation.enable": "all" }
}'

Shard’ların durumunu kontrol edin. Başlangıçta shard’lar INITIALIZING veya RELOCATING durumunda olabilir, bir süre sonra STARTED haline gelmelidir.

curl -X GET "localhost:9200/_cat/shards?v"

Cluster Sağlığı: Durumun Green (Yeşil) olduğundan emin olun.

curl -X GET "localhost:9200/_cluster/health?pretty"
{
  "cluster_name" : "elastic-cluster",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 2,
  "number_of_data_nodes" : 2,
  "active_primary_shards" : 56,
  "active_shards" : 112,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0,
  "unassigned_primary_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}

4.4. Adım: Final Sahnesi – Master Node (Node-1) Güncellemesi

Tüm Data node’lar (Node-2 ve varsa diğerleri) başarıyla v9.3.0 sürümüne geçtiğine ve cluster sağlığı tekrar “Green” olduğuna göre, artık cluster’ın liderini (Master Node) güncelleyebiliriz.

Altın Kural: Rolling upgrade süreçlerinde Master node her zaman en son güncellenir. Çünkü v9 bir Master, v8 bir node’u yönetmekte zorlanabilir; ancak v8 bir Master (şu anki Node-1), v9 bir node’u (Node-2) geçiş sürecinde başarıyla idare edebilir.

Bu aşamada yapılacak işlemler (Servis durdurma, v9 paket kurulumu, izinlerin düzenlenmesi ve servisin başlatılması), 4.3. Adım’da Node-2 için uygulanan teknik adımların birebir aynısıdır. > Kritik Hatırlatma: Node-1 (Master) kapandığında, halihazırda v9 olan Node-2 otomatik olarak “Master” rolünü üstlenecektir. Bu beklenen bir davranış olup, yükseltme bittiğinde liderlik tekrar dengelenecektir.

---

Bölüm 5: v9.3.0 Ekosistem Uyumu – Kibana ve Logstash Final Geçişi

Elasticsearch v9.3.0 zirvesine ulaştığımıza göre, artık görselleştirme ve veri işleme katmanlarını da bu yeni nesil mimariye taşımamız gerekiyor. Elastic Stack kuralı nettir: Bileşenler arasındaki sürüm farkı, özelliklerin devre dışı kalmasına veya bağlantı kopukluklarına yol açabilir.

5.1. Kibana Yükseltme (8.19.0 → 9.3.0)

Kibana v9, v8’deki dashboard’larınızı ve ayarlarınızı otomatik olarak devralır. Ancak Elasticsearch v9 ile tam uyumlu çalışması için binary dosyalarının güncellenmesi şarttır.

A. Servis Durdurma Güncelleme sırasında dosya çakışmalarını önlemek için servisi durduruyoruz:

sudo systemctl stop kibana

B. Paket Güncelleme v9.3.0 RPM paketini indirip mevcut sürümün üzerine kuruyoruz:

sudo rpm -Uvh kibana-9.3.0-x86_64.rpm

C. Yetki ve Servis Başlatma v9 geçişlerinde bazen optimize edilen dosyalar için izin gerekebilir:

sudo chown -R kibana:kibana /etc/kibana/
sudo systemctl daemon-reload
sudo systemctl start kibana

# Başlatma sürecini (Optimize adımlarını) takip edin:
sudo journalctl -u kibana -f

5.2. Logstash Yükseltme (8.19.0 → 9.3.0)

Logstash v9, v8 ile hazırladığınız .conf dosyalarınızı (pipeline) tanımaya devam eder. Ancak v9 ile gelen performans iyileştirmeleri ve yeni plugin destekleri için yükseltme elzemdir.

A. Pipeline Güvenliği ve Durdurma Önce veri akışını nazikçe durdurun:

sudo systemctl stop logstash

B. Paket Güncelleme v9.3.0 paketini sisteme entegre edelim:

sudo rpm -Uvh logstash-9.3.0-x86_64.rpm

C. Başlatma ve Veri Akışı Kontrolü

sudo systemctl daemon-reload
sudo systemctl start logstash

# Verilerin Elasticsearch'e akıp akmadığını loglardan izleyin:
sudo tail -f /var/log/logstash/logstash-plain.log

---

Bölüm 6: v9.3.0 Sonrası Kritik Yapılandırma – Güvenlik ve Şifreleme Anahtarları

Elasticsearch ve ekosistemini v9.3.0 sürümüne yükselttikten sonra, Kibana arayüzünde “Monitoring Request Error” veya “Encrypted Saved Objects” uyarılarıyla karşılaşmanız muhtemeldir. v9 neslinde “Alerting” (Alarm), “Reporting” ve “Security” özelliklerinin kararlı çalışması için sistem artık sabit şifreleme anahtarlarının tanımlanmasını şart koşmaktadır.

6.1. Şifreleme Anahtarları Neden Önemlidir?

v8 ve öncesinde bu anahtarlar boş bırakıldığında Kibana her açılışta geçici anahtarlar üretiyordu. Ancak v9 mimarisinde;

• Oturum Yönetimi: Servis her restart edildiğinde kullanıcıların sistemden atılmaması,
• Alarmlar (Alerting): Oluşturulan alarmların şifrelenmiş şekilde saklanabilmesi,
• Raporlama: PDF ve CSV çıktılarının güvenli oluşturulması için bu anahtarların kibana.yml içerisinde sabitlenmesi gerekir.

6.2. Adım Adım Anahtar Yapılandırması

1. Güvenli Anahtarları Üretin

Kibana’nın kurulu olduğu sunucuda, sistemin sizin için 32 karakterli güvenli rastgele anahtarlar üretmesini sağlayın:

/usr/share/kibana/bin/kibana-encryption-keys generate

## Kibana Encryption Key Generation Utility

The 'generate' command guides you through the process of setting encryption keys for:

xpack.encryptedSavedObjects.encryptionKey
    Used to encrypt stored objects such as dashboards and visualizations
    https://www.elastic.co/guide/en/kibana/current/xpack-security-secure-saved-objects.html#xpack-security-secure-saved-objects

xpack.reporting.encryptionKey
    Used to encrypt saved reports
    https://www.elastic.co/guide/en/kibana/current/reporting-settings-kb.html#general-reporting-settings

xpack.security.encryptionKey
    Used to encrypt session information
    https://www.elastic.co/guide/en/kibana/current/security-settings-kb.html#security-session-and-cookie-settings


Already defined settings are ignored and can be regenerated using the --force flag.  Check the documentation links for instructions on how to rotate encryption keys.
Definitions should be set in the kibana.yml used configure Kibana.

Settings:
xpack.encryptedSavedObjects.encryptionKey: 9b916129baa0edab153dd8e09a161fac
xpack.reporting.encryptionKey: d0820132cee7ac8f7150f8b580febfa2
xpack.security.encryptionKey: 1fe57e29e16a26aa51940cc2752d65f9

2. Yapılandırma Dosyasını Güncelleyin

Üretilen anahtarları kopyalayın ve /etc/kibana/kibana.yml dosyasının sonuna ekleyin:

sudo vi /etc/kibana/kibana.yml

Dosyaya eklenecek örnek satırlar (Kendi ürettiğiniz anahtarları kullanın):

xpack.encryptedSavedObjects.encryptionKey: 9b916129baa0edab153dd8e09a161fac
xpack.reporting.encryptionKey: d0820132cee7ac8f7150f8b580febfa2
xpack.security.encryptionKey: 1fe57e29e16a26aa51940cc2752d65f9

3. Servisi Yeniden Başlatın

Yapılandırmanın devreye girmesi için Kibana servisini restart edin:

sudo systemctl restart kibana

6.3. Sonuç: “Error 24” ve Monitoring Hatalarının Çözümü

Servis yeniden başladığında Kibana loglarında SavedObjects service has completed migrations and is available mesajını göreceksiniz. Arayüzü yenilediğinizde kırmızı hata pencerelerinin kaybolduğunu ve tüm monitoring özelliklerinin (v9 performans grafiklerinin) aktifleştiğini görebilirsiniz.

Profesyonel İpucu: Bu anahtarları güvenli bir yerde (Password Manager vb.) saklayın. Gelecekte bir node değişimi veya felaket kurtarma (disaster recovery) durumunda aynı anahtarları kullanmanız, eski alarmlarınızın ve kayıtlı objelerinizin okunabilmesi için kritiktir.