Furkan İkkan English
Yazılara geri dön
Yazı

· Network & System Administrator

ELK'de Yapılandırılmış JSON Loglarıyla Borg Yedekleme Başarıları ve Hatalarının Görselleştirilmesi

BorgBackup --log-json yapılandırmasını ELK ile merkezi izleme için nasıl yapılandıracağınızı, yedekleme sonuçlarını görselleştirmeyi ve hatalar için uyarı ayarlamayı öğrenin.

BackupBorgBackupELKloggingmonitoring

BorgBackup'ı altyapı yedeklemelerimiz için ilk kullandığımda, başarılı olduğunu doğrulamak için e-posta bildirimleri ve manuel log kontrollerine güveniyordum. Bu yöntem, yedekleme işleri ağ zaman aşımı veya depolama kilidi nedeniyle sessizce başarısız olana kadar işe yaradı; ancak bu hataları günler sonra fark ediyordum. Dönüm noktası, Borg'un yapılandırılmış JSON loglamasını etkinleştirdiğim ve bu logları ELK yığınımıza yönlendirdiğimde oluştu. Aniden, her yedekleme çalışmasını aranabilir bir olay olarak görebildim — başarı, süre, aktarılan bayt sayısı ve en önemlisi, herhangi bir başarısızlığın kesin nedeni. Bu yazıda, BorgBackup'ı --log-json ile nasıl yapılandırdığımı, logları Logstash'e nasıl gönderdiğimi, Elasticsearch'te nasıl indekslediğimi ve Kibana'da görselleştirmeler ve uyarılar oluşturarak yedekleme sağlığını bir bakışta nasıl izlediğimi göstereceğim.

Yapılandırılmış Günlüklerin Yedeklemeler İçin Önemi Nedir?

Borg tarafından üretilen düz metin günlükleri okunabilir olsa da, ölçekte ayrıştırılması zor olur. Farklı zamanlamalarda onlarca yedekleme hedefi yönetiyorsanız, 'ERROR' veya 'archive created' gibi ifadeler için grep yapmak güvenilir hale gelmez. Borg’un --log-json bayrağı, her günlük satırını event, path, repository, archive, duration ve success gibi tutarlı alanlara sahip geçerli bir JSON nesnesi olarak çıkarmak suretiyle bu sorunu çözer. Böylece, metin kalıplarına değil, gerçek yedekleme sonuçlarına göre filtreleme, toplama ve uyarı yapabilen bir merkezi günlük sistemine göndermek çok kolaylaşır.

Kendi kurulumumda, her yedekleme işi bir systemd zamanlayıcı üzerinden çalışır ve borg create komutuna --log-json eklenir. Çıktı doğrudan stdout’a gider, bu da journald tarafından yakalanıp Loki/Promtail yığınına iletilir — ELK için ise, Filebeat’i journal’ı okumak ya da ayrı bir günlük dosyasını okumak için kullanırım. Temel şey, JSON’un bozulmadan kalmasını sağlamaktır; böylece Logstash, bozuk satırlar nedeniyle kırılmadan onu ayrıştırabilir.

JSON Günlüğü İçin Borg Yapılandırma

Burada, bir yedekleme betiğinde Borg'u nasıl çağırdığımı gösteren bir örnek var:

#!/bin/bash
REPOSITORY=ssh://backup@backup-server:/mnt/borg/{hostname}
SOURCE_DIRS="/etc /var/www /home"

borg create \
    --log-json \
    --compression lz4 \
    --stats \
    $REPOSITORY::'{hostname}-{now:%Y-%m-%d_%H:%M}' \
    $SOURCE_DIRS

# Çıkış kodu kontrolü hâlâ önemli — JSON günlükleri onu değiştirmez
if [ $? -eq 0 ]; then
    logger -t borg-backup "Yedekleme başarıyla tamamlandı"
else
    logger -t borg-backup "Yedekleme çıkış kodu $? ile başarısız oldu"
fi

--log-json bayrağı, başlangıç, kontrol noktası, arşiv tamamlanması ve hatalar gibi her önemli olayı JSON olarak çıktıya verir. Hâlâ anında syslog görünürlüğü için geleneksel logger çağrısını tutuyorum, ancak gerçek güç yapılandırılmış akıştan gelir.

Bu bölüm metnini Türkçeye çevir. Anlam aynı kalsın. İngilizce cümle bırakma.

JSON Loglarını Filebeat ile ELK'ye Gönderme

Sistemd günlüğünü (veya çıktıyı yönlendirdiğiniz bir dosyayı) okumak ve JSON satırlarını Logstash'a yönlendirmek için Filebeat kullanırım. Kritik kısım, Filebeat'in her satırı JSON olarak işlemesini ve yapısını korumasını söylemek.

Filebeat modül yapılandırmamda:

filebeat.inputs:
- type: filestream
  enabled: true
  paths:
    - /var/log/borg-backup.log
  json.keys_under_root: true
  json.add_error_key: true

# Journal'dan okuma yapıyorsanız:
# - type: journald
#   enabled: true
#   journal.paths: ['/var/log/journal/']
#   json.keys_under_root: true

