Я использую syslog и rsyslog для ведения журнала в моих системах Linux и FreeBSD.
В настоящее время метка времени указывается в секундах, но я хотел бы повысить точность из этих временных меток включать миллисекунды. Возможно ли это при использовании таких вариантов системного журнала, как rsyslog (RedHat, Ubuntu) или Syslog на FreeBSD?
Если бы я увеличил метку времени ведения журнала, включив в нее микросекунды, насколько точны эти метки времени? Если событие произошло в 03: 37: 02: 001, означает ли это, что событие действительно произошло в эту точную миллисекунду, или есть задержка, когда системный журнал записывает событие?
Наиболее современный Демоны системного журнала (включая rsyslog и syslog-ng) поддерживают высокоточную метку времени. Если вы используете один из этих инструментов, у вас не должно возникнуть проблем с его настройкой.
Что касается точности. . . это зависит. Прежде всего, это будет зависеть от оборудования. Большинство современного оборудования поддерживает высокую точность времени, но не все. Если предположить, что оборудование поддерживает это, есть еще несколько проблем. Главный приоритет будет заключаться в том, чтобы убедиться, что ваши часы установлены точно, и что любые другие машины, которые регистрируются на нем, имеют соответствующее время (при условии, что вы отправляете журналы со всех своих систем на центральный хост-логин). ntpd это стандартный инструмент для поддержания точного времени на часах (обычно синхронизируется с ntp.org пул).
Наконец, мы подошли к самому мероприятию. Короткий ответ: почти всегда будет хотя бы небольшой дрейф, даже если он очень незначительный. Здесь тоже будет некоторая изменчивость в зависимости от других факторов. Многое будет зависеть от того, откуда происходит событие и как его подберут. Например, если у меня есть приложение, которое выполняет foo, а затем отправляет журнал в syslog, говоря, что приложение выполнило foo, между завершением foo и отправкой журнала может пройти 100 мс. Для завершения системного вызова syslog () может потребоваться еще 20 мсек.
Я не помню низкоуровневые подробности syslog, но я не верю, что событие имеет отметку времени, когда оно отправляется в syslog, я думаю, что это отметка времени демоном syslog, когда оно выбирается. Это добавляет еще несколько миллисекунд к миксу.
В принципе, если вы не имеете дело с системой реального времени со средствами ведения журнала, я не думаю, что вы когда-нибудь получите стопроцентную точность. Даже тогда у вас, вероятно, будут (микроскопические) уровни дрейфа, но, по крайней мере, у вас будут ограничения, чтобы знать свою погрешность. В то же время, если у вас нет такого уровня требований, ваша временная метка, вероятно, будет достаточно точной.
Кристофер рассмотрел технические вопросы: запустите ntpd, укажите его на надежный источник и помните о дрейфе. Я хотел добавить пару примечаний:
Отметка времени устанавливается syslog() вызов функции libc. Вот реализация uClibc. Типичный syslog() вызов завершится менее чем за 1 мс. Вот оболочка виртуальной машины Ruby syslog() через 0,15 мс:
Benchmark.measure {logger.info 'narf'} .real => 0.000149965286254883
Хотя системный журнал может подходить для точности до миллисекунды, многие платформы веб-приложений буферизуют журналы, а затем либо периодически очищают буфер, либо выводят все журналы для запроса после его завершения. Почти все веб-серверы делают то же самое (так формат общего файла журнала W3C знает передаваемые байты). Влияние заключается в том, что точность в миллисекундах полезна в меньшем количестве ситуаций, чем может показаться.
Дрейф часов характерен для виртуальных машин. Судя по анекдотическим упоминаниям, обычно 3 секунды в день. Бег ntpdate поскольку ночная работа cron не достаточно хороша.
Контекст обычно делает порядок довольно очевидным. Если вы не сталкивались со случаем, когда точность в миллисекундах была единственным способом узнать, какое событие произошло первым, вероятно, это не стоит времени.
В /etc/rsyslog.conf замените
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat
по
$ActionFileDefaultTemplate RSYSLOG_FileFormat
И после перезапуска службы rsyslog в файле журнала появятся миллисекунды.