Linuxロギング完全ガイド

Linuxシステム管理者として、ログファイルの検査 実行しなければならない可能性のある最も一般的なタスクの1つです。

Linuxログ 重要です：システムで発生する可能性のあるいくつかのエラーに関する重要な情報を保存します。

また、誰がシステムにアクセスしようとしているのか、特定のサービスが何をしているのか、または以前に発生したシステムクラッシュに関する情報も保存される場合があります。

結果として、場所を特定する方法を知る、操作およびログファイルの解析 間違いなくあなたが習得しなければならないスキルです。

このチュートリアルでは、Linuxロギングについて知っておくべきことをすべて明らかにします。

Linuxシステムでのロギングのアーキテクチャの方法が表示されますさまざまな仮想デバイスとプロセスがどのように相互作用してエントリをログに記録するか。

Syslogプロトコルについてさらに深く掘り下げていきます。また、syslogd（古いシステムの場合）から最近のシステムのsystemdを利用したjournalctlにどのように移行したか。

Linuxロギングタイプ

Linuxロギングを扱う場合、ターミナルでコマンドを入力する前に理解しておく必要のある基本事項がいくつかあります。

Linuxでは、2種類のロギングメカニズムがあります：

カーネルロギング ：カーネルが書き込む可能性のあるエラー、警告、または情報エントリに関連します。
ユーザーロギング ：ユーザースペースにリンクされているこれらのログエントリは、ホストマシンで実行される可能性のあるプロセスまたはサービスに関連しています。

ロギングを2つのカテゴリに分割することにより、Linuxではメモリ自体が2つのカテゴリに分割されていることを基本的に明らかにしています：ユーザースペース およびカーネルスペース 。

カーネルロギング

まず、カーネルロギングとも呼ばれるカーネルスペースに関連付けられたロギングから始めましょう。

カーネルスペースでは、ロギングはカーネルリングバッファを介して行われます。

カーネルリングバッファは、システムの起動時にログメッセージを格納する最初のデータ構造である循環バッファです。

Linuxマシンを起動しているときに、ログメッセージが画面に表示されている場合、それらのメッセージはカーネルリングバッファに保存されます。

カーネルログは、ユーザーログの前に開始されます（syslogデーモンまたは最近のディストリビューションのrsyslogによって管理されます）。

カーネルリングバッファは、システム上の他のログファイルとほとんど同じように検査できます。

システムでカーネル関連のログを開くには、「 dmesg」を使用する必要があります」コマンド。

注：カーネルリングバッファを検査するには、このコマンドをrootとして実行するか、特権権限を持っている必要があります。

$ dmesg

ご覧のとおり、システムの起動からコマンドを実行するまで、カーネルはカーネル空間で発生する可能性のあるすべてのアクション、警告、またはエラーを追跡します。

システムでディスクの検出またはマウントに問題がある場合は、おそらくここでエラーを検査する必要があります。

ご覧のとおり、dmesgコマンドはカーネルログを表示するための非常に優れたインターフェイスですが、dmesgコマンドはどのようにしてそれらの結果を出力しますか？

使用されているさまざまなメカニズムを明らかにするために、どのプロセスとデバイスがカーネルロギングを処理するかを見てみましょう。。

カーネルロギングの内部

おそらく前に聞いたことがあると思いますが、Linuxではすべてがファイルです。

すべてがファイルである場合、それはデバイスがファイルであることも意味します。

Linuxでは、カーネルリングバッファは/ devディレクトリ内の文字デバイスファイルによって具体化され、kmsgという名前が付けられます。

$ ls -l /dev/ | grep kmsg

kmsgデバイスとカーネルリングバッファの関係を表す場合、これがその表現方法です。

ご覧のとおり、kmsgデバイスは抽象化です。カーネルリングバッファの読み取りと書き込みに使用されます。

基本的に、カーネルリングバッファに書き込むためのユーザースペースプロセスのエントリポイントと見なすことができます。

