【サーバー管理入門 第9回】サーバーの悲鳴を聞け。「ログ管理」とjournalctl完全攻略
こんにちは!「リナックス先生」です。
前回は、MariaDBの構築とセキュリティ設定を行いました。
これでWebサーバーとDBサーバーが連携して動くようになりましたが、もし突然「接続できません」というエラーが出たら、コウ君ならどうする?
えっと……とりあえず再起動します!
それでもダメなら、画面に出ているエラーメッセージをGoogleで検索しますかね……?
「とりあえず再起動」は、原因究明のための証拠を消してしまう最悪の手よ!
エラーの原因は必ずサーバーの中に記録されているわ。
それが「ログ(Log)」よ。
今回は、サーバーが発する微かな悲鳴を聞き逃さないための、ログ管理と分析スキルを叩き込むわ!
第9回となる今回は、サーバー管理者の最も重要なスキルの一つ、「ログ管理とトラブルシューティング」について解説します。/var/log を眺めるだけの初心者から卒業し、journalctl を駆使して過去の事象をタイムトラベルするように調査できるプロの技術を習得しましょう。
本講座のカリキュラム
- サーバー管理入門:RHEL系OSの選定理由とローカル仮想環境の構築
- 初期設定とセキュリティの要:SSH鍵認証、禁止設定、ユーザー管理の鉄則
- パッケージ管理の裏側:dnf/rpmの仕組みとリポジトリの依存関係解決
- ネットワーク設定の極意:nmcli、IPアドレス設計、DNSリゾルバの設定
- ストレージ管理とファイルシステム:LVMの概念、ディスク拡張、fstabの罠
- プロセスとサービス管理:systemd (systemctl) の仕組みとUnit定義ファイルの作成
- Webサーバー構築(Nginx):ハイパフォーマンスWebサーバーの導入と設定最適化
- データベース構築(MariaDB):インストール、初期セキュリティ、バックアップの基礎
- 【今回】ログ管理とトラブルシュート:rsyslog、journalctl、ログローテートの設計
- 自動化の第一歩:Cronによる定期実行と管理用シェルスクリプトの作成
- バックアップと障害復旧:tar/rsyncによるデータ保全とリカバリ手順
- 監視と運用設計:サーバーのリソース監視、死活監視、そしてプロの運用論
1. ログの保存場所と主要ファイル
Linuxにおけるログファイルは、基本的に /var/log/ ディレクトリの下に集約されています。
まずは、ここにある主要なファイルとその役割を覚えましょう。
| ファイル名 | 役割 | 監視の重要度 |
|---|---|---|
| messages | システム全体のメインログ。 カーネル、デーモン、エラー情報など何でも記録される。 |
★★★★★ (最重要) |
| secure | 認証・セキュリティ関連のログ。 SSHのログイン成功/失敗、sudoの使用履歴など。 |
★★★★★ (不正アクセス監視) |
| cron | 定期実行タスク (Cron) の実行履歴。 | ★★★☆☆ |
| maillog | メールサーバー (Postfixなど) の送受信ログ。 | ★★★★☆ |
| dmesg | OS起動時のハードウェア認識ログ。 デバイスの認識不良などを調べる時に見る。 |
★★★☆☆ |
| nginx/ mariadb/ |
各アプリケーションごとの専用ログディレクトリ。 WebアクセスログやDBエラーログはここ。 |
★★★★☆ |
これらのファイルはテキスト形式なので、cat, less, tail などのコマンドで閲覧できます。
リアルタイム監視の基本:tail -f
サーバー管理者が最もよく使うコマンドの一つが tail -f です。
ファイルの末尾を表示し続け、新しいログが追記されるとリアルタイムで画面に流れます。
# 別のターミナルでSSH接続などを試しながら実行すると動きが見えます [root@server01 ~]# tail -f /var/log/secure
2. rsyslog と journald の二重構造
RHEL 7以降のLinux(AlmaLinux 9含む)では、ログ管理の仕組みが少し複雑になっています。
以下の2つのシステムが並行して動いていることを理解しましょう。
- systemd-journald: systemdの一部。メモリ上にバイナリ形式で高速にログを収集する。OS起動直後からのログも捕捉できる。
- rsyslog: 従来のsyslogデーモン。journaldからログを受け取り、テキストファイル(/var/log/messagesなど)に書き出す。
つまり、/var/log/messages を見るのは「rsyslogが書き出した結果」を見ていることになります。
しかし、最近のトレンドでは「journalctl コマンドを使って journald のデータを直接見る」ほうが多機能で便利です。
3. 現代の標準ツール「journalctl」完全攻略
journalctl は、ログを見るための最強のコマンドです。
grepでテキスト検索をするよりも遥かに効率的に、必要な情報を抽出できます。
基本:すべてのログを見る
[root@server01 ~]# journalctl
less形式で表示されます。スペースキーで進み、q で終了します。
応用1:リアルタイム監視 (-f)
tail -f と同じ挙動ですが、こちらはカラー表示されて見やすいです。
[root@server01 ~]# journalctl -f
応用2:特定のサービスだけ見る (-u)
「Nginxのログだけ見たい」「sshdのログだけ見たい」という時に、他のノイズを排除できます。
[root@server01 ~]# journalctl -u nginx [root@server01 ~]# journalctl -u sshd
応用3:時間を指定して見る (–since)
これが最強の機能です。「今日の朝9時から10時の間のログが見たい」といった指定が可能です。
# 今日の0時以降を表示 [root@server01 ~]# journalctl --since today # 1時間前から表示 [root@server01 ~]# journalctl --since "1 hour ago" # 具体的な日時を指定 [root@server01 ~]# journalctl --since "2024-01-20 09:00:00" --until "2024-01-20 10:00:00"
応用4:エラーだけを表示する (-p)
膨大なログの中から、緊急度の高いエラー(Error, Critical, Alertなど)だけを抽出します。
# Priority(優先度)が err 以上のものを表示 [root@server01 ~]# journalctl -p err
💡 プロのトラブルシューティング手順
1. まず journalctl -xe や journalctl -p err で致命的なエラーがないか探す。
2. エラーが見つかったら、その前後の時刻を --since で指定して、何が起きていたか詳細な文脈を確認する。
3. 特定のサービスが怪しければ -u [サービス名] で絞り込む。
4. ディスクを守る番人「ログローテート (logrotate)」
ログは放っておくと無限に増え続け、最終的にディスク容量を食いつぶしてサーバーを停止させます。
これを防ぐために、「古いログを圧縮して保存し、一定期間過ぎたら削除する」仕組みが logrotate です。
設定ファイルの場所
全体設定は /etc/logrotate.conf にありますが、通常は各アプリごとの設定ファイルが /etc/logrotate.d/ ディレクトリに置かれています。
設定例を見てみよう (nginx)
[root@server01 ~]# cat /etc/logrotate.d/nginx
/var/log/nginx/*.log {
create 0640 nginx root
daily
rotate 10
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
/bin/kill -USR1 `cat /run/nginx.pid 2>/dev/null` 2>/dev/null || true
endscript
}
主要な設定項目の意味:
- daily / weekly / monthly: ローテーションする頻度。
- rotate 10: 過去何世代分を残すか(この場合、当日分+過去10日分)。
- compress: 古いログを gzip 形式で圧縮して容量を節約する。
- missingok: ログファイルが無くてもエラーにしない。
- postrotate … endscript: ローテート直後に実行するコマンド。
※ Nginxなどの場合、ログファイルをリネーム(退避)しただけでは、古いファイルに書き込み続けてしまいます。「ログファイルが変わったよ」とプロセスに教える再読み込みシグナルを送る処理がここに書かれています。
手動テスト (デバッグ)
設定を変更した時、本当に正しく動くかテストするには -d (debug) オプションを使います。
[root@server01 ~]# logrotate -d /etc/logrotate.d/nginx
実際には実行せず、「何をしようとしたか」を表示してくれます。
5. 実践:SSHログインの痕跡を追う
では、実際にログを見てみましょう。
誰かがSSHでログインしようとして失敗した、あるいは成功した記録は /var/log/secure (または journalctl) に残ります。
ログイン成功のログ
[root@server01 ~]# grep "Accepted" /var/log/secure Jan 20 10:00:05 server01 sshd[1234]: Accepted publickey for admin_user from 192.168.1.10 ...
「いつ」「誰が」「どこから(IP)」「どの認証方式で」ログインしたかが明確にわかります。
ログイン失敗のログ(攻撃の予兆)
[root@server01 ~]# grep "Failed" /var/log/secure Jan 20 10:05:22 server01 sshd[5678]: Failed password for root from 203.0.113.5 ...
もし外部公開しているサーバーで、見知らぬIPアドレスから大量の Failed password が記録されていたら、それはブルートフォース攻撃(総当たり攻撃)を受けている証拠です。
すぐさまファイアウォールでそのIPをブロックするなどの対処が必要です。
次回予告:めんどくさい作業は自動化しよう
今回は、サーバーの健康状態とセキュリティを監視するための「ログ管理」について学びました。
エラーが出たときに慌てず騒がず journalctl -xe を打てるようになれば、あなたも立派な管理者です。
さて、バックアップやログ監視など、毎日決まった時間に同じコマンドを打つのは面倒ですよね?
次回は、指定した時間にコマンドを自動実行してくれる執事機能「Cron(クーロン)」と、シェルスクリプトを使った自動化について解説します。
「寝ている間にバックアップを取る」システムを構築しましょう。お楽しみに!
ログを見ていると、世界中から自分のサーバーに対して攻撃が来ているのが見えて、最初は怖くなるかもしれないわ。
でも、それがインターネットの現実。
VirtualBoxの中だけでなく、実際のVPSでログを見ると、よりリアルな「戦場」の空気を肌で感じられるわよ。
セキュリティの勉強やログ監視の実践には、自分だけの城(VPS)を持つのが一番です。
攻撃ログを分析して対策を練るのも、エンジニアとしてのスキルアップに繋がります。
初心者にも使いやすく、セキュリティ機能も充実している推奨VPSを以下に紹介します。
▼スクリプトの実験場に最適!推奨VPS


コメント