json.keys_under_root: true ayarı, JSON alanlarını doğrudan Elasticsearch belgesinin üst seviye alanları olarak düzleştirir; böylece event, success, duration ve repository gibi alanlar sorgulanabilir ve görselleştirilebilir hale gelir, zahmetsizce.

Parsing ve Zenginleştirme Logstash'te

Filebeat doğrudan JSON'u Elasticsearch'e gönderebilir, ancak bağlam eklemek ve sınır durumlarını yönetmek için Logstash üzerinden yönlendiririm. Örneğin, dosya adı veya ortamdan gelen etiketleri kullanarak her yedekleme olayına kaynak ana bilgisayar adı ve yedekleme tipi (günlük, haftalık vb.) ekleyerek zenginleştiririm.

Logstash filtresi basitçe şöyle görünür:

filter {
  if [event] == "archive_create" {
    mutate {
      add_field => { "backup_type" => "%{[@metadata][backup_type]}" }
      add_tag => [ "borg-backup" ]
    }
    if [success] == false {
      mutate { add_tag => [ "backup-failed" ] }
    }
  }
}

Bu sayede, tag:backup-failed gibi Kibana filtreleri oluşturarak tüm başarısız çalışmaları anında görebilir veya zaman içinde backup_type üzerinden ortalama süreyi grafikleyebilirim.

Kibana'da Yedekleme Başarısını Görselleştirme

Veri Elasticsearch'te olduğunda, Kibana'da birkaç temel görselleştirme oluşturdum:

  • Günlük yedekleme başarı oranını gösteren zaman serisi grafiği (success:true ile success:false sayısı karşılaştırması)
  • Yavaş outlier'ları tespit etmek için konak bazında ortalama yedekleme süresini gösteren çubuk grafiği
  • Depo, hata mesajı (message alanıdan) ve süresi ile birlikte son başarısız çalıştırmaları listeleyen tablo
  • Hata nedenlerini gösteren pasta grafiği — message alanından yaygın kalıpları Painless scripti veya Logstash grok ile çıkarıyorum (örneğin: "bağlantı zaman aşımı", "depo kilitli", "kontrol noktası başarısız")

Bu görselleştirmeler, operasyon ekibimizin haftalık olarak incelediği özel "Yedekleme İzleme" panosunda yer alıyor. Veri yapılandırıldığı için, grafikteki başarısız çubuğa tıklayarak neyin yanlış gittiğini gösteren tam günlük girdilerine kadar detaylı inceleme yapabiliyorum.

Yedekleme Hataları İçin Uyarı Ayarlama

Görselleştirme trend analizi için yardımcı olur, ancak proaktif uyarılara ihtiyacım vardı. Kibana’da şu koşulları sağladığında tetiklenen bir kural oluşturdum:

  • tag:backup-failed görünür
  • Ve zaman damgası son 15 dakika içindeyse
  • Ve host, kritik altyapı grubumuzda ise

Eylem, mesajımızı Mattermost kanalımıza gönderir ve webhook üzerinden dahili izleme sistemimizde bir bilet oluşturur. Uyarı, log metni eşleştirmesi yerine etiketli bir alana dayandığı için güvenilirdir — grep benzeri desenlerden kaynaklanan yanlış pozitifler olmaz.

İpuçları ve Dikkat Edilmesi Gerekenler

  • --log-json çıktısını her zaman bir dry run ile test edin: borg create --log-json --dry-run ...
  • Log toplayıcınızın satırları kesmesini veya birleştirmesini önleyin — JSON günlüğü, bütün satırlara dayanır
  • Elasticsearch'te _jsonparsefailure etiketleri görüyorsanız, JSON olmayan çıktıyı kontrol edin (örneğin, stdout'a yönlendirilen şifre istekleri)
  • Günlükleri şiddet seviyesine göre ayırmayı düşünün: operasyonel olaylar için --log-json kullanın ve ayrıntılı/hata ayıklama günlüklerini gerekirse ayrı bir akıma yönlendirin

Son Düşünceler

BorgBackup ile yapılandırılmış JSON loglamaya geçiş yaparak yedekleme izlemeyi nasıl yaptığımı dönüştürdüm. Bildirimlerin çalışmasını ummak yerine, her çalıştırmanın aranabilir, denetlenebilir kaydını artık elimde buluyorum — sorunları hızlıca teşhis etmemıza yardımcı olan bağlamla birlikte. ELK ile birleştirildiğinde, bu, yedekleme izlemeyi reaktif bir işten altyapı sağlığımızın şeffaf ve ölçülebilir bir parçasına dönüştürüyor.

Borg kullanıyorsanız ve hâlâ başarı/başarısızlık için metin loglarını ayrıştırıyorsanız, --log-json seçeneğini deneyin. Küçük bir değişiklik, bir şeyler ters gittiğinde hemen ödenir — ve hiç olmadan nasıl yönetebileceğinizi hayal edemezsiniz.

Kapak görseli: Lenharth Systems · CC0 (Openverse / kamu malı) · https://stocksnap.io/photo/computer-hard-2J3PLNMO9M