Selamlar bu yazımda LCM AI Insights: MCP ve LLM ile Akıllı Log Kesintisi Analizi konusunu ele aldım keyifli okumalar 🙂
Bu çalışmada, geliştirdiğim Log Continuity Manager for Splunk (LCM) uygulamasının tespit ettiği log kesintilerini AI ile değerlendiren bir laboratuvar ortamı oluşturdum. Hedefim yalnızca “log akışı durdu” uyarısı üretmek değil; kesintiyi ilgili log kaynaklarıyla ilişkilendirerek olası nedenleri, eksik kanıtları ve önerilen kontrol adımlarını tek ekranda toplamak.

1. Lab mimarisi ve hedef

PoC ortamında Splunk Enterprise, LCM KV Store collection’ları, Splunk REST API, Splunk MCP Server, Windows üzerinde çalışan Python AI Analyzer servisi, Codex CLI ve HEC kullanıldı. Sonuçlar ayrı bir indexe gönderildi; LCM’nin mevcut KV Store ve uygulama davranışı değiştirilmedi.

LCM (monitoring_status) → Python AI Analyzer → Splunk REST API / MCP → Codex (LLM) → HEC → index=lcm_ai_analysis → Dashboard Studio

Bu mimaride Python AI Analyzer, LCM kesinti kayıtlarını ve kaynak log özetlerini Splunk REST API üzerinden toplarken, Splunk MCP entegrasyonu AI modelinin gerektiğinde ek sorgularla daha ayrıntılı inceleme yapabilmesini amaçlamaktadır. Analiz sonuçları HEC aracılığıyla tekrar Splunk’a aktarılmaktadır.

2. LCM üzerindeki aktif log kesintileri

Önce uygulamanın Current Violations ekranından aktif log kesintilerini kontrol ettim. Aynı host için farklı source ve izleme hedefleri birbirinden ayrı kayıtlar olarak takip ediliyor.

| inputlookup monitoring_status

| where effective_is_interrupted=1 AND enabled=1

| table host host_key index source sourcetype effective_status gap_min expected_after

Örnekte ONVO-TV için android_tv indexindeki adb:logcat akışı, DISKILINCF için ise farklı Windows Event Log kanalları izleniyor. Bir hosttaki birden çok kesintinin tek olay olarak sayılmaması analiz doğruluğu açısından önemli.

3. İlk teknik inceleme: Splunk MCP ve Codex

İlk aşamada bir kesinti olayını Splunk MCP üzerinden Codex’e incelettim. LCM’nin monitoring_status ve monitoring_targets kayıtlarıyla kaynak logların son olay ve indeksleme zamanları karşılaştırıldı; mevcutsa ilgili _internal kayıtları araştırıldı.

search index=android_tv host=”ONVO-TV” source=”adb:logcat” earliest=-30d latest=now

| stats count max(_time) as last_event max(_indextime) as last_index

| convert ctime(last_event) ctime(last_index)

ONVO-TV testinde olay üretiminin ve indekslemenin aynı tarihte durduğu görüldü. Windows üzerindeki ADB collector işlemi veya TV–ADB bağlantısı öncelikli hipotez olarak öne çıktı; ancak ilgili collector logları olmadan kesin kök neden ilan edilmedi.

4. AI analizlerinin Splunk’a yazılması

AI çıktılarının LCM’den bağımsız saklanması için lcm_ai_analysis indexini ve lcm:ai:analysis sourcetype’ını oluşturdum. HEC aracılığıyla yazılan kayıtlar; analiz kimliği, izlenen hedef, olası neden, güven düzeyi, soruşturma durumu ve önerilen aksiyonları içeriyor.

index=lcm_ai_analysis sourcetype=”lcm:ai:analysis” earliest=-24h

| spath

| table _time analysis_id target_id monitored_index probable_cause confidence investigation_status recommended_actions{}

İlk toplu testte 6 kesinti dönemi analiz edildi ve 6 ayrı analysis_id için kayıt doğrulandı. Bu adım, manuel olarak tetiklenen Codex incelemesinin indexe geri yazılabildiğini gösterdi.

5. Kesintiler için otomatik Python AI Analyzer

