keencli Binlerce Router Log Satırını Nasıl Odaklı Bir Tanı Raporuna Dönüştürüyor

Router arızaları nadiren tek bir hata mesajı olarak gelir. Bir PPPoE kopması, bir rota değişikliği, bir DNS güncellemesi ve alakasız servis logları aynı dosyaya yığılabilir. İşe yarayan tek satır, binlerce satırın arasında kaybolabilir.

keencli aracını tam olarak bu arızayı incelenebilir hâle getirmek için yazdım. Keenetic router’dan zaman damgalı bir durum kaydı topluyor, logu muhtemel ağ olaylarına indirgiyor, kimlikleri maskeliyor ve bir tanı promptu hazırlıyor. Yapay zekâ analizi isteğe bağlı; yerel rapor ise her zaman üretiliyor.

Tekrarlanabilir bir durum kaydıyla başlayın

fetch komutu; sistem, PPPoE, ping-check, log, Wi-Fi ve mesh verisini tek bir zaman damgalı dizinde toplayabiliyor:

outputs/2026-06-25_18-15-39/
├── system.json
├── interface_PPPoE0.json
├── pingcheck.json
├── log.txt
├── wifi.json
└── mesh.json

Bu, ilk bakışta göründüğünden daha önemli. Router’ın durumu, siz onu incelerken bile değişiyor. İlgili girdileri birlikte kaydetmek, aynı kanıtı cihaza yeniden bağlanmadan ya da arızanın tekrar yaşanmasını beklemeden analiz edebilmemi sağlıyor.

Anahtar kelimeye değil, olaya göre filtreleyin

En son durum kaydını analyze komutu okuyor. PPPoE, modem kopmaları, ping-check durumu, WAN bağlantı değişiklikleri, rotalar, IP adresleri ve DNS değişiklikleri etrafındaki olaylar tutuluyor. Önyükleme gürültüsü, sürücü mesajları, provisioning bildirimleri ve tekrarlayan bridge güncellemeleri ise ayıklanıyor.

Projede belgelenen tipik bir örnekte yaklaşık 3.000 girdi satırı, incelenmesi gereken 60 satıra iniyor. Bu bir benchmark ya da garanti değil. Amaçlanan indirgemeyi anlatan yararlı bir tarif: arızanın etrafındaki sıra korunuyor, açıklamaya yardımcı olmayan satırlar çıkarılıyor.

Daha küçük bir olay akışı LLM olmadan bile işe yarıyor. Okuması, diff’lemesi, bir issue’ya eklemesi ve kanıt olarak saklaması çok daha kolay.

Raporu yazmadan önce maskeleyin

Tanı dosyaları, makineler veya servisler arasında öylece dolaşmaması gereken kimlikler barındırıyor. Analiz edilen çıktıyı yazmadan önce keencli, IPv4 adreslerini, yaygın MAC adresi biçimlerini ve JSON ssid değerlerini maskeliyor. Aynı maskeleme adımı yapay zekâ promptu hazırlanırken bir kez daha uygulanıyor.

Router şifresi bir ortam değişkeninden veya .env dosyasından okunuyor ve Rust’ın SecretString tipiyle saklanıyor. Normal yapılandırma dosyasında ya da tanı çıktısında yer almıyor.

Bu, kapsamı belirli bir koruma; mükemmel bir anonimleştirme iddiası değil. Maskeleme kuralları bilinen biçimleri kapsıyor, ancak sıra dışı kimlikler bir rapor paylaşılmadan önce hâlâ gözden geçirilmeli.

Yapay zekâyı belirgin bir sınırın gerisinde tutun

Hiçbir API anahtarı yapılandırılmasa bile keencli analyze, prompt_for_ai.txt dosyasını üretmeye devam ediyor. Bir OpenRouter anahtarı varsa maskelenmiş promptu gönderebiliyor ve dönen raporu durum kaydının yanına kaydedebiliyor.

Bu sınır kasıtlı:

• toplama ve filtreleme yerel olarak çalışıyor;
• kullanıcı, prompt’u göndermeden önce inceleyebiliyor;
• üçüncü tarafa aktarım yalnızca isteğe bağlı yapay zekâ adımında gerçekleşiyor;
• yapay zekâ raporu bir hipotez olarak kalıyor, bir router komutu değil.

Maskelenmiş veri de olsa yine üçüncü tarafa gönderilen bir veri. Araç istekten önce bunu belirtiyor ve önerilen her ağ değişikliği orijinal loglara karşı doğrulanmalı.

Bunun değiştirdiği şey

İşe yarayan taraf, keencli’nin bir modeli çağırabilmesi değil. Dağınık bir sorun giderme oturumunu küçük, incelenebilir bir çıktıya dönüştürebilmesi asıl mesele. Model, bu çıktının olası okuyucularından yalnızca biri; bir kişi, bir issue tracker ya da sonraki bir karşılaştırma da aynı işi görüyor.

Sırada işe yarayacak asıl doğrulama, daha geniş donanım kapsamı. Şu anki yaklaşım, üzerinde geliştirildiği router’larda pratik değer taşıyor; ancak her Keenetic modeli veya her log biçimi için bir uyumluluk garantisi olarak sunulmamalı.

Uygulama detayları log filtresinde, maskeleme kodunda ve proje README’sinde bulunuyor. Kod biraz sıkıcı ama işini yapıyor :)