InfluxDB Retention Policy Kurulum ve Yönetimi

Zaman serisi veritabanlarıyla çalışırken en çok göz ardı edilen konulardan biri disk yönetimidir. InfluxDB’ye metrik atmaya başlarsınız, her şey güzel gider, ama birkaç ay sonra disk dolmaya başlar ve ne yapacağınızı bilemezsiniz. İşte tam bu noktada Retention Policy devreye girer. Bu yazıda InfluxDB’nin veri saklama mekanizmasını derinlemesine inceleyecek, gerçek dünya senaryolarıyla nasıl yapılandırılacağını göstereceğiz.

Retention Policy Nedir?

Retention Policy, Türkçeye “saklama politikası” olarak çevirebileceğimiz, InfluxDB’nin verilerinizi ne kadar süre tutacağını ve nasıl depolayacağını belirleyen bir yapılandırma birimidir. Bir veritabanına bağlı olarak çalışır ve şu üç temel parametreyi içerir:

DURATION: Verinin ne kadar süre saklanacağı
REPLICATION: Kaç kopyanın tutulacağı (cluster kurulumlar için önemli)
SHARD DURATION: Her bir shard’ın ne kadar zaman dilimini kapsayacağı

InfluxDB 1.x ile çalışıyorsanız Retention Policy kavramını doğrudan kullanırsınız. InfluxDB 2.x’te bu kavram “bucket” yapısıyla birleştirilmiş olsa da mantık aynıdır. Bu yazıda her iki versiyonu da ele alacağız, ancak örneklerin büyük çoğunluğu 1.x üzerine yoğunlaşacak çünkü üretim ortamlarında hâlâ yaygın olarak kullanılıyor.

InfluxDB 1.x’te Retention Policy Temelleri

Mevcut Durumu Kontrol Etme

Herhangi bir şey yapmadan önce mevcut retention policy’leri görmek iyi bir başlangıç noktasıdır. InfluxDB CLI’a bağlanıp şunu çalıştırın:

influx -host localhost -port 8086

CLI’a girdikten sonra mevcut veritabanınızı seçin ve politikaları listeleyin:

USE telegraf
SHOW RETENTION POLICIES ON telegraf

Bu komut size şuna benzer bir çıktı verecektir:

name    duration  shardGroupDuration  replicaN  default
----    --------  ------------------  --------  -------
autogen 0s        168h0m0s            1         true

Burada duration: 0s değeri dikkat çekicidir. Bu değer, verinin sonsuza kadar saklanacağı anlamına gelir. Yeni kurulumda varsayılan olarak bu şekilde gelir ve üretim ortamında bırakmak ciddi disk sorunlarına yol açar.

Yeni Retention Policy Oluşturma

Diyelim ki Telegraf ile sunucu metriklerinizi topluyorsunuz ve bu verileri 30 gün saklamak istiyorsunuz:

CREATE RETENTION POLICY "otuz_gun" ON "telegraf" DURATION 30d REPLICATION 1 DEFAULT

Bu komutu parçalayalım:

“otuz_gun”: Politikanın adı, anlamlı isimler seçin
ON “telegraf”: Hangi veritabanına uygulanacağı
DURATION 30d: 30 günlük saklama süresi
REPLICATION 1: Tek node kurulumda 1 olmalı
DEFAULT: Bu politikayı varsayılan yap

Süre formatları için şu kısaltmaları kullanabilirsiniz:

ns: Nanosaniye
u veya µ: Mikrosaniye
ms: Milisaniye
s: Saniye
m: Dakika
h: Saat
d: Gün
w: Hafta
INF: Sonsuz

Mevcut Retention Policy’yi Güncelleme

Zaten var olan bir politikayı değiştirmek için ALTER komutunu kullanırsınız:

ALTER RETENTION POLICY "autogen" ON "telegraf" DURATION 90d REPLICATION 1 DEFAULT

Dikkat edin: Retention Policy süresini kısalttığınızda, eski shard’lar silinene kadar bir miktar gecikme olabilir. InfluxDB bu silme işlemini arka planda yapar, anlık değildir.

Gerçek Dünya Senaryosu: Katmanlı Saklama Stratejisi

Üretim ortamlarında sık karşılaşılan ihtiyaç şudur: Bazı verileri kısa süre yüksek çözünürlükte, bazılarını ise uzun süre düşük çözünürlükte saklamak istiyorsunuzdur. Örneğin CPU metriklerini 1 saniye aralıkla topluyorsunuzdur ama 6 ay önceki CPU verisini 1 saatlik ortalamalarla görmek yeterlidir.