ただし、カーネルログ情報をファイルにダンプするために1つの特別なファイルがカーネルによって使用されるため、上記の図は不完全です。

要約すると、基本的にkmsg仮想デバイスがエントリポイントとして機能すると述べます。このプロセスの出力（ログ行）が/ proc/kmsgファイルに出力されている間のカーネルリングバッファの場合。

このファイルは、ほとんどの場合、ユーザースペースで使用されるロギングユーティリティである単一のプロセスでのみ解析できます。一部のディストリビューションではsyslogdを使用できますが、最近のディストリビューションではrsyslogと統合されています。

rsyslogユーティリティには、カーネルログをファイルシステム上の専用ファイルにリダイレクトする一連の組み込みモジュールがあります。

歴史的に、カーネルログはklogdデーモンによって取得されていました以前のシステムでは、ほとんどのディストリビューションでrsyslogに置き換えられました。

一方では、ロギングユーティリティがリングバッファから読み取っていますが、ユーザースペースプログラムがリングバッファに書き込んでいます。たとえば、最近のディストリビューションではsystemd（有名なsystemd-journalを使用）です。

カーネルロギングについて詳しく知ったところで、ユーザースペースでロギングがどのように行われるかを見てみましょう。

Syslogを使用したユーザー側のロギング

ユーザースペースへのログオンは、カーネルスペースへのログオンとはまったく異なります。

ユーザー側では、ロギングはSyslogプロトコルに基づいています。

Syslogは、Linuxインスタンスで生成されたログを生成、転送、および収集するための標準として使用されます。

Syslogは、重大度レベルとファシリティレベルを定義し、ユーザーが自分のコンピューターで生成されたログをより深く理解できるようにします。

ログは、後でSyslogサーバーと呼ばれるサーバーで分析および視覚化できます。

つまり、Syslogプロトコルは、Unixシステムでフォーマット、送受信されるログメッセージを定義するために使用されるプロトコルです。

Syslogは、ログを送信するためにアプリケーションが使用する必要のある形式を定義するsyslog形式を定義することで知られています。

この形式は、2つの重要な用語を定義することでよく知られています：施設および優先順位 。

Syslog機能の説明

つまり、施設レベル ログを生成したプログラムまたはシステムの一部を判別するために使用されます。

Linuxシステムでは、さまざまなユーティリティやプログラムがログを送信しています。そもそもどのプロセスがログを送信したかを判断するために、Syslogは、プログラムがSyslogログを送信するために使用する番号（施設番号）を定義します。

以下の表で説明されている23を超えるSyslog機能があります。

数値コード	キーワード	施設名
0	カーン	カーネルメッセージ
1	ユーザー	ユーザーレベルのメッセージ
2	メール	メールシステム
3	デーモン	システムデーモン
4	auth	セキュリティメッセージ
5	syslog	Syslogdメッセージ
6	lpr	ラインプリンタサブシステム
7	ニュース	ネットワークニュースサブシステム
8	uucp	UUCPサブシステム
9	cron	クロックデーモン
10	authpriv	セキュリティメッセージ
11	ftp	FTPデーモン
12	ntp	NTPサブシステム
13	セキュリティ	セキュリティログ監査
14	コンソール	コンソールログアラート
15	solaris-cron	ログのスケジュール
16-23	local0からlocal7	地元で使用されている施設

これらの機能のほとんどは、システムプロセス（1つまたはcronユーティリティがある場合はメールサーバーなど）に予約されています。それらの一部（施設番号16から23まで）は、カスタムSyslogクライアントまたはユーザープログラムがログを送信するために使用できます。

Syslogの優先順位の説明

Syslogの重大度レベル ログイベントの重大度に慣れており、デバッグ、情報メッセージから緊急レベルまでさまざまです。

