Linux管理者-ログ管理
systemdは、CentOSLinuxのシステムログの管理方法を変更しました。システム上のすべてのデーモンがログを個々の場所に配置する代わりに、ログエントリを並べ替えてフィルタリングする主な方法としてtailやgrepなどのツールを使用します。journald システムログの分析に単一の管理ポイントをもたらしました。
systemdロギングの背後にある主なコンポーネントは、journal、jounralctl、journald.confです。
journaldはメインのロギングデーモンであり、journald.confを編集して構成され、journalctlはjournaldによってログに記録されたイベントを分析するために使用されます。
journaldによってログに記録されるイベントには、カーネルイベント、ユーザープロセス、およびデーモンサービスが含まれます。
正しいシステムタイムゾーンを設定する
journalctlを使用する前に、システム時刻が正しい時刻に設定されていることを確認する必要があります。これを行うには、timedatectlを使用します。
現在のシステム時刻を確認しましょう。
[root@centos rdc]# timedatectl status
Local time: Mon 2017-03-20 00:14:49 MDT
Universal time: Mon 2017-03-20 06:14:49 UTC
RTC time: Mon 2017-03-20 06:14:49
Time zone: America/Denver (MDT, -0600)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: yes
Last DST change: DST began at
Sun 2017-03-12 01:59:59 MST
Sun 2017-03-12 03:00:00 MDT
Next DST change: DST ends (the clock jumps one hour backwards) at
Sun 2017-11-05 01:59:59 MDT
Sun 2017-11-05 01:00:00 MST
[root@centos rdc]#
現在、システムはローカルタイムゾーンに対して正しいです。システムがそうでない場合は、正しいタイムゾーンを設定しましょう。設定を変更した後、CentOSは現在のタイムゾーンからのタイムゾーンオフセットを自動的に計算し、システムクロックをすぐに調整します。
timedatectl −を使用してすべてのタイムゾーンを一覧表示しましょう。
[root@centos rdc]# timedatectl list-timezones
Africa/Abidjan
Africa/Accra
Africa/Addis_Ababa
Africa/Algiers
Africa/Asmara
Africa/Bamako
Africa/Bangui
Africa/Banjul
Africa/Bissau
これは、timedatectllist-timezonesからの競合する出力です。特定のローカルタイムゾーンを見つけるには、grepコマンドを使用できます-
[root@centos rdc]# timedatectl list-timezones | grep -i "america/New_York"
America/New_York
[root@centos rdc]#
CentOSで使用されるラベルは通常、スペースではなくアンダースコアが付いた国/地域です(New_Yorkと "New York")。
それでは、タイムゾーンを設定しましょう-
[root@centos rdc]# timedatectl set-timezone "America/New_York"
[root@centos rdc]# date
Mon Mar 20 02:28:44 EDT 2017
[root@centos rdc]#
システムクロックは自動的に時間を調整する必要があります。
journalctlを使用してログを分析する
journalctlを使用する場合の一般的なコマンドラインスイッチ-
スイッチ | アクション |
---|---|
-k | カーネルメッセージのみを一覧表示します |
-u | 特定のユニット(httpd、sshdなど)ごとのリスト |
-b | ラベルオフセットを起動します |
-o | 出力形式をログに記録します |
-p | ログタイプ(名前または番号)でフィルタリングします |
-F | フィールド名またはフィールド名値 |
- UTC | UTCオフセットでの時間 |
-以来 | 時間枠でフィルタリング |
ブートログを調べる
まず、CentOSLinuxでブートログを調べて構成します。最初に気付くのは、CentOSはデフォルトで、再起動後も永続するブートログを保存しないことです。
再起動インスタンスごとのブートログを確認するには、次のコマンドを発行できます-
[root@centos rdc]# journalctl --list-boots
-4 bca6380a31a2463aa60ba551698455b5 Sun 2017-03-19 22:01:57 MDT—Sun 2017-03-19 22:11:02 MDT
-3 3aaa9b84f9504fa1a68db5b49c0c7208 Sun 2017-03-19 22:11:09 MDT—Sun 2017-03-19 22:15:03 MDT
-2 f80b231272bf48ffb1d2ce9f758c5a5f Sun 2017-03-19 22:15:11 MDT—Sun 2017-03-19 22:54:06 MDT
-1 a071c1eed09d4582a870c13be5984ed6 Sun 2017-03-19 22:54:26 MDT—Mon 2017-03-20 00:48:29 MDT
0 9b4e6cdb43b14a328b1fa6448bb72a56 Mon 2017-03-20 00:48:38 MDT—Mon 2017-03-20 01:07:36 MDT
[root@centos rdc]#
システムを再起動すると、別のエントリが表示されます。
[root@centos rdc]# journalctl --list-boots
-5 bca6380a31a2463aa60ba551698455b5 Sun 2017-03-19 22:01:57 MDT—Sun 2017-03-19 22:11:02 MDT
-4 3aaa9b84f9504fa1a68db5b49c0c7208 Sun 2017-03-19 22:11:09 MDT—Sun 2017-03-19 22:15:03 MDT
-3 f80b231272bf48ffb1d2ce9f758c5a5f Sun 2017-03-19 22:15:11 MDT—Sun 2017-03-19 22:54:06 MDT
-2 a071c1eed09d4582a870c13be5984ed6 Sun 2017-03-19 22:54:26 MDT—Mon 2017-03-20 00:48:29 MDT
-1 9b4e6cdb43b14a328b1fa6448bb72a56 Mon 2017-03-20 00:48:38 MDT—Mon 2017-03-20 01:09:57 MDT
0 aa6aaf0f0f0d4fcf924e17849593d972 Mon 2017-03-20 01:10:07 MDT—Mon 2017-03-20 01:12:44 MDT
[root@centos rdc]#
それでは、最後のブートログインスタンスを調べてみましょう-
root@centos rdc]# journalctl -b -5
-- Logs begin at Sun 2017-03-19 22:01:57 MDT, end at Mon 2017-03-20 01:20:27 MDT. --
Mar 19 22:01:57 localhost.localdomain systemd-journal[97]: Runtime journal is using 8.0M
(max allowed 108.4M
Mar 19 22:01:57 localhost.localdomain kernel: Initializing cgroup subsys cpuset
Mar 19 22:01:57 localhost.localdomain kernel: Initializing cgroup subsys cpu
Mar 19 22:01:57 localhost.localdomain kernel: Initializing cgroup subsys cpuacct
Mar 19 22:01:57 localhost.localdomain kernel: Linux version 3.10.0514.6.2.el7.x86_64
([email protected].
Mar 19 22:01:57 localhost.localdomain kernel: Command line:
BOOT_IMAGE=/vmlinuz-3.10.0-514.6.2.el7.x86_64 ro
Mar 19 22:01:57 localhost.localdomain kernel: Disabled fast string operations
Mar 19 22:01:57 localhost.localdomain kernel: e820: BIOS-provided physical RAM map:
上記は、前回の起動からの要約出力です。また、数時間、数日、数週間、数か月、さらには数年のブートログを参照することもできます。ただし、デフォルトでは、CentOSは永続的なブートログを保存しません。ブートログを永続的に保存できるようにするには、いくつかの構成変更を行う必要があります-
- ブートログの中央ストレージポイントを作成します
- 新しいログフォルダに適切な権限を付与します
- 永続ログ用にjournald.confを構成します
永続的なブートログのブート場所を構成する
journaldが永続的なブートログを保存する最初の場所は/ var / log / journalです。これはデフォルトでは存在しないので、作成しましょう-
[root@centos rdc]# mkdir /var/log/journal
それでは、ディレクトリに適切な権限を与えましょう。journaldデーモンアクセス-
systemd-tmpfiles --create --prefix /var/log/journal
最後に、ジャーナルに永続的なブートログを保存するように伝えましょう。でvimのか、お好きなテキストエディタ、オープン/etc/systemd/jounrald.conf」。
# See journald.conf(5) for details.
[Journal]=Storage=peristent
私たちが関わっている行は、Storage =です。最初にコメント#を削除してから、に変更しますStorage = persistent上に描かれているように。CentOSシステムを保存して再起動し、journalctllist-bootsを実行するときに複数のエントリが存在するように注意してください。
Note− VPSプロバイダーからのような絶えず変化するマシンIDにより、journaldが永続的なブートログの保存に失敗する可能性があります。このようなシナリオには多くの回避策があります。もっともらしいVPS回避策を見つけた人からの信頼できるアドバイスに従うよりも、CentOS管理フォーラムに投稿された現在の修正を熟読するのが最善です。
特定のブートログを調べるには、journald --list-bootsを使用して各オフセットを取得し、-bスイッチを使用する必要があります。したがって、2番目のブートログを確認するために使用します-
journalctl -b -2
ブートログオフセットが指定されていない-bのデフォルトは、最後の再起動後の現在のブートログになります。
ログタイプによるログの分析
ジャーナルからのイベントには番号が付けられ、7つの異なるタイプに分類されます-
0 - emerg :: System is unusable
1 - alert :: Action must be taken immediatly
2 - crit :: Action is advised to be taken immediatly
3 - err :: Error effecting functionality of application
4 - warning :: Usually means a common issue that can affect security or usilbity
5 - info :: logged informtation for common operations
6 - debug :: usually disabled by default to troubleshoot functionality
したがって、すべての警告を確認したい場合は、journalctl −を介して次のコマンドを発行できます。
[root@centos rdc]# journalctl -p 4
-- Logs begin at Sun 2017-03-19 22:01:57 MDT, end at Wed 2017-03-22 22:33:42 MDT. --
Mar 19 22:01:57 localhost.localdomain kernel: ACPI: RSDP 00000000000f6a10 00024
(v02 PTLTD )
Mar 19 22:01:57 localhost.localdomain kernel: ACPI: XSDT 0000000095eea65b 0005C
(v01 INTEL 440BX 06040000 VMW 01
Mar 19 22:01:57 localhost.localdomain kernel: ACPI: FACP 0000000095efee73 000F4
(v04 INTEL 440BX 06040000 PTL 00
Mar 19 22:01:57 localhost.localdomain kernel: ACPI: DSDT 0000000095eec749 1272A
(v01 PTLTD Custom 06040000 MSFT 03
Mar 19 22:01:57 localhost.localdomain kernel: ACPI: FACS 0000000095efffc0 00040
Mar 19 22:01:57 localhost.localdomain kernel: ACPI: BOOT 0000000095eec721 00028
(v01 PTLTD $SBFTBL$ 06040000 LTP 00
Mar 19 22:01:57 localhost.localdomain kernel: ACPI: APIC 0000000095eeb8bd 00742
(v01 PTLTD ? APIC 06040000 LTP 00
Mar 19 22:01:57 localhost.localdomain kernel: ACPI: MCFG 0000000095eeb881 0003C
(v01 PTLTD $PCITBL$ 06040000 LTP 00
Mar 19 22:01:57 localhost.localdomain kernel: ACPI: SRAT 0000000095eea757 008A8
(v02 VMWARE MEMPLUG 06040000 VMW 00
Mar 19 22:01:57 localhost.localdomain kernel: ACPI: HPET 0000000095eea71f 00038
(v01 VMWARE VMW HPET 06040000 VMW 00
Mar 19 22:01:57 localhost.localdomain kernel: ACPI: WAET 0000000095eea6f7 00028
(v01 VMWARE VMW WAET 06040000 VMW 00
Mar 19 22:01:57 localhost.localdomain kernel: Zone ranges:
Mar 19 22:01:57 localhost.localdomain kernel: DMA [mem 0x000010000x00ffffff]
Mar 19 22:01:57 localhost.localdomain kernel: DMA32 [mem 0x010000000xffffffff]
Mar 19 22:01:57 localhost.localdomain kernel: Normal empty
Mar 19 22:01:57 localhost.localdomain kernel: Movable zone start for each node
Mar 19 22:01:57 localhost.localdomain kernel: Early memory node ranges
Mar 19 22:01:57 localhost.localdomain kernel: node 0: [mem 0x000010000x0009dfff]
Mar 19 22:01:57 localhost.localdomain kernel: node 0: [mem 0x001000000x95edffff]
Mar 19 22:01:57 localhost.localdomain kernel: node 0: [mem 0x95f000000x95ffffff]
Mar 19 22:01:57 localhost.localdomain kernel: Built 1 zonelists in Node order,
mobility grouping on. Total pages: 60
Mar 19 22:01:57 localhost.localdomain kernel: Policy zone: DMA32
Mar 19 22:01:57 localhost.localdomain kernel: ENERGY_PERF_BIAS: Set to
'normal', was 'performance'
上記は、システム上の過去4日間のすべての警告を示しています。
systemdを使用してログを表示および閲覧する新しい方法は、慣れるためにほとんど練習や調査を必要としません。ただし、出力形式が異なり、パッケージ化されたすべてのデーモンログをユニバーサルにすることに特に注意する必要があるため、採用する価値があります。journaldは、従来のログ分析方法に比べて優れた柔軟性と効率を提供します。