Bu senaryo için birden fazla Retention Policy ve Continuous Query kombinasyonu kullanırız.

Adım 1: Veritabanı ve Politikaları Oluşturun

CREATE DATABASE metriks

CREATE RETENTION POLICY "ham_veri" ON "metriks" DURATION 7d REPLICATION 1 DEFAULT

CREATE RETENTION POLICY "haftalik_ozet" ON "metriks" DURATION 52w REPLICATION 1

CREATE RETENTION POLICY "aylik_ozet" ON "metriks" DURATION INF REPLICATION 1

Burada üç katman oluşturduk:

ham_veri: 7 günlük ham, yüksek çözünürlüklü veri
haftalik_ozet: 1 yıllık, 5 dakikalık ortalamalar
aylik_ozet: Sonsuz, saatlik ortalamalar

Adım 2: Continuous Query’leri Tanımlayın

Continuous Query’ler, InfluxDB’nin belirli aralıklarla otomatik olarak çalıştırdığı sorgulardır. Veriyi bir politikadan alıp özetleyerek başka bir politikaya yazan bu yapı, bizim katmanlı sistemimizin kalbidir:

CREATE CONTINUOUS QUERY "cq_5dk_ozet" ON "metriks"
BEGIN
  SELECT mean("value") AS "mean_value"
  INTO "metriks"."haftalik_ozet"."cpu_usage"
  FROM "metriks"."ham_veri"."cpu_usage"
  GROUP BY time(5m), *
END

CREATE CONTINUOUS QUERY "cq_1saat_ozet" ON "metriks"
BEGIN
  SELECT mean("value") AS "mean_value", max("value") AS "max_value", min("value") AS "min_value"
  INTO "metriks"."aylik_ozet"."cpu_usage"
  FROM "metriks"."haftalik_ozet"."cpu_usage"
  GROUP BY time(1h), *
END

Bu yapıyla artık:

Son 7 gün için saniye saniye CPU verisi görürsünüz
Son 1 yıl için 5 dakikalık ortalamalar mevcuttur
Tüm geçmiş için saatlik min/max/ortalama değerler saklanır

Continuous Query’lerin Durumunu Kontrol Etme

SHOW CONTINUOUS QUERIES

Eğer bir Continuous Query çalışmıyorsa veya sorun yaşıyorsanız InfluxDB loglarını kontrol edin:

journalctl -u influxdb -f | grep "continuous"

InfluxDB 2.x’te Bucket ve Retention

InfluxDB 2.x’e geçtiyseniz ya da geçmeyi düşünüyorsanız, Retention Policy artık “bucket” kavramının içinde yaşıyor. Her bucket oluştururken bir retention süresi belirliyorsunuz.

Bucket Oluşturma ve Retention Ayarı

influx bucket create 
  --name telegraf_metriks 
  --retention 30d 
  --org myorg 
  --token YOUR_TOKEN

Mevcut bucket’ları listelemek için:

influx bucket list --org myorg --token YOUR_TOKEN

Var olan bir bucket’ın retention süresini güncellemek için önce bucket ID’sini öğrenmeniz gerekir:

influx bucket update 
  --id BUCKET_ID 
  --retention 60d 
  --org myorg 
  --token YOUR_TOKEN

InfluxDB 2.x’te Continuous Query yerini Tasks aldı. Aynı katmanlı saklama stratejisini Flux diliyle şöyle uygularsınız:

influx task create --flux '
option task = {name: "downsample_cpu", every: 5m}

from(bucket: "telegraf_metriks")
  |> range(start: -5m)
  |> filter(fn: (r) => r["_measurement"] == "cpu")
  |> aggregateWindow(every: 5m, fn: mean, createEmpty: false)
  |> to(bucket: "telegraf_ozet", org: "myorg")
' --org myorg --token YOUR_TOKEN

Shard Yönetimi ve Performans

Retention Policy’nin önemli ama çoğu zaman göz ardı edilen bir parçası da shard duration’dır. InfluxDB verileri zaman aralıklarına göre shard adı verilen gruplara böler. Her shard bağımsız bir TSM dosyası kümesidir.

Varsayılan shard duration değerleri şöyledir:

2 saatten kısa retention: 1 saatlik shardlar
2 saat ile 6 ay arası retention: 1 günlük shardlar
6 aydan uzun retention: 7 günlük shardlar

Ama bu değerleri manuel olarak değiştirebilirsiniz:

