Auteur de la discussion
#1
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ı
Kullanıcı senaryoları ve ipuçları
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?
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: CODE
1
journalctl --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: CODE
1
journalctl -f -u nginx.service - Birim veya hizmet ayrımı: Belirli bir birimin loglarını görmek için -u kullanılır. Örneğin: CODE
1
journalctl -u mariadb.service --since 2 hours ago - Seviye ve kaynak: Önemli olayları yakalamak için PRIORITY veya SYSLOG_IDENTIFIER ile filtrelenebilir. Örneğin: veyaCODE
1
journalctl -p err..alertCODE1
journalctl 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: CODE
1
journalctl -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: CODE
1
journalctl -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: CODE
1
journalctl _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: CODE
1
journalctl -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: CODE
1
journalctl -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: CODE
1
journalctl -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: CODE
1
journalctl -u postgresql.service -p err -o short-prec - Kritik hatalarda uyarı akışı: --priority ve -p ile kritik seviyedeki olayları yalnızca listeleyin. Örneğin: CODE
1
journalctl -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?
