Selamlar, bu yazıda Splunk Edge Processor kullanarak Windows Event Log verileri üzerinde Event ID bazlı index yönlendirme çalışmasını adım adım ele alıyorum. Çalışma tamamen lab ortamında gerçekleştirildi ve pipeline davranışı gerçek bir Windows Application eventi üretilerek doğrulandı.

1. Lab hedefi ve mimari

Test senaryosunda Windows Universal Forwarder, veriyi doğrudan indexer yerine Edge Processor’a gönderiyor. Edge Processor, Application loglarının raw XML içeriğini SPL2 pipeline ile değerlendiriyor ve hedef index metadata’sını gerektiğinde değiştiriyor.

2. Test Event ID’lerinin belirlenmesi

Application kanalında bulunan EventCode değerlerini kontrol ederek lab için 900, 902 ve 903 eventlerini uygun test adayları olarak belirledim. index=windows2 source=”XmlWinEventLog:Application”
| stats count by EventCode

Raw XML yapısında Event ID aşağıdaki formda yer alıyor. Bu daha sonra Edge Processor pipeline içinde regex ile çıkarıldı.

<EventID Qualifiers=’16384′>900</EventID>

3. Edge Processor oluşturulması

Data Management uygulamasında yeni bir Edge Processor tanımı oluşturdum. Lab instance’ının adı LAB-EDGE-PROCESSOR olarak belirlendi; default destination lab Splunk instance’ına yönlendirildi ve persistent queue 5 GB olarak bırakıldı.

4. Linux instance kurulumu ve sertifika hatası

Edge Processor instance için ayrı bir Linux host kullandım. Önce Splunk management ve S2S port erişimlerini doğruladım:

nc -vz 10.100.201.162 8089
nc -vz 10.100.201.162 9997

İlk paket indirme denemesinde self-signed sertifika nedeniyle curl doğrulama hatası oluştu. Lab ortamında certificate validation kapatılarak Splunk arayüzünden yeniden oluşturulan komut seti kullanıldı.

5. 1777 port çakışması ve troubleshooting

İlk kurulumdan sonra instance Splunk tarafında Pending durumunda kaldı. Edge Processor loglarında pprof extension için 127.0.0.1:1777 portunun kullanımda olduğu görüldü.

ss -lntp | grep 1777
ps -ef | grep -E “splunk-edge|splunksup|edge_linux” | grep -v grep

Aynı Linux makinede daha önce kurulmuş başka bir Edge Processor instance’ı bulunduğu için port çakışması oluşmuştu. Eski instance durdurulduktan sonra yeni instance portu devraldı ve Edge Processor sağlıklı duruma geçti.

6. Universal Forwarder’ın Edge Processor’a yönlendirilmesi

Windows Universal Forwarder üzerindeki outputs.conf yalnızca Edge Processor hedefini kullanacak şekilde sadeleştirildi.

Forwarder restart edildikten sonra eventler Edge Processor’a ulaştı ve default destination üzerinden Splunk’a iletilmeye başladı.

7. Windows Event Log akışının doğrulanması

Received data ekranında Windows event sourcetype’larının Edge Processor’a ulaştığı doğrulandı. Application, Security ve System sourcetype’ları aynı Edge Processor üzerinden akıyordu.

8. Pipeline partition tanımı

Pipeline yalnızca Application eventlerini işleyecek şekilde partition tanımlandı. Bu sayede Security ve System logları pipeline’a girmeden default destination üzerinden akmaya devam ediyor.

Field    : sourcetype
Action   : Include
Operator : equals
Value    : XmlWinEventLog:Application

9. Sample data ve destination seçimi

Pipeline geliştirme ekranında Event ID 900 içeren gerçek Windows XML eventi sample data olarak kullanıldı. Destination lab Splunk instance’ı olan splunk_162 olarak seçildi ve index davranışı Default bırakıldı.

10. SPL2 ile Event ID bazlı index routing

Raw XML içerisindeki Event ID rex ile çıkarıldı. Event ID 900-903 aralığındaysa index metadata’sı edgeprocess_test olarak değiştirildi; diğer eventlerde mevcut index metadata’sı korundu.

$pipeline = | from $source
| rex field=_raw “<EventID[^>]*>(?<event_id>[0-9]+)</EventID>”
| eval index=if(event_id >= 900 AND event_id <= 903, “edgeprocess_test”, index)
| into $destination;

Preview sonucunda event_id=900 ve index=edgeprocess_test değerlerinin üretildiği görüldü. Bu aşama pipeline yayınlanmadan önce routing mantığının doğru olduğunu doğruladı.

11. Pipeline’ın Edge Processor’a uygulanması

Pipeline LAB_Windows_Application_EventID_Routing adıyla kaydedildi ve LAB-EDGE-PROCESSOR üzerine uygulandı.

12. Gerçek Windows eventi ile uçtan uca test

Preview testinden sonra gerçek akışı doğrulamak için Windows üzerinde Event ID 900 içeren yeni bir Application eventi oluşturdum.

eventcreate /L APPLICATION /T INFORMATION /SO EdgeProcessorLab /ID 900 /D “Edge Processor routing test EventID 900”

Pipeline aktifken normal Application eventleri windows2 indexine gelmeye devam etti. Örneğin EventCode 1022, mevcut index davranışının korunduğunu gösterdi.

13. edgeprocess_test index doğrulaması

Oluşturulan Event ID 900 eventinin hedef indexe ulaştığını aşağıdaki sorgu ile doğruladım:

index=edgeprocess_test earliest=-10m
| table _time host source sourcetype EventCode _raw
| sort – _time

14. Duplicate oluşmadığının doğrulanması

Aynı Event ID’nin eski windows2 indexinde bulunup bulunmadığını kontrol ettim. Pipeline aktif olduktan sonra oluşturulan Event ID 900 için sonuç 0 event döndü. Böylece eventin kopyalanmadığı, hedef index metadata’sının gerçekten değiştirildiği doğrulandı.

index=windows2 source=”XmlWinEventLog:Application” earliest=-10m EventCode=900
| table _time host EventCode _raw

15. Sonuç

Bu PoC ile Windows Universal Forwarder’dan gelen verilerin Splunk Edge Processor üzerinden geçirilmesi ve raw Windows XML içeriğindeki Event ID değerine göre farklı indexlere yönlendirilmesi uçtan uca doğrulandı.

Edge Processor yaklaşımının önemli avantajı, klasik index-time routing konfigürasyonlarına alternatif olarak merkezi yönetilen, SPL2 tabanlı ve yayınlamadan önce sample data ile test edilebilen bir ingestion katmanı sağlamasıdır.