Syslog施設レベルと同様に、重大度レベルは0から7の範囲の数値カテゴリに分類され、0は最も重大な緊急レベルです。。

繰り返しになりますが、Syslogで利用可能なすべての優先度レベルの表を次に示します。

表に記載されているsyslogの重大度レベルは次のとおりです。

値	重大度	キーワード
0	緊急事態	`emerg`
1	アラート	`alert`
2	重要	`crit`
3	エラー	`err`
4	警告	`warning`
5	通知	`notice`
6	情報	`info`
7	デバッグ	`debug`

Syslogアーキテクチャ

Syslogは、ロギングシステムのアーキテクチャを構築するために使用されるいくつかの技術用語も定義しています：

発信者 ：「Syslogクライアント」とも呼ばれる発信者は、Syslog形式のメッセージをネットワーク経由または正しいアプリケーションに送信する責任があります。
リレー ：ネットワークを介してメッセージを転送するためにリレーが使用されます。リレーは、たとえばメッセージを充実させるためにメッセージを変換できます（有名な例にはLogstashやfluentdが含まれます）。
コレクター ：「Syslogサーバー」とも呼ばれるコレクターは、複数のアプリケーションからログを保存、視覚化、および取得するために使用されます。コレクターは、ローカルファイル、データベース、キャッシュなど、さまざまな出力にログを書き込むことができます。

ご覧のとおり、Syslogプロトコルはクライアントサーバーアーキテクチャに準拠しています。以前のチュートリアルで見ました。

1つのSyslogクライアントがメッセージを作成し、それをオプションのローカルリレーまたは遠隔リレーに送信します。これらのリレーはさらにSyslogサーバーに転送できます。

Syslogプロトコルがどのようにアーキテクチャ化されているかがわかったところで、私たち自身のLinuxシステムについてはどうでしょうか。

このアーキテクチャに準拠していますか？

Linuxローカルロギングアーキテクチャ

ローカルLinuxシステムへのログオンは、前に説明した正確な原則に従います。

面倒なことはありませんが、Linuxシステム（最近のディストリビューション）でロギングを構築する方法は次のとおりです。

ローカルLinuxシステムの場合、前述のoriginator-relay-collectorアーキテクチャに従います：

発信者はクライアントアプリケーションですログを送信するためにsyslogまたはジャーナルライブラリを埋め込む場合があります。
デフォルトでは、リレーはローカルに実装されていません。
コレクターはrsyslogとjournaldデーモンです事前定義されたソケットで着信ログをリッスンします。

では、コレクターが受信したログはどこに保存されますか？

Linuxログファイルの場所

Linuxシステムでは、ログは / var / logに保存されますディレクトリ。

/ var / logディレクトリ内のログは、前に見たSyslog機能に分割され、その後にログサフィックスが続きます： auth.log、daemon.log、kern.log、またはdpkg.log。

auth.logファイルを調べた場合、Linuxシステムでの認証と承認に関連するログが表示されます。

同様に、cron.logファイルには、システムのcronサービスに関連する情報が表示されます。

ただし、上の図からわかるように、Linuxサーバーにはrsyslogとsystemd-journalの2つの異なるログシステムが共存しています。

Rsyslogとsystemd-journalの共存

歴史的に、デーモン Linux上のアプリケーションからログを収集する責任がありました。

多くの古いディストリビューションでは、このタスクは syslogdというデーモンに割り当てられていました。ただし、最近のディストリビューションでは、rsyslogデーモンに置き換えられました。。

systemdが最近のディストリビューションの既存のinitプロセスを置き換えたとき、ログを取得して保存する独自の方法が付属していました：systemd-journal。

現在、2つのシステムは共存しています ただし、それらの共存は、ログが過去にアーキテクチャ化されていた方法と下位互換性があると考えられていました。

rsyslogとsystemd-journalの主な違いは、rsyslogが / var / logで利用可能なログファイルにログを保持することです。ジャーナルされている間はされません 設定されていない限り、データを保持します。