CREATE RETENTION POLICY "uzun_vade" ON "metriks" DURATION 365d REPLICATION 1 SHARD DURATION 24h DEFAULT

Shard duration küçüldükçe daha fazla shard dosyası oluşur, bu da bazı sorgularda daha fazla dosya okuması anlamına gelir. Shard duration büyüdükçe tek bir silme işlemi daha uzun sürer ama dosya sayısı azalır.

Mevcut shard gruplarını görmek için:

SHOW SHARD GROUPS ON "metriks"

Bu çıktı size hangi shard gruplarının ne zaman başlayıp bittiğini ve ne zaman silineceğini gösterir. Disk baskısı yaşıyorsanız bu bilgi çok değerlidir.

Disk Kullanımını İzleme ve Yönetme

Retention Policy’yi doğru yapılandırdıktan sonra işin bittiğini düşünmeyin. Düzenli izleme şart.

InfluxDB’nin veri dizinini kontrol edin:

du -sh /var/lib/influxdb/data/*

Her veritabanı klasörünün boyutunu görmek için:

du -sh /var/lib/influxdb/data/telegraf/

WAL (Write Ahead Log) dizini de dolabilir:

du -sh /var/lib/influxdb/wal/

InfluxDB’nin kendi istatistiklerini sorgulamak da mümkündür:

SELECT * FROM "_internal"."monitor"."database" WHERE time > now() - 1h

Bu sorgu size veritabanı bazında seri sayısını, measurement sayısını ve diğer istatistikleri gösterir.

Erken Silme: Manuel Shard Temizliği

Bazen bir Retention Policy’yi kısalttığınızda eski veriler hemen silinmez. InfluxDB shard’ların süresinin dolmasını bekler. Eğer acil disk alanı gerekiyorsa shard’ları manuel silebilirsiniz:

SHOW SHARDS ON "telegraf"

Bu komut size shard ID’lerini ve expiry tarihlerini gösterir. Süresi dolmuş bir shard’ı zorla silmek için:

DROP SHARD 15

Ama dikkatli olun, bu işlem geri alınamaz.

Üretim Ortamı için Önerilen Yapılandırma

Bir monitoring stack kuruyorsanız ve Telegraf + InfluxDB + Grafana kullanıyorsanız, şu yapılandırmayı başlangıç noktası olarak alabilirsiniz:

# Veritabanını oluştur
CREATE DATABASE monitoring

# Ham veri için 14 günlük politika
CREATE RETENTION POLICY "ham_14gun" ON "monitoring" 
  DURATION 14d 
  REPLICATION 1 
  SHARD DURATION 1d 
  DEFAULT

# Özet veri için 1 yıllık politika  
CREATE RETENTION POLICY "ozet_1yil" ON "monitoring" 
  DURATION 365d 
  REPLICATION 1 
  SHARD DURATION 7d

# Arşiv için sonsuz politika
CREATE RETENTION POLICY "arsiv" ON "monitoring" 
  DURATION INF 
  REPLICATION 1 
  SHARD DURATION 30d

Telegraf yapılandırmanızda hangi Retention Policy’ye yazacağınızı belirtebilirsiniz:

# /etc/telegraf/telegraf.conf içinde outputs.influxdb bölümü

[[outputs.influxdb]]
  urls = ["http://localhost:8086"]
  database = "monitoring"
  retention_policy = "ham_14gun"
  username = "telegraf"
  password = "gizli_sifre"

Yaygın Hatalar ve Çözümleri

Hata 1: Varsayılan Politikayı Değiştirmeyi Unutmak

Yeni bir politika oluşturduğunuzda DEFAULT keyword’ünü eklemeyi unutursanız, veriler eski politikaya yazmaya devam eder. Mevcut durumu doğrulayın:

SHOW RETENTION POLICIES ON "monitoring"

Çıktıda default sütununa bakın. Yanlış politika varsayılan olarak işaretliyse:

ALTER RETENTION POLICY "ham_14gun" ON "monitoring" DEFAULT

Hata 2: Continuous Query Aralığı ile Retention Uyumsuzluğu

Diyelim ki ham verinizi 1 saatlik Retention Policy ile saklıyorsunuz ama Continuous Query’niz her 2 saatte bir çalışıyor. Bu durumda bazı veri noktalarını kaybedersiniz çünkü CQ çalıştığında kaynak veri artık mevcut değildir. Genel kural: Continuous Query aralığı her zaman kaynak Retention Policy süresinin en az yarısından kısa olmalıdır.

Hata 3: Silinen Retention Policy Sonrası Orphan Shardlar

Bir Retention Policy’yi silerseniz o politikaya ait shardlar otomatik silinmeyebilir:

# Orphan shard'ları bul
SHOW SHARDS
# Gözlemleyin, hangi shardların artık geçerli bir RP'si yok

# InfluxDB servisini yeniden başlatmak genellikle temizler
systemctl restart influxdb

Retention Policy’yi Otomasyon ile Yönetme

Büyük ortamlarda Retention Policy oluşturmayı ve yönetmeyi script’lerle otomatize etmek akıllıca bir yaklaşımdır. Aşağıdaki bash scripti, belirtilen veritabanları için standart üç katmanlı politikayı otomatik olarak uygular:

#!/bin/bash

INFLUX_HOST="localhost"
INFLUX_PORT="8086"
INFLUX_USER="admin"
INFLUX_PASS="adminpassword"

DATABASES=("telegraf" "app_metriks" "network_metriks")

for DB in "${DATABASES[@]}"; do
  echo "[$DB] Retention policy yapılandırılıyor..."
  
  influx -host "$INFLUX_HOST" -port "$INFLUX_PORT" 
    -username "$INFLUX_USER" -password "$INFLUX_PASS" 
    -execute "CREATE RETENTION POLICY 'ham_veri' ON '$DB' DURATION 14d REPLICATION 1 SHARD DURATION 1d DEFAULT"
  
  influx -host "$INFLUX_HOST" -port "$INFLUX_PORT" 
    -username "$INFLUX_USER" -password "$INFLUX_PASS" 
    -execute "CREATE RETENTION POLICY 'ozet_veri' ON '$DB' DURATION 365d REPLICATION 1 SHARD DURATION 7d"
  
  echo "[$DB] Tamamlandı."
done

echo "Tüm veritabanları için yapılandırma tamamlandı."

Bu scripti cron’a ekleyerek yeni oluşturulan veritabanlarını da kapsayabilirsiniz ya da bir provisioning aracıyla (Ansible, Chef, Puppet) entegre edebilirsiniz.

Grafana ile Entegrasyon: Doğru Politikayı Seçmek

Grafana’da InfluxDB datasource tanımlarken, hangi Retention Policy’yi kullanacağınızı sorgu bazında belirtebilirsiniz. Grafana’nın query editor’ünde “FROM” bölümünde politika seçimi yapılabilir.

Farklı zaman aralıkları için farklı Retention Policy kullanmak, Grafana dashboard’larınızı çok daha verimli hale getirir. Son 1 saatlik veriyi ham veri politikasından, son 6 aylık veriyi özet politikasından çekmek hem performansı artırır hem de depolama maliyetini düşürür.

Bunu Grafana’da template variable ile otomatik hale getirmek mümkündür. Zaman aralığı değiştikçe otomatik olarak doğru Retention Policy’ye yönlendiren bir yapı kurabilirsiniz, ama bu ayrı bir yazı konusu.

Sonuç

InfluxDB Retention Policy, doğru yapılandırıldığında “kur ve unut” mantığıyla çalışan güçlü bir mekanizmadır. Ama bu “kur” aşamasının dikkatli yapılmasını gerektirir. Özetleyecek olursak:

Her production InfluxDB kurulumunda mutlaka bir Retention Policy tanımlayın, varsayılan autogen politikasını olduğu gibi bırakmayın.
Katmanlı saklama stratejisi için ham veri, özet veri ve arşiv olmak üzere en az üç politika kullanın.
Continuous Query’leri Retention Policy süreleriyle uyumlu şekilde yapılandırın, aksi halde veri kayıpları yaşarsınız.
Shard duration’ı iş yüküne göre ayarlayın, varsayılan değerler çoğu senaryo için yeterli olsa da yüksek yoğunluklu yazma durumlarında optimizasyon gerekebilir.
Disk kullanımını düzenli olarak izleyin ve şüpheli büyümeler için uyarılar oluşturun.
InfluxDB 2.x’e geçiş planlamanız varsa, bucket tabanlı retention mekanizmasını ve Task yapısını önceden öğrenin.

Zaman serisi verisi doğası gereği sürekli büyür. Bu büyümeyi kontrol altında tutmak için Retention Policy’yi bir seçenek olarak değil, zorunluluk olarak ele alın. Bir kez doğru kurulunca aylarca hiç dokunmadan çalışan bir yapı elde edersiniz.

InfluxDB Retention Policy ile Veri Saklama Yönetimi