Приветствую,
уважаемый читатель!
Хочу
поделиться историей о том, как можно при парсинге log-файлов неожиданно недосчитаться
большого количества событий из-за нехватки нулей, а формат даты и времени
перестает быть просто формальностью, которую SIEM "и так проглотит".
Итак,
история следующая, недавно появилась необходимость выгрузить из СУБД MSSQL в csv-файл много событий при помощи PowerShell, и далее загрузить
файлы в Splunk
(о определённым причинам DB
Connect
не
подходил). После загрузки файлов за некоторое время, стало ясно, что в sourcetype не
хватает нескольких сотен событий.
- Splunk, увидев время события 0:17:12, интерпретировал его не как 0 часов 17 минут, а как 17 часов 12 минут.
- Для дальнейших 4-х событий Splunk вообще не смог подставить время из события (0:27:12, 0:37:12, 0:47:12, 0:57:12) и проиндексировал под временем предыдущего.
Причем сами события не потерялись, и в веб-интерфейсе
Splunk
они
просто схлопнулись в одно большое событие с последней «корректной» датой.
Данную
ситуацию при индексации событий можно
воспроизвести искусственно через PS:
function collect_null {
$Ihost = "ExpHost"
$Ssocket = '10.10.10.33:3033'
$Ssource = 'tcp:3033'
$timeSplunk =
"2017.10.12 0:13:40"
$eventSplunk =
"Simple event"
[string]$to_splunk = 'CollectTime={0};
Event={1};' -f $timeSplunk,
$eventSplunk
C:\scripts\SendToSplunk.exe -server
$Ssocket -host
$Ihost -source
$Ssource -event
"$to_splunk"
}
Результат
ниже:
Такая
«особенность» индексации событий возникает из-за отсутствия «лидирующего нуля»
в поле времени (часы), т.е. формат времени не HH:mm:ss, а H:mm:ss. Причем в СУБД дата хранится в
формате HH:mm:ss и, видимо, PowerShell сам
исправляет её перед выводом в файл. Исправляется данная ситуация достаточно
просто, путем обязательного форматирования времени с использованием «лидирующего
нуля».
В PowerShell это
делается с использованием оператора «-f», например
так:
$TimeN = '{0:dd.MM.yyyy HH:mm:hh}' -f $str.Time
Всем
удачи в мелочах J
Комментариев нет:
Отправить комментарий