Корреляция / var / log / * временные метки

20

/var/log/messages, /var/log/syslogи некоторые другие файлы журналов используют метку времени, которая содержит абсолютное время, например Jan 13 14:13:10.

/var/log/Xorg.0.logи /var/log/dmesg, кроме вывода $ dmesg, использовать формат, который выглядит как

[50595.991610] malkovich: malkovich malkovich malkovich malkovich

Я предполагаю / собираю, что числа представляют секунды и микросекунды с момента запуска.

Однако, моя попытка сопоставить эти два набора временных меток (используя выходные данные uptime) дала расхождение около 5000 секунд.

Это примерно столько времени, сколько мой компьютер был приостановлен.

Есть ли удобный способ отобразить числовые метки времени, используемые dmesg и Xorg, в абсолютные метки времени?

Обновить

В качестве предварительного шага к тому, чтобы разобраться в этом, а также, надеюсь, сделать мой вопрос немного более понятным, я написал скрипт на Python для анализа /var/log/syslogи вывода перекоса времени. На моей машине, работающей под управлением Ubuntu 10.10, этот файл содержит множество строк, созданных ядром, которые помечены как меткой времени dmesg, так и меткой времени syslog. Сценарий выводит строку для каждой строки в этом файле, которая содержит метку времени ядра.

Использование:

python syslogdriver.py /var/log/syslog | column -nts $'\t'

Чистый вывод (определения столбцов см. Ниже):

abs              abs_since_boot  rel_time      rel_offset  message
Jan 13 07:49:15  32842.1276569   32842.301498  0           malkovich malkovich

... rel_offsetэто 0 для всех промежуточных строк ...

Jan 13 09:55:14  40401.1276569   40401.306386  0           PM: Syncing filesystems ... done.
Jan 13 09:55:14  40401.1276569   40401.347469  0           PM: Preparing system for mem sleep
Jan 13 11:23:21  45688.1276569   40402.128198  -5280       Skipping EDID probe due to cached edid
Jan 13 11:23:21  45688.1276569   40402.729152  -5280       Freezing user space processes ... (elapsed 0.03 seconds) done.
Jan 13 11:23:21  45688.1276569   40402.760110  -5280       Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Jan 13 11:23:21  45688.1276569   40402.776102  -5280       PM: Entering mem sleep

... rel_offset-5280 для всех остальных строк ...

Jan 13 11:23:21  45688.1276569   40403.149074  -5280       ACPI: Preparing to enter system sleep state S3
Jan 13 11:23:21  45688.1276569   40403.149477  -5280       PM: Saving platform NVS memory
Jan 13 11:23:21  45688.1276569   40403.149495  -5280       Disabling non-boot CPUs ...
Jan 13 11:23:21  45688.1276569   40403.149495  -5280       Back to C!
Jan 13 11:23:21  45688.1276569   40403.149495  -5280       PM: Restoring platform NVS memory
Jan 13 11:23:21  45688.1276569   40403.151034  -5280       ACPI: Waking up from system sleep state S3

... Финальные строки находятся чуть дальше, все еще намного выше конца вывода. Некоторые из них, по-видимому, были записаны в dmesgкруговой буфер до того, как произошло приостановление, и были распространены только syslogпосле этого. Это объясняет, почему все они имеют одинаковую метку времени системного журнала.

Определения столбцов:

abs время, зарегистрированное системным журналом.

abs_since_bootэто то же самое время в секундах с момента запуска системы, основанное на содержании /proc/uptimeи значении time.time().

rel_time это временная метка ядра.

rel_offsetэто разница между abs_since_bootи rel_time. Я округляю это до десятков секунд, чтобы избежать одноразовых ошибок, поскольку абсолютные (то есть syslogсгенерированные) временные метки имеют точность только в секундах. Это на самом деле неправильный способ сделать это, так как это действительно (я думаю ..) просто приводит к меньшей вероятности ошибки, превышающей 10. Если у кого-то есть идея получше, пожалуйста, дайте мне знать.

У меня также есть несколько вопросов о формате даты syslog; в частности, мне интересно, появится ли в этом году год. Я предполагаю, что нет, и в любом случае, скорее всего, смогу помочь себе получить эту информацию в TFM, но если кто-то узнает, что это будет полезно. Конечно, если предположить, что кто-то использует этот сценарий в будущем, вместо того, чтобы просто разрушить пару строк кода на Perl.

