目次
- Linuxのログ管理が重要な理由
- 障害対応の迅速化
- セキュリティ監視
- システムの安定運用
- /var/logディレクトリの構成と主要ログファイル
- システム全般のログ
- 認証・セキュリティ関連のログ
- アプリケーション固有のログ
- ログファイルの基本的な確認方法
- journalctlの基本と活用方法
- journalctlの基本的な使い方
- 時間による絞り込み
- ユニット(サービス)による絞り込み
- 優先度(ログレベル)による絞り込み
- 出力形式の変更
- rsyslogの設定と活用
- rsyslogの設定ファイル
- カスタムログルールの追加
- ログローテーションの設定と最適化
- logrotateの基本設定
- アプリケーション固有のlogrotate設定
- カスタムアプリケーションのlogrotate設定
- logrotateの動作確認
- journaldのディスク使用量管理
- ジャーナルの容量確認
- ジャーナルのクリーンアップ
- journaldの永続化設定
- 実践的なログ分析テクニック
- SSH不正アクセスの調査
- Webサーバーのエラー分析
- ディスク容量逼迫時のログ調査
- シェルスクリプトによるログ監視の自動化
- ログ管理のベストプラクティス
- ログの保持ポリシーを定める
- ログの一元管理を検討する
- 定期的な監視体制の構築
- まとめ
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コマンド一覧・実践ガイドから学習を始めることをおすすめします。
先行モニター企業 募集中|先着5社・2026年11月末まで 生成AIの利用費、「誰が・何のために・いくら」まで見えていますか?
株式会社カイダンと共同開発したAI利用ガバナンスSaaS「ManageAI」は、OpenAI・Azure OpenAI・Claude・AWS Bedrock・Google Vertex AIの費用と利用状況を、部署・利用者・プロジェクト別に可視化します。導入は読み取り専用キーの登録だけ。初期費用0円・月額5万円(税別)で先行モニター企業を募集しています。
ニュースリリースを読む関連記事
Related / 9 articles
Notes & Insights
- プログラミング
DDoS攻撃の仕組みと対策入門|レイヤー別の防御とCDN・クラウドの活用
DDoS攻撃をボリューム型・プロトコル型・アプリ層に分けて仕組みを解説し、自前サーバーで防げない理由、CloudflareやAWS Shieldの標準防御、オリジンIPの隠し方、レートリミットとBot対策、攻撃を受けたときの初動、費用が跳ね上がるDenial of Walletへの備えまでわかります。
- プログラミング
WAFとは?仕組み・導入パターン・誤検知対策|Webアプリを攻撃から守る実践ガイド
WAFがファイアウォールやIDSと何が違うのか、シグネチャとマネージドルールの仕組み、Cloudflare WAF・AWS WAF・ModSecurityの比較、フォーム送信がブロックされる誤検知の調査と例外設定、ログ監視、WAFが代替できないことまで実践的に解説します。
- プログラミング
セキュリティヘッダー入門|CSP・HSTS・X-Frame-Optionsの設定と効果を実践解説
CSP・HSTS・X-Frame-Options・X-Content-Type-Optionsなど主要セキュリティヘッダーが防ぐ攻撃と、CSPのReport-Onlyからの段階導入、nonce/hash、HSTS preloadの不可逆リスク、Nginx・Next.js・Astroでの設定例、確認方法を解説します。
- プログラミング
クラウドの通信費(Egress)入門|データ転送量課金の仕組みと転送コストを抑える設計
クラウドの「受信無料・送信有料」の原則、AZ間・リージョン間・インターネット向けの単価差、NATゲートウェイ処理料の罠、CDNで転送量を減らす方法、バックアップやログ転送の見落とし、請求書で転送料を特定する手順を解説。想定外の請求を防げます。
- プログラミング
秘密情報をGitに入れない仕組み|.gitignore・git-secrets・履歴から漏れた鍵の削除
APIキーや.envをGitにコミットしてしまう典型経路と、.gitignore・.env.exampleの運用、pre-commitでのgitleaks検知、GitHub secret scanningの活用、漏れた鍵の無効化と履歴書き換え(git filter-repo)の手順を解説。仕組みで再発を防げます。
- プログラミング
開発・ステージング・本番環境の分離設計|環境差分をなくす構成とアクセス制御
開発・ステージング・本番それぞれの目的と、構成をコードで揃える方法、環境別の設定注入、本番データを使わないテストデータ戦略、ステージングの保護(Basic認証・IP制限・noindex)、コストを抑える運用までを解説。環境差分による本番障害を防げます。
- プログラミング
ngrok・Cloudflare Tunnelでローカルを公開|Webhook開発とデモ環境の作り方
NAT内のローカル環境にStripeやLINEのWebhookを届けるトンネリングの仕組みを解説。ngrok・Cloudflare Tunnel・localtunnelの比較、固定ドメインと認証、リクエスト検査、公開時のセキュリティ、自宅サーバー公開への応用までわかります。
- プログラミング
ローカル開発環境のHTTPS化|mkcert・hostsファイル・自己署名証明書の正しい使い方
ローカル開発をHTTPS前提にすべき理由(Secure Cookie・Service Worker・OAuth)と、mkcertでローカルCAを作りhostsで独自ドメインを割り当ててVite・Next.js・Dockerで使う手順を解説。証明書警告を無視する癖の危険も理解できます。
- プログラミング
localhost・0.0.0.0・127.0.0.1の違い|ポートとUnixソケットを理解して「つながらない」を解決
localhost・127.0.0.1・0.0.0.0の意味の違い、Dockerで外から接続できない原因、host.docker.internal、ポート競合の調べ方、Unixソケットの利点と権限、1024未満ポートの制約を解説。「つながらない」を仕組みから解決できます。
先行モニター企業 募集中
生成AIのコストを「部署別」に、請求書より先に。
先着5社限定・2026年11月末まで。初期費用0円・月額5万円(税別)で、正式版と同等の機能に加え、開発者と伴走者による導入支援を追加費用なしで提供します。プロンプト原文は一切取得しません。
株式会社カイダン × Harmonic Society株式会社の共同事業|読み取り専用キーの登録だけで導入できます