การประทับเวลาสหสัมพันธ์ / var / log / *

/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และแสดงเวลาที่เบี่ยงเบน บนเครื่องของฉันรันอูบุนตู 10.10, ไฟล์นั้นมีหลายบรรทัดเคอร์เนลที่มาจากการประทับทั้ง dmesg timestamp และ syslog timestamp สคริปต์เอาต์พุตบรรทัดสำหรับแต่ละบรรทัดในไฟล์นั้นซึ่งมีเวลาประทับเคอร์เนล

การใช้งาน:

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ภายหลังเท่านั้น สิ่งนี้อธิบายว่าทำไมพวกเขาทั้งหมดจึงมีการประทับเวลา syslog เดียวกัน

คำจำกัดความของคอลัมน์:

abs เป็นเวลาที่บันทึกโดย syslog

abs_since_bootคือว่าเวลาเดียวกันในไม่กี่วินาทีนับตั้งแต่การเริ่มต้นระบบขึ้นอยู่กับเนื้อหาของและความคุ้มค่าของ/proc/uptimetime.time()

rel_time คือการประทับเวลาเคอร์เนล

rel_offsetคือความแตกต่างระหว่างและabs_since_boot rel_timeฉันปัดเศษนี้เป็นสิบวินาทีเพื่อหลีกเลี่ยงข้อผิดพลาดครั้งเดียวเนื่องจากการsyslogประทับเวลาสัมบูรณ์ (เช่น - สร้าง) ที่มีความแม่นยำเพียงวินาทีเท่านั้น ที่จริงแล้วไม่ใช่วิธีที่ถูกต้องที่จะทำเพราะจริงๆ (ฉันคิดว่า .. ) เพียงส่งผลให้มีโอกาสน้อยที่จะมีข้อผิดพลาดออกไป 10 หากใครมีความคิดที่ดีกว่าโปรดแจ้งให้เราทราบ

ฉันยังมีคำถามบางอย่างเกี่ยวกับรูปแบบวันที่ของ syslog; โดยเฉพาะอย่างยิ่งฉันสงสัยว่าปีที่เคยปรากฏในนั้น ฉันคาดเดาไม่ได้และในกรณีใด ๆ อาจช่วยตัวเองให้ได้ข้อมูลใน TFM แต่ถ้ามีคนรู้ว่ามันจะมีประโยชน์ .. แน่นอนว่ามีบางคนใช้สคริปต์นี้ในอนาคตในบางจุดแทนที่จะใช้โค้ด Perl สองสามบรรทัด

ต่อไป:

ดังนั้นหากมีการเปิดเผยต้อนรับบางอย่างจากฉันที่ได้รับจากคุณขั้นตอนต่อไปของฉันคือการเพิ่มฟังก์ชั่นเพื่อให้ได้เวลาที่แม่นยำสำหรับการประทับเวลาเคอร์เนลที่กำหนด ฉันควรจะสามารถป้อนสคริปต์หนึ่งหรือชุดของ syslogs พร้อมกับเคอร์เนลการประทับเวลาเพื่อให้ได้เวลาประทับที่แน่นอน จากนั้นฉันจะกลับไปแก้จุดบกพร่อง Xorg ของฉันซึ่งหนีฉันไปในตอนนี้

ปัญหาที่น่าสนใจไม่แน่ใจว่าฉันเคยลองทำ แต่ฉันสังเกตเห็นเวลาที่คุณกำลังพูดถึงและฉันมักจะเชื่อว่ามันเป็นวินาทีตั้งแต่ bootup

ใน syslog ของฉันฉันมีบนเซิร์ฟเวอร์ของฉันฉันมี:

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

ฉันคิดว่านี่เป็นสิ่งที่สอดคล้องกันในหมู่ดิสทริบิวเตอร์ส่วนใหญ่เนื่องจากนี่เป็นเคอร์เนลที่คายออกมา

และที่นี่ฉันมีวันที่พร้อมกับการประทับเวลา

คุณสามารถลองทำสิ่งนี้:

ก่อนอื่นรับเวลาประทับของไฟล์ dmesg (ข้อสันนิษฐานของฉันคือนี่จะเป็นเวลาของ dmesg 0) คุณจะใช้

ls -l - ไทม์สไตล์ = +% 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)'

อีกวิธีในการแปลงวินาทีที่มีราก epochal เป็นเวลาที่อ่านได้คือการใช้ date -d ตามที่แนะนำ หากคุณบอกให้ 'date' แสดงถึงเวลาที่ให้มาพร้อมกับ -d คุณสามารถระบุได้ว่าเวลาที่จะถูกแปลงนั้นเป็นวินาทีวินาทีนับตั้งแต่ยุคโดยใช้ @

date -d "@1294953978"

สิ่งนี้ให้สิ่งที่คุณต้องการ "พฤ. 13 ม.ค. 15:26:18 CST 2011" เป็นเอาต์พุต

วันที่ +% s

ฉันจำไม่ได้ว่าจะทำเชลล์คณิตศาสตร์อย่างไรฉันมักจะใช้วิธี Perl ตามด้านบน :)

วิธีที่ง่ายที่สุดในการจับคู่ตัวเลขจาก dmesg กับวันที่คือการใช้dateโปรแกรม

date -d "-50595 seconds"

คำสั่งนี้แสดงวันที่สำหรับเวลาปัจจุบันลบ 50595 วินาที

จากman date:

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

จำนวนเท่ากับเวลาเปิดเครื่องไม่ใช่เวลาที่ผ่านไปตั้งแต่เวลาบูต

เนื่องจากคุณสังเกตว่าเวลาเปลี่ยนแปลงไประหว่างการหยุดชั่วคราว / ดำเนินการต่อฉันจะทราบว่าเอกสารนี้มีการบันทึกอย่างน้อยหนึ่งแห่ง หน้า man dmesg (1) พูดว่า:

แหล่งเวลาที่ใช้สำหรับบันทึกไม่ได้รับการอัปเดตหลังจากระบบ SUSPEND / RESUME

ฉันไม่สามารถหาวิธีที่จะทำให้เคอร์เนลรักษาเวลาประทับเหล่านี้ให้สอดคล้องกับเวลาที่กำหนด

รวดเร็วสกปรกใช้งานได้

$ 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.