Следующий:

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

linux  xorg  logs  timestamps 
— созерцаемое
источник
1
Я думаю, что это квалифицируется как ошибка и должно быть сообщено. Кстати, syslog-ng использует нормальные временные метки, которые вы можете сортировать sort, иметь год, часовой пояс и т. Д. +1 для скрипта python.
— стрибика
@stribika: это будет проблема ядра или системного журнала? Или оба? Похоже, системный журнал должен быть уведомлен о том, что система была приостановлена ​​.. возможно, он мог бы сделать это сам с перехватом приостановки и возобновления.
— интуитивно
Мне кажется, что ядро ​​виновато. Значения rel_time не «пропускают» время, пока система была приостановлена. Я нахожу странным, однако, что перекос начинается до того, как приостановка действительно произойдет. Значения уже неправильные, для Freezing user space processesкоторых это явно сделано перед сном.
— стрибика
2
@stribika: Моя рабочая теория заключается в том, что эти события не помещаются в системный журнал до тех пор, пока не возобновится, потому что они происходят после того, как сам системный журнал был приостановлен.
— интуитивно
@stribika: Кроме того, вы правы в том, что ядро ​​«виновато»: насколько я понимаю (после повторного рассмотрения), syslog просто ставит префикс абсолютной метки времени к тексту (начиная с [12345.6789]..), излучаемому ядром, поэтому он все делает правильно , с учетом вопросов, рассмотренных в моем последнем комментарии. Я не уверен, что ядро ​​действительно должно делать здесь; это зависит от того, что означают эти временные метки запуска. Время выполнения (в отличие от времени с момента загрузки) может иметь смысл в некоторых контекстах. Я думаю, что в идеале должна быть надежная запись обоих этих значений.
— интуитивно

Ответы:

4

Интересная проблема, Не уверен, что я когда-либо пытался сделать это. Но я заметил метку времени, о которой ты говоришь, и я всегда считал, что она была секундами с момента загрузки.

В моем системном журнале у меня на сервере есть:

Jan 10 19:58:55 wdgitial kernel: [    0.000000] Initializing cgroup subsys cpuset
Jan 10 19:58:55 wdgitial kernel: [    0.000000] Initializing cgroup subsys cpu
Jan 10 19:58:55 wdgitial kernel: [    0.000000] Linux version 2.6.32-21-server (buildd@yellow) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #32-Ubuntu SMP Fri Apr 16     09:17:34 UTC 2010 (Ubuntu 2.6.32-21.32-server 2.6.32.11+drm33.2)
Jan 10 19:58:55 wdgitial kernel: [    0.000000] Command line:  root=/dev/xvda1 ro quiet splash

Я полагаю, что это довольно непротиворечиво в большинстве дистрибутивов Linux, поскольку это ядро ​​выплевывает свои вещи.

И здесь у меня есть дата вместе с отметкой времени.

— Райан Гиббонс
источник
3

Вы можете попробовать это:

Во-первых, получите метку времени файла dmesg (я предполагаю, что это будет время dmesg 0). Вы будете использовать

ls -l - time-style = +% s

/var/log$ ls -l --time-style=+%s dmesg
-rw-r----- 1 root adm 56181 1294941018 dmesg

Вы можете преобразовать секунды в удобочитаемую дату с

perl -e 'print scalar localtime(1294941018)'

Чтобы увидеть читаемое время события, добавьте в секундах от события в dmesg. Если событие dmesg прошло 55.290387 секунд, добавьте 55 или 55.290387:

perl -e 'print scalar localtime(1294953978 + 55)'

Другой способ преобразовать укоренившиеся в эпоху секунды в читаемое время - использовать дату -d, как предложено. Если вы укажете 'date' для обозначения времени, указанного в -d, вы можете указать, что время для преобразования в секундах с начала эпохи, используя @.

date -d "@1294953978"

В результате вы получите что-то вроде «Чт 13 января 15:26:18 CST 2011».

дата +% s
напечатает текущее время в формате секунд с начала эпохи.

Я не могу вспомнить, как выполнять shell-математику, поэтому я обычно использую метод perl, как указано выше. :)

