Добавьте миллисекунды к метке времени файла журнала - PullRequest
0 голосов
/ 24 января 2019

Я просматриваю логи с двух разных серверов. Я знаю разницу во времени между этими двумя серверами вплоть до миллисекунды. Чтобы лучше понять последовательность этих сообщений, мне нужно настроить вывод одного из файлов журнала, чтобы он отражал то же время.

Обычно я использую файл журнала через скрипт awk, чтобы выполнять другие действия, а затем перенаправлять вывод в less. Это выглядит так:

~/path/to/myAwkscript.awk /path/to/my/logfile | less 

Мой мыслительный процесс заключается в том, что я могу использовать sed / awk, чтобы добавить 747 миллисекунд к каждой отметке времени в файле. Я не против других решений. Каждая строка (если это не какая-то трассировка стека) начинается с timestamp в следующем формате: YYYY-MM-DD HH:MM:SS,MS

Вот пример метки времени в моем журнале:

2019-01-24 01:36:24,487

Когда я рассматриваю это, я хочу, чтобы эта часть читалась следующим образом:

2019-01-24 01:36:25,234

, а затем оставшаяся часть строки / файла будет его оригиналом.

Спасибо за чтение. -Gregg

1 Ответ

0 голосов
/ 24 января 2019

Поскольку мы ничего не знаем о вашем входном файле, мы предполагаем, что вы можете извлечь дату-время и манипулировать им самостоятельно в awk.

Хитрость в том, чтобы использовать mktime с датой, исключая миллисекунды. Это создаст время эпохи (в секундах с 1970-01-01 00:00:00 UTC), где вы можете добавить миллисекунды. Однако, поскольку миллисекунды не могут быть представлены в виде числа с плавающей запятой, предлагается работать в миллисекундах, а не в секундах. Таким образом, вы можете делать все с целыми числами.

Пример:

2019-01-24 01:36:24,487
=> mktime("2019 01 24 01 36 24")*1000 + 487
=> 1548293784487

Возвращает общее количество миллисекунд. Теперь вы можете сравнить эти числа, добавив к этому числу 747 миллисекунд.

Зачем работать в миллисекундах? Большую часть времени, работая за секунды, не будет проблематичным. Вы получите что-то вроде:

2019-01-24 01:36:24,487
=> mktime("2019 01 24 01 36 24") + 0.487
=> 1548293784.48699998855590820....

Как вы заметили, это не совсем то же самое число, но округленное до ближайшего двоичного числа. Эти незначительные ошибки округления могут потенциально привести к незначительным несоответствиям, какая запись журнала была первой.

Следующий пример отсортирует два файла соответственно:

Здесь мы предполагаем, что log1 нужны дополнительные 747 миллисекунд:

awk '{ time=$1" "$2; ms = substr(time,21,3); time=substr(time,1,19)
       gsub(/[-:]/," ",time); time=mktime(time)*1000 + ms }
     (NR==FNR) { time+=747 }
     { print time, FILENAME, $0 }' log1 log2 | sort -n

Это выведет что-то вроде:

1548293784487 log2 2019-01-24 01:36:24,487 entry
1548293784587 log2 2019-01-24 01:36:24,587 entry
1548293785234 log1 2019-01-24 01:36:24,487 entry
1548293785235 log2 2019-01-24 01:36:25,235 entry
...

примечание: здесь используется расширение gnu-awk mktime. примечание: mktime преобразуется в эпоху, предполагая, что представленная строка находится в локальном часовом поясе сервера. Если оба журнала создаются на серверах с разными часовыми поясами, вам придется внести изменения в код, чтобы отразить эти часовые пояса. Настоятельно рекомендуется всегда иметь свои журналы в UTC.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...