ジャーナルログファイルの場所

前のセクションから理解したように、 systemd-journal ユーティリティは、システムのログアクティビティも追跡します。

サービスとして構成されている一部のアプリケーション（Apache HTTPサーバーなど）は、systemdジャーナルと直接通信する場合があります。

systemdジャーナルはログを一元的に保存します/run / log / journal ディレクトリ。

ログファイルはバイナリファイルとして保存されます systemdによるため、通常のcat以下のコマンドを使用してファイルを検査することはできません。

代わりに、「 journalctl」を使用します systemd-journalによって作成されたログファイルを検査するための「」コマンド。

$ journalctl

journalctlで使用できるさまざまなオプションがありますが、ほとんどの場合、「-r」および「-u」オプションを使用する必要があります。

最新のジャーナルエントリを表示するには、「 journalctl」を使用します」と「-r 」オプション。

$ journalctl -r

特定のサービスに関連するログを表示する場合、「-u」オプションを使用して、サービスの名前を指定します。

$ journalctl -u <service>

たとえば、SSHサービスに関連するログを表示するには、次のコマンドを実行します

$ journalctl -u ssh

構成ファイルを読み取る方法を確認したので、ロギングユーティリティを簡単に構成する方法を見てみましょう。

Linuxロギング構成

前のセクションからおそらく理解しているように、Linuxログは2つの重要なコンポーネントに基づいています：rsyslogとsystemd-journal。

これらのユーティリティにはそれぞれ独自の構成ファイルがあり、次の章でそれらを構成する方法を説明します。

システムジャーナル構成

systemdジャーナルの構成ファイルは、 / etc / systemdにあります。ディレクトリ。

$ sudo vi /etc/systemd/journald.conf

「journald.conf」という名前のファイル」は、ジャーナルデーモンを構成するために使用されます最近の配布について。

ジャーナル構成で最も重要なオプションの1つは、「ストレージ」です。」パラメータ。

以前と同様に、ジャーナルファイルはシステムに保持されず、次回の再起動時に失われます。

ジャーナルログを永続化するには、このパラメータを「永続的」に変更し、systemdジャーナルデーモンを再起動してください。

ジャーナルデーモンを再起動するには、「restart」オプションを指定して「systemctl」コマンドを使用し、サービスの名前を指定します。

$ sudo systemctl restart systemd-journald

結果として、ジャーナルログはrsyslogログファイルの隣の/ var / log/journalディレクトリに保存されます。

$ ls -l /var/log/journal

systemd-journalの構成に興味がある場合は、FreeDesktopが提供するドキュメントを必ずお読みください。

Rsyslog構成

一方、rsyslogサービスは、 /etc/rsyslog.confを介して構成できます。構成ファイル。

$ sudo vi /etc/rsyslog.conf

前に指定したように、rsyslogは本質的にSyslogコレクターですが、理解する必要がある主な概念は、Rsyslogがモジュールで動作することです。

そのモジュラーアーキテクチャは、ログをファイル、シェル、データベース、またはソケットに転送するネイティブな方法などのプラグインを提供します。

rsyslogを使用する場合、注意が必要な2つの主要なセクションがあります。モジュール およびルール 。

Rsyslog モジュール

デフォルトでは、システムで2つのモジュールが有効になっています： imuxsock （syslogソケットでリッスン）および imjournal （基本的にジャーナルログをrsyslogに転送します。）

注：imklog（カーネルログの収集を担当）もアクティブ化される可能性があります。

Rsyslogルール

ルール rsyslogのセクションはおそらく最も重要なセクションです。

rsyslogでは、systemdを使用した古いディストリビューションでも同じ原則を見つけることができますが、ルールセクションでは、機能と優先度に応じて、ファイルシステムに保存するログを定義します。

例として、次のrsyslog構成ファイルを見てみましょう。

