Journalctl Filtreleriyle Hata Ayıklama

Journalctl Filtreleriyle Hata Ayıklama

Giriş ve bağlam
Bir Linux sisteminde günlükler genel sistem davranışını anlamak için altın değerindedir. Özellikle systemd tabanlı dağıtımlarda journalctl ile logları toplamak ve filtrelemek, hatanın kaynağını süratle izlemek için etkili bir yol sağlar. Bu postta, günlükleri zaman, kaynak, seviye ve birim açısından nasıl daraltabileceğimizi adım adım ele alacağım. Her bölümde gerçek dünyadan kurgulanmış ama uygulanabilir örnekler üzerinden ilerliyorum.

Temel filtreleme yaklaşımları

• Zaman aralığı: Belirli bir başlangıç ve bitiş arasındaki olayları görmek için --since ve --until kullanılır. Örneğin:
  كود نسخ

  1journalctl --since "2024-06-01" --until "2024-06-02 12:00"

• Gecikmeli veya canlı akış: Anlık akışı izlemek için -f ile takip (tail -f benzeri) işlevi görür. Örneğin:
  كود نسخ

  1journalctl -f -u nginx.service

• Birim veya hizmet ayrımı: Belirli bir birimin loglarını görmek için -u kullanılır. Örneğin:
  كود نسخ

  1journalctl -u mariadb.service --since 2 hours ago

• Seviye ve kaynak: Önemli olayları yakalamak için PRIORITY veya SYSLOG_IDENTIFIER ile filtrelenebilir. Örneğin:
  كود نسخ

  1journalctl -p err..alert

  veya
  كود نسخ

  1journalctl SYSLOG_IDENTIFIER=kernel

• Kayıt türleri: Hataları hızlıca görmek için -p hata veya daha genel olarak --priority hatalara odaklanır. Örneğin:
  كود نسخ

  1journalctl -p err / -p crit

• Çıktı formatı: -o json ile yapısal çıktı alınabilir; ayrıştırma ve otomasyon için faydalıdır. Örneğin:
  كود نسخ

  1journalctl -o json -u ssh.service | jq '.'

• Giriş/çıkış ve cihazlar: Özellikle blok cihazı veya ağ arayüzüyle ilgili olayları izlemek için _PID ve SYSLOG_FACILITY gibi alanlar üzerinde ince ayrıntılar yapılabilir. Örneğin:
  كود نسخ

  1journalctl _PID=1234 -n 100

• Filtre birleşimleri: Birden çok kriteri AND/OR mantığıyla birleştirmek için -p, -u, --since gibi seçenekler beraber kullanılabilir. Örneğin:
  كود نسخ

  1journalctl -u apache2.service --since "2 hours ago" -p warning

Kullanıcı senaryoları ve ipuçları

• Bir sorunun kökeni: Önce ilgili hizmetin son 200-300 girdisini inceleyin, sonra daha eski olaylarda bir eşik veya kötü konfigürasyon göstergesi arayın. Örneğin:
  كود نسخ

  1journalctl -u docker.service -n 300 --no-pager

• Gecikmeleri ve yeniden başlatmaları izlemek: Restart veya crash durumlarını görmek için -b bayrağı ile boot bazlı kayıtlara odaklanın. Örneğin:
  كود نسخ

  1journalctl -b -u cron.service --no-pager

• Ekip içi paylaşım için temiz çıktı: -o short-prec veya -o cat ile okunabilir ve ayrıştırılabilir çıktılar elde edilir. Örneğin:
  كود نسخ

  1journalctl -u postgresql.service -p err -o short-prec

• Kritik hatalarda uyarı akışı: --priority ve -p ile kritik seviyedeki olayları yalnızca listeleyin. Örneğin:
  كود نسخ

  1journalctl -p crit -u network-manager

Kapanış ve dikkat edilecek noktalar
journalctl’in filtreleme gücü, hatayı izole etmek için önce mantıksal olarak hangi birimin veya hangi zaman aralığının sorumlu olduğunu belirlemekten geçer. Genelde yol haritası şu: ilgili servis loglarını hızlıca toparla, hata seviyesindeki girdileri derinleştir, ardından sorunlu bölgede konfigürasyon veya etkileşimleri incele. Bu yöntemlerle günlüklerdeki kritik ipuçlarını yakalamak mümkün olur.

Bu konudaki deneyimleriniz veya gördüğünüz ilginç filtre kombinasyonları varsa paylaşabilirsiniz. Hangi senaryolarda hangi filtreleri işe yarar buldunuz?