Manuel prompt ihtiyacını kaldırmak için Python tabanlı bir izleme servisi hazırladım. Servis Splunk REST API ile LCM’nin monitoring_status kayıtlarını belirli aralıklarla kontrol ediyor; yeni kesinti döneminde kaynak log özetini topluyor, AI modelini çağırıyor ve çıktıyı HEC’e iletiyor.

py -3.12 analyzer.py –once –dry-run

py -3.12 analyzer.py –bootstrap

py -3.12 analyzer.py –mode codex –interval 60

Dry-run yalnızca okuma ve kanıt toplama testidir. Bootstrap mevcut aktif kayıtları başlangıç durumu olarak işaretler. Sürekli mod ise 60 saniyelik döngülerle yeni kesintileri arar; aynı analysis_id için yerel SQLite checkpoint ve Splunk tarafındaki kayıt kontrolü kullanılır.

HEC’in code=0 yanıtı isteğin kabul edildiğini belirtir; gerçek indeksleme ayrıca Splunk aramasıyla doğrulandı. Şekildeki otomatik çalışma gönderimin başarılı olduğunu gösterir; bu, kök neden tespitinin doğrulandığı anlamına gelmez.

6. Otomatik analiz sonuçlarının doğrulanması

Otomatik oluşturulan kayıtlar lcm:auto:v1: ile başlayan analysis_id değerleriyle ayrıştırıldı. Her kayıt izlenen host ve index ile ilişkilendirildi.

index=lcm_ai_analysis sourcetype=”lcm:ai:analysis” earliest=-1h

| search analysis_id=”lcm:auto:v1:*”

| sort 0 – _indextime

| table _time analysis_id target_id monitored_host monitored_index probable_cause confidence investigation_status recommended_actions{}

PoC sırasında otomasyonun kesintileri algılayıp AI çağrısı yapabildiği ve HEC üzerinden veri yazabildiği doğrulandı. Bununla birlikte bazı Codex çıktılarında mevcut ön kanıt paketinin doğru kullanılmadığı görüldü. Bu kayıtlar düşük güven düzeyinde ve investigation_required durumunda bırakıldı. Kanıta dayalı kök neden analizi bu sürümde geliştirmeye açık bir alandır.

7. LCM AI Insights Dashboard Studio

Sonuçları Splunk Dashboard Studio üzerinde tek görünümde birleştirdim. Kartlarda analiz edilen kesinti sayısı, araştırma gerektiren olaylar, doğrulanmış kök nedenler ve farklı index sayısı bulunuyor. Tabloda probable_cause, confidence ve recommended_actions gibi alanlar gösteriliyor.

Dashboard yeni indekslenen analizleri gösterebilir. Arayüzdeki analiz sayısı otomatik olarak kök nedeni bulunan kesinti sayısı olarak yorumlanmamalı; doğrulanmış kök neden ayrıca takip edilmelidir.

8. Sonuç ve sonraki geliştirmeler

Bu PoC ile LCM’nin tespit ettiği log kesintilerinin otomatik keşfi, REST üzerinden kanıt toplama, Codex çağrısı, HEC’e geri yazma, mükerrer kayıt kontrolü ve Dashboard Studio görselleştirmesi çalışır hâle getirildi. Deneyim, log sürekliliği yönetimine AI destekli değerlendirme ve müdahale önerileri eklemek için pratik bir temel oluşturdu.

Mevcut sürümde AI’nın bazı otomatik analizlerde ön kanıtları yeterince değerlendiremediğini gözlemledim. Bu nedenle geliştirme yol haritasında daha zengin _internal ve collector kanıtları, kaynakla ilişkilendirilmiş açıklamalar, kesinti dönemine ait kararlı kimlik, recovery analizi, hata durumunda güvenilir yeniden deneme ve insan onaylı kök neden doğrulaması bulunuyor.

Çalışma Codex üzerinden test edilmiştir. Kurum içi Qwen3 gibi bir Local LLM kullanımı da uygun API, erişim ve güvenlik kontrolleri sağlanarak mümkündür; bu alternatif ayrı test gerektirir.

Uygulama: Log Continuity Manager for Splunk — https://splunkbase.splunk.com/app/8958