— belacqua
источник
1
@jgbelacqua: Вы хотите date -d @$((1294953978 + 55)), по крайней мере, под Bash. Однако некоторые временные метки ядра искажены, это означает, что время, создаваемое этим методом, будет раньше, чем соответствующие им временные метки в /var/log/syslog. Похоже, что это происходит в результате событий приостановки в ОЗУ, предположительно в дополнение к гибернации и, возможно, некоторым другим вещам, потому что время ядра не увеличивается в течение этих периодов. Смотрите обновление вопроса для получения дополнительной информации.
— интуитивно
2

Самый простой способ отобразить число из dmesg на дату - использовать dateпрограмму.

date -d "-50595 seconds"

Эта команда отображает дату для текущего времени минус 50595 секунд.

От man date:

-d, --date=STRING
       display time described by STRING, not `now'

Число равно времени включения, а не времени, прошедшему с момента загрузки.

— Lekensteyn
источник
2

Так как вы заметили, что во время приостановки / возобновления изменяется перекос времени, я отмечу, что это задокументировано как минимум в одном месте. Страница руководства dmesg (1) гласит:

Источник времени, используемый для журналов, не обновляется после системы SUSPEND / RESUME.

Я не смог найти способ заставить ядро ​​синхронизировать эти временные метки с настенным временем.

— Андрей
источник
1

Быстро, грязно, работает.

$ dmesg | grep 3w | perl /root/print_time_offset.pl

Содержание этого скрипта:

$ cat /root/print_time_offset.pl

#!/usr/bin/perl

$uptime = `cat /proc/uptime | awk '{print $1}';`;
$boot = time() - $uptime;
chomp $boot;
while (<STDIN>) {
        if ($_ =~ /^\[([\s\d\.]+)\]/) {
                $time_offset = $1;
        }
        $real_time = sprintf scalar localtime($boot + $time_offset);
        $_ =~ s/\[[\s\d\.]+\]/\[$real_time\]/;
        print $_;
}

Пример вывода выглядит следующим образом:

[Mon Feb 21 23:06:33 2011] 3ware 9000 Storage Controller device driver for Linux v2.26.02.012.
[Mon Feb 21 23:06:33 2011] 3w-9xxx 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[Mon Feb 21 23:06:33 2011] 3w-9xxx 0000:03:00.0: setting latency timer to 64
[Mon Feb 21 23:06:33 2011] scsi4 : 3ware 9000 Storage Controller
[Mon Feb 21 23:06:33 2011] 3w-9xxx: scsi4: Found a 3ware 9000 Storage Controller at 0xfbcde000, IRQ: 16.
[Mon Feb 21 23:06:34 2011] 3w-9xxx: scsi4: Firmware FE9X 4.08.00.006, BIOS BE9X 4.08.00.001, Ports: 4.
[Mon Feb 21 23:06:35 2011] 3w-9xxx: scsi4: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[Mon Feb 21 23:06:35 2011] 3w-9xxx: scsi4: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[Mon Feb 21 23:06:35 2011] 3w-9xxx: scsi4: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[Mon Feb 21 23:06:35 2011] 3w-9xxx: scsi4: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[Mon Feb 21 23:06:35 2011] 3w-9xxx: scsi4: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[Mon Feb 21 23:06:35 2011] 3w-9xxx: scsi4: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[Sat Feb 26 02:01:01 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x0029): Verify started:unit=0, subunit=1.
[Sat Feb 26 02:01:01 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x0029): Verify started:unit=0, subunit=0.
[Sat Feb 26 16:49:13 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x002B): Verify completed:unit=0, subunit=1.
[Sat Feb 26 17:07:19 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x002B): Verify completed:unit=0, subunit=0.
[Sat Mar  5 02:00:16 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x0029): Verify started:unit=0, subunit=1.
[Sat Mar  5 02:00:16 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x0029): Verify started:unit=0, subunit=0.
[Sat Mar  5 18:48:57 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x002B): Verify completed:unit=0, subunit=1.
[Sat Mar  5 19:05:17 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x002B): Verify completed:unit=0, subunit=0.
[Sat Mar 12 02:00:30 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x0029): Verify started:unit=0, subunit=1.
[Sat Mar 12 02:00:30 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x0029): Verify started:unit=0, subunit=0.
— Dacav
источник
1
Я предполагаю, что вы только прочитали первые пару абзацев вопроса. Проверьте это снова более подробно. Или, в качестве альтернативы, попробуйте приостановить работу своего компьютера и проверить, правильно ли ваш сценарий сообщает абсолютные метки времени новых зарегистрированных сообщений.
— интуитивно
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.