Linuxサーバーを運用する上で、ログ管理は避けて通れない重要なスキルです。障害発生時の原因調査、セキュリティインシデントの検知、パフォーマンスの監視——これらすべての基盤となるのがログファイルの適切な管理と分析です。
しかし、「/var/logにファイルがたくさんあるけれど、どれを見ればいいかわからない」「journalctlの使い方がよくわからない」「ログが肥大化してディスクを圧迫している」といった悩みを抱えるIT担当者は少なくありません。
本記事では、Linuxのログ管理について基礎から実践まで体系的に解説します。/var/logディレクトリの構成、journalctlの活用法、ログローテーションの設定方法、さらにはトラブルシューティングに役立つログ分析テクニックまで、現場で必要な知識を網羅しています。Linuxの基本を学びたい方は、まずLinuxとは?の記事もあわせてご覧ください。
Linuxのログ管理が重要な理由
Linuxシステムは、あらゆる動作の記録をログとして残しています。ユーザーのログイン、サービスの起動と停止、エラーの発生、ネットワーク接続の状態など、システム上で起きたことはすべてログに記録されます。
ログ管理が重要な理由は大きく3つあります。
障害対応の迅速化
サーバーに障害が発生した際、最初に確認するのがログファイルです。エラーメッセージや警告を時系列で追うことで、問題の原因を特定し、復旧までの時間を短縮できます。ログがなければ、手探りでの調査を強いられ、対応が大幅に遅れます。
セキュリティ監視
不正アクセスの試行、権限昇格の失敗、不審なプロセスの起動など、セキュリティ上の脅威はログに痕跡を残します。定期的なログの監視と分析は、セキュリティインシデントの早期発見に欠かせません。ファイアウォールの設定と併せてログを監視することで、より堅牢なセキュリティ体制を構築できます。詳しくはLinuxファイアウォール設定入門もご覧ください。
システムの安定運用
ログを継続的に監視することで、問題が顕在化する前に予兆を捉えることが可能です。ディスク容量の逼迫、メモリ使用量の増加、特定サービスの異常終了など、ログに残る警告を見逃さないことがシステムの安定稼働につながります。
/var/logディレクトリの構成と主要ログファイル
Linuxでは、システムのログファイルは主に/var/logディレクトリ配下に集約されます。ディレクトリ構造の全体像についてはLinuxディレクトリ構造ガイドで詳しく解説しています。ここでは、/var/log内の主要なログファイルを確認しましょう。
システム全般のログ
以下のファイルは、システム全体の状態を把握するために最も頻繁に参照するログです。
# システム全般のログ(Debian/Ubuntu系)
/var/log/syslog
# システム全般のログ(RHEL/CentOS/Rocky Linux系)
/var/log/messages
# カーネルのログ
/var/log/kern.log
# 起動時のログ
/var/log/boot.log
/var/log/syslog(またはmessages)は、システム上のほぼすべてのサービスからのメッセージが記録される最も重要なログファイルです。障害調査の第一歩として確認すべきファイルです。
認証・セキュリティ関連のログ
# 認証ログ(Debian/Ubuntu系)
/var/log/auth.log
# 認証ログ(RHEL/CentOS/Rocky Linux系)
/var/log/secure
# ログイン失敗の記録(バイナリ形式、lastbコマンドで閲覧)
/var/log/btmp
# ログイン成功の記録(バイナリ形式、lastコマンドで閲覧)
/var/log/wtmp
# 現在ログイン中のユーザー(バイナリ形式、whoコマンドで閲覧)
/var/log/utmp
SSHでのリモートアクセスを許可しているサーバーでは、auth.log(secure)は必ず定期的に確認すべきファイルです。不正なログイン試行がないか、ブルートフォース攻撃を受けていないかをチェックできます。SSH接続の詳細についてはLinux SSH・リモート接続ガイドを参照してください。
アプリケーション固有のログ
# Apacheのログ
/var/log/apache2/access.log
/var/log/apache2/error.log
# Nginxのログ
/var/log/nginx/access.log
/var/log/nginx/error.log
# MySQLのログ
/var/log/mysql/error.log
# cronジョブの実行ログ
/var/log/cron
Webサーバーなどのアプリケーションは、専用のサブディレクトリにログを保存するのが一般的です。Nginxの設定方法についてはLinux Nginx構築ガイドで解説しています。
ログファイルの基本的な確認方法
ログファイルを確認する際は、用途に応じて適切なコマンドを使い分けます。
# ログファイルの末尾を確認(最新のエントリ)
tail -20 /var/log/syslog
# リアルタイムでログを監視
tail -f /var/log/syslog
# 複数のログファイルを同時に監視
tail -f /var/log/syslog /var/log/auth.log
# 特定の文字列を含む行を検索
grep "error" /var/log/syslog
# 特定の日時以降のログを抽出
grep "Mar 22" /var/log/syslog
# エラーレベルのメッセージのみ抽出
grep -i "error\|fail\|critical" /var/log/syslog
grepやtailなどのテキスト処理コマンドの詳しい使い方は、Linuxテキスト処理コマンド入門やLinuxコマンド一覧・実践ガイドでまとめています。
journalctlの基本と活用方法
近年のLinuxディストリビューション(Ubuntu 16.04以降、CentOS 7以降など)では、systemd-journaldがシステムログの管理を担っています。このjournaldが収集するログを閲覧・検索するためのコマンドがjournalctlです。
journalctlの基本的な使い方
# すべてのログを表示(古い順)
journalctl
# 最新のログから表示(ページャーで末尾から開始)
journalctl -e
# 最新の50行を表示
journalctl -n 50
# リアルタイムでログを追跡(tail -fと同様)
journalctl -f
# 逆順(新しい順)で表示
journalctl -r
journalctlの大きな利点は、従来のテキストベースのログファイルと異なり、構造化されたデータとして管理される点です。これにより、高度なフィルタリングや検索が容易に行えます。
時間による絞り込み
障害調査では、問題が発生した時間帯のログを絞り込む場面が頻繁にあります。journalctlでは直感的な時間指定が可能です。
# 今日のログのみ表示
journalctl --since today
# 特定の日時以降のログ
journalctl --since "2026-03-22 09:00:00"
# 特定の時間範囲のログ
journalctl --since "2026-03-22 09:00:00" --until "2026-03-22 12:00:00"
# 直近1時間のログ
journalctl --since "1 hour ago"
# 直近30分のログ
journalctl --since "30 minutes ago"
# 前回の起動以降のログ
journalctl -b
# 前回の起動時のログ
journalctl -b -1
ユニット(サービス)による絞り込み
systemdで管理されているサービスごとにログを確認できるのは、journalctlの最大の強みです。サービス管理の基本はLinux systemd・サービス管理ガイドで詳しく解説しています。
# 特定のサービスのログ
journalctl -u nginx.service
# 複数サービスのログを同時に表示
journalctl -u nginx.service -u php-fpm.service
# 特定サービスのリアルタイム監視
journalctl -u sshd.service -f
# 特定サービスの今日のログのみ
journalctl -u mysql.service --since today
優先度(ログレベル)による絞り込み
ログメッセージには優先度(priority)が設定されています。障害調査では、エラー以上の優先度のログに注目することで、効率的に問題を特定できます。
# エラー以上の優先度のログのみ表示
journalctl -p err
# 警告以上のログ
journalctl -p warning
# 重大なエラーのみ
journalctl -p crit
# 緊急レベルのログ
journalctl -p emerg
優先度の一覧は以下の通りです(数値が小さいほど深刻)。
- 0 emerg: システムが利用不可能
- 1 alert: 即座に対処が必要
- 2 crit: 致命的な状態
- 3 err: エラー
- 4 warning: 警告
- 5 notice: 注意すべき通常の状態
- 6 info: 情報メッセージ
- 7 debug: デバッグ情報
出力形式の変更
# JSON形式で出力(スクリプトでの解析に便利)
journalctl -o json-pretty
# 短縮形式(デフォルト)
journalctl -o short
# 詳細形式(全フィールド表示)
journalctl -o verbose
# カーネルメッセージのみ
journalctl -k
rsyslogの設定と活用
journalctlと並んで、rsyslogは多くのLinuxディストリビューションで採用されているログ管理デーモンです。rsyslogは受け取ったログメッセージを分類し、設定に基づいて適切なファイルに書き出します。
rsyslogの設定ファイル
# メインの設定ファイル
/etc/rsyslog.conf
# 追加の設定ファイル(ディレクトリ)
/etc/rsyslog.d/
rsyslog.confの基本的な設定形式は以下の通りです。
# 書式: ファシリティ.プライオリティ 出力先
# すべてのauthメッセージをauth.logに記録
auth,authpriv.* /var/log/auth.log
# すべてのメッセージ(auth以外)をsyslogに記録
*.*;auth,authpriv.none /var/log/syslog
# カーネルメッセージをkern.logに記録
kern.* /var/log/kern.log
# エラー以上のメッセージを別ファイルに記録
*.err /var/log/error.log
カスタムログルールの追加
特定のアプリケーションのログを個別のファイルに出力したい場合、rsyslogにカスタムルールを追加できます。
# /etc/rsyslog.d/50-myapp.conf として作成
# local0ファシリティのログを専用ファイルに記録
local0.* /var/log/myapp.log
# 設定を反映
sudo systemctl restart rsyslog
設定変更後はrsyslogを再起動する必要があります。プロセス管理の基本操作はLinuxプロセス管理の記事で解説しています。
ログローテーションの設定と最適化
ログファイルは放置すると際限なく肥大化し、ディスク容量を圧迫します。ログローテーションは、ログファイルを定期的にアーカイブ・圧縮・削除し、ディスク容量を管理する仕組みです。ディスク管理全般についてはLinuxディスク管理入門も参考にしてください。
logrotateの基本設定
ほとんどのLinuxディストリビューションにはlogrotateがプリインストールされています。設定ファイルは以下の場所にあります。
# メイン設定ファイル
/etc/logrotate.conf
# アプリケーションごとの設定ファイル
/etc/logrotate.d/
メイン設定ファイルの内容を確認してみましょう。
# /etc/logrotate.conf の例
# ローテーション周期:週次
weekly
# 保持する世代数:4週分
rotate 4
# ローテーション後に新しいログファイルを作成
create
# 圧縮を有効化
compress
# 個別設定ファイルの読み込み
include /etc/logrotate.d
アプリケーション固有のlogrotate設定
Nginxのログローテーション設定例を見てみましょう。
# /etc/logrotate.d/nginx
/var/log/nginx/*.log {
daily # 毎日ローテーション
missingok # ログファイルがなくてもエラーにしない
rotate 14 # 14世代保持(2週間分)
compress # 古いログをgzip圧縮
delaycompress # 直近のローテーションファイルは圧縮しない
notifempty # 空のログファイルはローテーションしない
create 0640 www-data adm # 新しいログファイルの権限
sharedscripts # スクリプトを一度だけ実行
postrotate # ローテーション後に実行するコマンド
if [ -f /var/run/nginx.pid ]; then
kill -USR1 `cat /var/run/nginx.pid`
fi
endscript
}
ファイル権限の設定(0640など)についてはLinuxファイルパーミッションガイドで詳しく解説しています。
カスタムアプリケーションのlogrotate設定
自社開発のアプリケーションなど、独自のログファイルにもlogrotateを適用できます。
# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
daily
rotate 30 # 30日分保持
compress
delaycompress
missingok
notifempty
create 0644 appuser appgroup
dateext # ファイル名に日付を付与
dateformat -%Y%m%d # 日付フォーマット指定
postrotate
systemctl reload myapp 2>/dev/null || true
endscript
}
logrotateの動作確認
# ドライラン(実際には実行しない)で設定を確認
sudo logrotate -d /etc/logrotate.d/nginx
# 手動で即座にローテーションを実行
sudo logrotate -f /etc/logrotate.d/nginx
# logrotate自体のログを確認
cat /var/lib/logrotate/status
journaldのディスク使用量管理
systemd-journaldのログ(ジャーナル)もディスク容量を消費します。特にサーバーで長期間運用していると、ジャーナルデータが数GBに膨れ上がることがあります。
ジャーナルの容量確認
# ジャーナルのディスク使用量を確認
journalctl --disk-usage
# 出力例:
# Archived and active journals take up 1.2G in the file system.
ジャーナルのクリーンアップ
# 指定した容量まで古いジャーナルを削除
sudo journalctl --vacuum-size=500M
# 指定した日数より古いジャーナルを削除
sudo journalctl --vacuum-time=30d
# 指定した数のジャーナルファイルだけ残す
sudo journalctl --vacuum-files=5
journaldの永続化設定
journaldの設定は/etc/systemd/journald.confで管理します。
# /etc/systemd/journald.conf
[Journal]
# ジャーナルの永続化(再起動後もログを保持)
Storage=persistent
# 最大ディスク使用量
SystemMaxUse=1G
# 空きディスク容量の下限
SystemKeepFree=2G
# 個々のジャーナルファイルの最大サイズ
SystemMaxFileSize=100M
# 保持する最大期間
MaxRetentionSec=1month
# 圧縮の有効化
Compress=yes
# 設定変更後にjournaldを再起動
sudo systemctl restart systemd-journald
実践的なログ分析テクニック
ログ管理の真価は、障害やセキュリティ問題の調査で適切にログを分析できることにあります。ここでは、実務で役立つログ分析テクニックを紹介します。
SSH不正アクセスの調査
# SSH認証失敗の回数をIPアドレスごとに集計
grep "Failed password" /var/log/auth.log | \
awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20
# 特定のIPアドレスからのアクセス試行を時系列で確認
grep "192.168.1.100" /var/log/auth.log | tail -50
# journalctlでSSHサービスの認証失敗を確認
journalctl -u sshd.service | grep "Failed password" | tail -20
Webサーバーのエラー分析
# HTTPステータスコード別のアクセス数を集計
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn
# 404エラーの多いURLを特定
awk '$9 == 404 {print $7}' /var/log/nginx/access.log | \
sort | uniq -c | sort -rn | head -20
# 500エラーが発生した時間帯を特定
awk '$9 == 500 {print $4}' /var/log/nginx/access.log | \
cut -d: -f1-2 | sort | uniq -c
ディスク容量逼迫時のログ調査
# 大きなログファイルの特定
sudo du -sh /var/log/* | sort -rh | head -10
# ログの増加速度を確認(5秒間隔で3回計測)
for i in 1 2 3; do
ls -l /var/log/syslog
sleep 5
done
# 特定のプロセスが大量のログを出力していないか確認
journalctl --since "1 hour ago" | awk '{print $5}' | \
sort | uniq -c | sort -rn | head -10
シェルスクリプトによるログ監視の自動化
cronと組み合わせて、ログ監視を自動化する例です。定期実行の設定方法はLinux cron・スケジュール実行ガイドを参照してください。
#!/bin/bash
# /usr/local/bin/log-alert.sh
# エラーログを監視し、閾値を超えたらアラートを送信
LOG_FILE="/var/log/syslog"
THRESHOLD=100
PERIOD="1 hour ago"
ALERT_EMAIL="admin@example.com"
# 直近1時間のエラー数をカウント
ERROR_COUNT=$(journalctl --since "$PERIOD" -p err --no-pager | wc -l)
if [ "$ERROR_COUNT" -gt "$THRESHOLD" ]; then
echo "警告: 直近1時間のエラー数が${THRESHOLD}件を超えました(${ERROR_COUNT}件)" | \
mail -s "[ALERT] ログエラー閾値超過" "$ALERT_EMAIL"
fi
シェルスクリプトの基本についてはLinuxシェルスクリプト入門で詳しく学べます。
ログ管理のベストプラクティス
最後に、Linux環境でのログ管理におけるベストプラクティスをまとめます。
ログの保持ポリシーを定める
業界や法規制の要件を考慮しつつ、ログの保持期間を明確に定義しましょう。一般的なガイドラインは以下の通りです。
- セキュリティログ(auth.log等): 最低90日、可能であれば1年
- アプリケーションログ: 30〜90日
- デバッグログ: 7〜14日
- アクセスログ: 用途に応じて30日〜1年
ログの一元管理を検討する
複数のサーバーを運用している場合、各サーバーのログを集中ログサーバーに転送する仕組みを構築すると、管理効率が大幅に向上します。rsyslogのリモート転送機能を使えば、比較的簡単に実現できます。
# 送信側の設定(/etc/rsyslog.d/50-remote.conf)
# TCP経由でログを転送
*.* @@logserver.example.com:514
# 受信側の設定(/etc/rsyslog.d/50-server.conf)
# TCP 514番ポートでログを受信
module(load="imtcp")
input(type="imtcp" port="514")
# ホストごとにログを分離して保存
template(name="RemoteLogs" type="string"
string="/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log")
*.* ?RemoteLogs
ネットワーク設定の基本はLinuxネットワークコマンドの記事もあわせて確認してください。
定期的な監視体制の構築
ログは記録するだけでなく、定期的に確認する運用体制を整えることが重要です。以下の項目を定期チェックリストに含めましょう。
- SSH認証の失敗ログの確認(毎日)
- ディスク使用量とログサイズの確認(毎日)
- エラーログの確認と対応(毎日)
- logrotateの正常動作確認(毎週)
- ジャーナルのディスク使用量確認(毎週)
- ログ保持ポリシーの見直し(四半期ごと)
まとめ
Linuxのログ管理は、サーバー運用の要となるスキルです。本記事で解説した内容を振り返りましょう。
- /var/logディレクトリの構成を理解し、主要なログファイルの役割を把握する
- journalctlを使いこなし、時間・サービス・優先度で効率的にログを絞り込む
- rsyslogでログの出力先をカスタマイズし、アプリケーション固有のログを管理する
- logrotateでログのローテーションを自動化し、ディスク容量の逼迫を防ぐ
- journaldのディスク使用量を適切に管理する
- 実践的なログ分析テクニックを身につけ、障害調査やセキュリティ監視に活かす
ログ管理のスキルは、LinuxトラブルシューティングやLinuxセキュリティ強化と密接に関連しています。これらの知識を組み合わせることで、より堅牢なLinuxサーバー運用を実現できるでしょう。
まだLinuxの基本コマンドに自信がない方は、Linuxコマンド一覧・実践ガイドから学習を始めることをおすすめします。
関連記事
AWS CloudFrontでサイト高速化|CDN設定からキャッシュ戦略まで実践解説
AWS CloudWatchで監視・アラート設定|運用担当者のための実践ガイド
AWS CodePipelineでCI/CD構築|コード変更から本番デプロイまでの自動化
AWS Cost Explorerでコスト可視化|ムダを見つけて月額費用を削減する実践術
AWS ECS/Fargateでコンテナ運用|Docker→本番デプロイの実践ガイド
AWS IAMのベストプラクティス|最小権限の原則を実務で実装する方法
AWS RDSの実務ガイド|データベース構築・バックアップ・パフォーマンスチューニング
AWS S3の実務活用ガイド|バケット設計・アクセス制御・コスト最適化の実践