AI ile sistem yönetimi otomasyonu artık sadece bir moda kelime değil — ben her gün kullanıyorum. Benim ortamımda AI destekli CLI araçları log analizi ve hata tespitini gözle yapabileceğimden çok daha hızlı hallediyor. journald dökümlerini, syslog akışlarını ve container loglarını local modellere veya API destekli CLI'lara pipe ediyorum; saniyeler içinde anomalileri, stack trace'leri ve root-cause ipuçlarını yüzeye çıkarıyorlar. İşte ben bunu nasıl yapıyorum, ne işe yarıyor ve nelerden kaçınmanız gerekiyor.
Neden AI CLI Araçları Manuel Log Grep'ten Daha İyi
Eskiden grep -i error /var/log/syslog çalıştırıp on dakka scroll yapardım. Hâlâ çalışıyor ama Proxmox cluster'ları, bir düzine Windows VM'i ve CDN arkasında birkaç e-commerce stack'i yönetirken log hacmi acımasız oluyor. AI CLI araçları iş akışını değiştiriyor: filtrelemek yerine soruyorsun.
En büyük avantaj sadece hız değil — bağlam. Bir grep sana bir satırın "error" ile eşleştiğini söyler. Bir AI CLI aracı ise neden o hatanın önemli olduğunu, muhtemelen neyin sebep olduğunu ve sırada neyi kontrol etmen gerektiğini söyler. Arama ile teşhis arasındaki fark budur.
Daha önce MTTD'yi düşürme yazımda (https://furkanikkan.com/urun/veri-ihlalini-ne-kadar-hizli-tespit-edersiniz-mttd-rehberi-57) belirttiğim gibi, hızlı tespit her şey demek. AI CLI araçları bu tespit penceresini ciddi şekilde daraltıyor.
Offline Log Analizi için Ollama ile Local LLM'ler
Her logu OpenAI'ya göndermiyorum. Bazı loglar müşteri verisi, iç IP'ler veya ağdan çıkmaması gereken altyapı detayları içeriyor. ollama tam burada devreye giriyor.
32GB RAM ve basit bir GPU'ya sahip bir makinede local model çalıştırıyorum — genelde llama3 veya qwen2.5. İşte tipik bir pipeline:
journalctl -u nginx --since "1 hour ago" --no-pager | \
ollama run llama3 "Analyze these Nginx logs. List any anomalies, \
error patterns, and suggest root causes. Be concise."Bu bana 10–20 saniye içinde okunabilir bir özet veriyor. Model upstream timeout'ları, 499 client disconnect'leri ve rate-limit hit'leri gibi şeyleri yakalıyor — sabah 2'de yorgunken kolayca gözden kaçabilecek şeyler.
İpucu: Hızlı triyaj için qwen2.5:7b gibi daha küçük modeller kullanın. Daha derin analiz gerektiğinde sadece daha büyük olanlara geçin. 7B modeller log pattern tanımada şaşırtıcı derecede iyi.
Doğal Dil Log Sorguları için lg CLI Kullanımı
lg (Language-Grep) adında şık bir araç var; regex yerine doğal dil kullanarak log aramanı sağlıyor. Ne aradığını bildiğin ama doğru grep pattern'ini kuramadığın anlar için birebir.
pip install lg-ai
# Karmaşık grep pattern'leri yazmak yerine:
lg "find all failed SSH login attempts from the same IP" /var/log/auth.log
# Veya journalctl ile:
journalctl --since today --no-pager | lg "show me entries about disk space warnings"Bunu çoğunlukla tek seferlik soruşturmalar için kullanıyorum. Monitoring stack'imi replace etmiyor — bir şeyler bozulduğunda ve hemen cevap lazım olduğunda hızlı bir tanı aracı.
Otomatik Hata Tespit Pipeline'ları Kurmak
Sürekli otomasyon için komutları manuel çalıştırmak istemiyorum. AI bakmaya değer bir şey tespit ettiğinde sistemin beni uyarmasını istiyorum. İşte kullandığım basit bir yaklaşım:
#!/bin/bash
# ai-log-scanner.sh — cron ile her 15 dakikada bir çalışır
LOGS=$(journalctl --since "15 min ago" --no-pager -p err..alert)
if [ -n "$LOGS" ]; then
ANALYSIS=$(echo "$LOGS" | ollama run qwen2.5:7b \
"Summarize these system errors. If any indicate hardware failure, \
disk issues, or network outages, flag them as CRITICAL. \
Output format: [SEVERITY] service: description")
echo "$ANALYSIS" | grep -q "CRITICAL" && \
/usr/local/bin/send-alert.sh "$ANALYSIS"
fiBu script Proxmox host'larımda ve birkaç kritik VM'de duruyor. Geleneksel eşik tabanlı monitoring'in kaçırdığı şeyleri yakalıyor — mesela kernel loglarına gömülü predictive failure uyarıları veren bir RAID controller, veya "başarılı" olan ama corruption uyarıları loglayan bir backup job.
Her Gün Gerçekten Kullandığım AI CLI Araçları
İşte benim kısa listem — iş akışımda kalıcı yer edinen araçlar:
ollama— Local model runner. Offline log analizimin belkemiği. Hiçbir veri ağdan çıkmıyor.lg— Doğal dil log arama. Regex kurmak çok uzun sürecekse ad-hoc sorgular için harika.aichat— Config dosyaları ve hata mesajları hakkında hızlı sorular için kullandığım hafif bir CLI chat client'ı. Birden fazla backend destekliyor.shell-gpt(sgpt) — Doğal dilden shell komutları üretiyor. Loglardan ziyade karmaşık one-liner'lar yazmak için kullanıyorum. Daha önce Linux sysadmin araçları yazımda (https://furkanikkan.com/urun/haftada-saatler-kazandiran-25-linux-sistem-yoneticisi-araci-54) işlediğim gibi, komut üretimi gerçekten zaman kazandırıyor.ggshield— Kod ve config'i git'e gitmeden önce secret'lar için tarıyor. Log analizi per se değil ama hassas verinin loglara ve commit'lere sızmasını yakalıyor.
Tuzaklar ve Pratik Uyarılar
Zor yoldan öğrendiğim birkaç şey:
AI çıktısına körü körüne güvenme. Modeller root cause halüsinasyonu yapıyor. Aksiyon almadan önce her zaman doğruluyorum. AI bir başlangıç noktası, kesin cevap değil. "Failing disk" diyorsa yine de smartctl -a /dev/sda çalıştırıyorum değiştirme siparişi vermeden önce.
Token limitleri önemli. Yoğun bir e-commerce frontend'inden tam günlük syslog 500MB+ olabilir. Local modeller buna boğuluyor. Model'e göndermeden önce grep veya journalctl -p err ile ön-filtreleme yapıyorum. AI ilginç kısımları alıyor, şelaleyi değil.
API destekli araçlarda maliyet birikiyor. Yoğun trafikli bir stack'te log analizi için OpenAI API kullandığımda, fark etmeden bir haftada 40$'a vurmuştum. Local modeller donanım yatırımından sonra bedava. API çağrılarını seçici kullan — toplu işlem için değil, karmaşık analiz için.
Log format değişiklikleri pipeline'ları bozar. Bir app güncellemesi log formatını değiştirir ve AI modelin aniden her şeyi yanlış yorumlar. Model versiyonlarını sabitliyorum ve büyük güncellemelerden sonra pipeline'ları test ediyorum.
Bu Daha Büyük Resimde Nereye Oturuyor
AI CLI araçları monitoring stack'imi replace etmiyor — Zabbix metric'leri hallediyor, Grafana trend'leri gösteriyor ve alerting rule'ları eşik aşımlarını yakalıyor. AI'ın eklediği şey yorumlama katmanı. Dağınık, yapılandırılmamış şeyleri okuyor ve bana neyin önemli olduğunu söylüyor.
Hem Linux hem Windows Server ortamlarını yöneten biri olarak (benim yaptığım gibi), PowerShell event loglarını ve journald çıktısını aynı modele atıp tutarlı analiz alabilmek gerçekten faydalı. Farklı log formatları, aynı tanı iş akışı.
Burada tarif ettiğim araçları denemek hiçbir şeye mal olmuyor. ollama'yı kur, bir 7B model pull'la, bir sonraki hata logunu içine pipe et. İş akışına uyup uymadığını bir gün içinde anlarsın.
Kapak görseli: ₡ґǘșϯγ Ɗᶏ Ⱪᶅṏⱳդ · CC0 (Openverse / kamu malı) · https://www.flickr.com/photos/148598741@N02/51894347967