最初の列は、適用されるルールを説明しています。ドットの左側で、施設を定義します。右側には重大度があります。

ワイルドカード記号「*」は、すべての重大度で機能していることを意味します。

結果として、ログ設定を順番に微調整したい場合、たとえば、特定の重大度のみに関心がある場合、これは変更するファイルです。

Linuxログ監視ユーティリティ

前のセクションでは、ロギングユーティリティを簡単に構成する方法を見てきましたが、Linuxログを簡単に読み取るためにどのユーティリティを使用できますか？

Linuxログを読み取って監視する最も簡単な方法は、followに「-f」オプションを指定してtailコマンドを使用することです。

$ tail -f <file>

たとえば、auth.logファイルに書き込まれたログを読み取るには、次のコマンドを実行します。

$ tail -f /var/log/auth.log

Linuxログを読み取るもう1つの優れた方法は、Linuxデスクトップ環境を実行している場合にグラフィカルアプリケーションを使用することです。

「ログ」アプリケーションは、さまざまなログファイル（rsyslogまたはjournald）に保存される可能性のあるアプリケーションログとシステムログを一覧表示するために設計されたグラフィカルアプリケーションです。

Linuxロギングユーティリティ

Linuxシステムでロギングを構成する方法を説明したので、メッセージをログに記録する場合に使用できるいくつかのユーティリティを見てみましょう。

ロガーの使用

ロガー ユーティリティは、おそらく使用するのに最も簡単なログクライアントの1つです。

ロガーは、ログメッセージをシステムログに送信するために使用され、次の構文を使用して実行できます。

$ logger <options> <message>

たとえば、認証機能からrsyslogユーティリティに緊急メッセージを送信する場合は、次のコマンドを実行します。

$ logger -p auth.emerg "Somebody tried to connect to the system"

これで、/ var / log / auth.logファイルを調べると、rsyslogサーバーに記録したばかりのメッセージを見つけることができます。

$ tail -n 10 /var/log/auth.log | grep --color connect

ロガーは、たとえばBashスクリプトで使用する場合に非常に便利です。

しかし、systemd-journalを使用してファイルをログに記録したい場合はどうなりますか？

systemd-catの使用

systemdジャーナルにメッセージを送信するには、「systemd-cat」コマンドを使用して、実行するコマンドを指定する必要があります。

$ systemd-cat <command> <arguments>

「ls-l」コマンドの出力をジャーナルに送信する場合は、次のコマンドを記述します

$ systemd-cat ls -l

echoコマンドをsystemd-catユーティリティにパイプすることで、「プレーンテキスト」ログをジャーナルに送信することもできます。

$ echo "This is a message to journald" | systemd-cat

壁の使用

wallコマンドはロギングユーティリティに直接関係していませんが、Linuxシステム管理には非常に役立ちます。

wallコマンドは、ログインしているすべてのユーザーにメッセージを送信するために使用されます。

$ wall -n <message>

たとえば、ログインしているすべてのユーザーにメッセージを書き込んで、次のサーバーの再起動について通知する場合は、次のコマンドを実行します。

$ wall -n "Server reboot in five minutes, close all important applications"

結論

このチュートリアルでは、Linuxロギングについて詳しく学びました。：アーキテクチャの仕組み さまざまなロギングコンポーネント（つまり、 rsyslog およびジャーナル ）相互作用します。

Syslogプロトコルについて詳しく学びましたシステム上の特定のイベントをログに記録するためにコレクターを構成する方法。

Linuxロギングは幅広いトピックであり、このテーマについて探求するトピックは他にもたくさんあります。

複数のマシンでログを監視するために集中ログシステムを構築できることをご存知ですか？

一元化されたロギングに興味がある場合は、ガイドを必ずお読みください！

また、Linuxシステム管理に情熱を注いでいる場合は、WebサイトにLinuxシステム専用の完全なセクションがありますので、ぜひチェックしてください！