– JDBC maakt een on-disk ‘session tracking’ file voor aanwezige informatie van het laatste event dat zij bekeken heeft om resets te vermijden als het Event Correlation Service (ECS) herstart. Net zoals de meeste andere ‘actieve’ QRadar protocollen die outbound communicatie maken om event gegevens van een extern systeem op te halen.
– Bij JDBC wordt de tracking
informatie opgeslagen in
simple name=value property files. Die staan in /store/ec/jdbc/ met een file per JDBC
log source
– De files hebben een naam met daarin de sensorprotocolconfig id waarde voor de
log source. Deze kan opgehaald worden uit de postgres database
door gebruik te maken van het volgende commando:
•Psql –U qradar –c “select id from sensorprotocolconfig where configname = ‘<Log Source Name>’;”
– Deze file kan worden gebruikt om vast te stellen wanneer de JDBC provider voor het laatst de
remote database heeft gepoold en kan je ook vertellen wat de comparable kolom is
en wat de laatst waargenomen waarde was.
– Je kunt het
JDBC protocol forceren om de oude gegevens opnieuw in te lezen door in te breken in deze file – dat is handig voor test en demonstratie doeleinden. Schakel de log source uit, pas
de file aan door‘comparable’ naar een oudere timestamp/counter/id/etc aan te passen, schakel daarna de
log source weer in. Wanneer de
JDBC provider opstart leest het die file om te bepalen wanneer het
met pollen moet beginnen en dus kijkt het terug in de tijd en haalt dan de oudere gegevens op.
Geen opmerkingen:
Een reactie posten