Linuxサーバーを安定して運用するためには、ログと監視の仕組みを理解し適切に活用することが欠かせません。
ログが肥大化してディスクを圧迫したり、監視ツールの出力を正しく読み取れなかったりすると、トラブルの早期発見が難しくなります。
ここではログ・監視系で起こりやすいトラブルと、その解決の入口を整理します。
Linuxの基礎知識 🟡 ログ・監視系
📌 システムの健全性を保つためのログ活用と監視テクニック
└─【Linuxの基礎知識】ログ・監視系でよくあるトラブルと解決の入口
├─ 【Linuxの基礎知識】リソース監視ツールの使い方を徹底解説！
├─ 【Linuxの基礎知識】journalctlの具体的な使い方を初心者向けに解説
├─ 【Linuxの基礎知識】Linuxでログ肥大を防ぐlogrotateの基本と自作アプリ対応法
├─ 【Linuxの基礎知識】dmesgの読み方とハードウェアトラブル対応
├─ 【Linuxの基礎知識】vmstatとiostatでボトルネックを見抜く
├─ 【Linuxの基礎知識】sarコマンドでサーバー性能を長期監視する方法
├─ 【Linuxの基礎知識】top / htopの違いと使い分け｜リアルタイム監視の基本
└─ 【Linuxの基礎知識】rsyslogでログを転送する方法と設定例
トラブル例（ログ・監視系）
ログと監視はLinux運用に欠かせない要素ですが、仕組みやツールの使い方を誤解するとトラブルの発見や対応が遅れてしまいます。
ここでは、ログ・監視系で起こりやすいトラブルの全体像をまとめます。
ログ・監視系で実際に多くの管理者が直面するのは、ログの見方や監視コマンドの読み取りに関する問題です。
さらに、ログ肥大によるディスク圧迫や、長期的な性能変化の見落としも頻出します。
以下に、具体的なトラブル事例とその切り分けポイントを整理します。
| トラブル事象 | 原因の切り分け | 解決記事 |
|---|---|---|
| リソース監視ができない | ツール選定や基本操作を理解していない | リソース監視ツールの使い方を徹底解説！ |
| ログの見方が分からない | journalctlの基本操作を理解していない | journalctlの具体的な使い方を初心者向けに解説 |
| ログが肥大化して容量を圧迫 | logrotateの仕組みや設定を導入していない | Linuxでログ肥大を防ぐlogrotateの基本と自作アプリ対応法 |
| ハード異常を把握できない | dmesgの確認不足や読み方を誤っている | dmesgの読み方とハードウェアトラブル対応 |
| ボトルネックが特定できない | vmstatやiostatの指標を理解していない | vmstatとiostatでボトルネックを見抜く |
| 長期的な負荷推移が追えない | sarコマンドの利用や設定不足 | sarコマンドでサーバー性能を長期監視する方法 |
| リアルタイム監視ができない | top / htop の違いや操作を理解していない | top / htopの違いと使い分け｜リアルタイム監視の基本 |
| ログを他サーバーに転送できない | rsyslogの転送設定が未導入または誤設定 | rsyslogでログを転送する方法と設定例 |
リソース監視ツールの使い方を徹底解説！
Linuxシステムを安定して運用するには、CPUやメモリ、ディスクI/O、ネットワークといったリソースの状態を把握し続けることが欠かせません。
top や vmstat、iostat などの監視ツールを適切に使えば、負荷の兆候を早期に発見し、障害を未然に防ぐことができます。
ただし、表示される数値や指標を正しく読み解けなければ、問題の本質を見逃してしまうこともあります。
ここでは、代表的なモニタリングツールの特徴と見方、さらに実際のトラブルシューティングでどう活用できるのかを整理しています。
日常的な監視から緊急対応まで役立つ知識をまとめており、システムの安定稼働に直結する実践的な内容となっています。
リソース監視ができない場合の対策
リソース状況を把握できないと、CPUやメモリ不足が表面化してから対応せざるを得なくなります。
[原因の切り分け]
| 原因 | 確認方法 | 解決策 |
|---|---|---|
| 監視ツールを導入していない | rpm -qa | grep sysstat などで確認 | sysstat や top/htop/vmstat をインストール |
| 導入済みでも基本操作を理解していない | man コマンドや --help で使用方法を確認 | 主要コマンド（sar, iostat, mpstat など）を練習 |
| 監視対象の指標が未設定 | プロセスやリソースの測定ポイントを見直す | 監視設定ファイルにCPU・メモリ・I/Oなどの対象を追加 |
| ログ収集が無効 | sar -u を実行し統計が出力されるか確認 | sysstat サービスを有効化し systemctl enable/start で稼働させる |
| 権限不足で監視できない | 特定の監視コマンド実行時にエラーが出るか確認 | 必要に応じて sudo 権限で実行または権限調整 |
もっと詳しく
journalctlの具体的な使い方を初心者向けに解説
Linuxでサーバーを運用していると、必要なログが見つからず困る場面は避けられません。
systemd 環境では従来の /var/log/messages だけでは不十分で、そこで役立つのが journalctl です。
サービスの起動やエラー、システム全体の状態まで一括で参照でき、時系列や条件を指定して効率的に絞り込むことができます。
初心者にとっても扱いやすいコマンドでありながら、実務では障害調査や運用監視に欠かせない強力な機能を備えています。
ここでは journalctl の基本的な操作方法から、現場で活用できる実践的な使い方までを整理し、ログ管理を一段とわかりやすくするための知識をまとめています。
ログの見方が分からない場合の対策
[原因の切り分け]
| 原因 | 確認方法 | 解決策 |
|---|---|---|
| journalctl の基本操作を知らない | journalctl -xe で直近のログを確認 | 公式ドキュメントや man journalctl を確認し基本操作を習得 |
| 期間指定やフィルタリングを理解していない | --since, --until, -u オプションを試す | よく使う条件付きオプションを組み合わせて検索に慣れる |
| systemd と従来ログの違いを把握していない | /var/log/messages と併せて比較 | systemd 環境では journalctl、非 systemd 環境では rsyslog を使い分ける |
| 権限不足で読めない | 一般ユーザーで閲覧時にエラーになるか確認 | sudo journalctl を利用するか、必要に応じて権限を調整 |
| ログローテーション後に対象が見つからない | /var/log/ 配下のファイル数や更新日時を確認 | logrotate 設定を見直し、保存期間や世代数を適切に調整 |
もっと詳しく
👉 【Linuxの基礎知識】journalctlの具体的な使い方を初心者向けに解説
Linuxでログ肥大を防ぐlogrotateの基本と自作アプリ対応法
Linuxで稼働するシステムやアプリケーションでは、ログが増え続けることでディスクを圧迫したり、解析やバックアップに時間がかかるといった問題が起こります。
こうしたトラブルを未然に防ぐ仕組みが logrotate です。定期的にログを分割・圧縮・削除することで、必要な情報を残しながら容量を効率的に管理できます。
標準のシステムログだけでなく、自作アプリケーションのログにも対応させることが可能で、適切に設定すれば長期運用でも安定した環境を維持できます。
ここでは logrotate の基本動作や設定の考え方に加え、実際に自作アプリへ適用する際の実践的なポイントを整理しています。
ログが肥大化してディスクを圧迫する場合の対策
[原因の切り分け]
| 原因 | 確認方法 | 解決策 |
|---|---|---|
| logrotate 未導入 | rpm -qa | grep logrotate で確認 | パッケージマネージャで logrotate をインストール |
| 対象ファイル設定が不足 | /etc/logrotate.d/ の有無を確認 | 必要なログファイルを対象に設定を追加 |
| 古いログが圧縮・削除されていない | /var/log/ の容量推移を確認 | logrotate の設定で世代数や圧縮オプションを調整 |
| サービス再起動で設定が反映されていない | systemctl status logrotate で稼働状況を確認 | 定期的に logrotate を cron で実行させる |
| アプリ独自ログが対象外 | アプリケーション設定で出力先を確認 | 独自ログも logrotate の設定に追加 |
もっと詳しく
👉 【Linuxの基礎知識】Linuxでログ肥大を防ぐlogrotateの基本と自作アプリ対応法
dmesgの読み方とハードウェアトラブル対応
Linuxサーバーを運用していると、ディスクが認識されない、USB機器が動作しない、ネットワークカードが応答しないといったハードウェアトラブルに直面することがあります。
そんなとき一次診断の手掛かりとなるのが dmesg です。
カーネルが出力するメッセージを確認でき、起動時に認識されたハードウェアやドライバの読み込み状況、エラー内容までを把握できます。
システム管理者にとっては欠かせないツールですが、出力は膨大で英語メッセージも多く、初心者にとって読み解くのは容易ではありません。
ここでは dmesg の役割や基本的な読み方を整理し、実際のハードウェア障害を切り分けるためにどのように活用できるのかをまとめています。
ハード異常を把握できない場合の対策
[原因の切り分け]
| 原因 | 確認方法 | 解決策 |
|---|---|---|
| dmesg を確認していない | dmesg | grep -i error で異常を調査 | 定期的に dmesg を確認し自動通知の仕組みを導入 |
| メッセージを誤解している | ログの内容をドキュメントと照合 | 公式ドキュメントやエラーメッセージ集を参照して正しく解釈 |
| 警告を見逃している | 定期的に dmesg を確認する仕組みを構築 | 監視ツールと連携し、警告発生時に通知されるよう設定 |
| ハード障害とソフト不具合の切り分けができていない | smartctl -a /dev/sdX でディスク状態を確認 | SMART情報やメモリテストツールを利用して物理故障を判定 |
| ログが上書きされて過去の異常を確認できない | journalctl --since "1 day ago" で履歴確認 | ログを外部ストレージや集中管理サーバーに保存 |
もっと詳しく
👉 【Linuxの基礎知識】dmesgの読み方とハードウェアトラブル対応
vmstatとiostatでボトルネックを見抜く
Linuxサーバーが遅いと感じたとき、原因がCPUの処理能力にあるのか、メモリ不足なのか、あるいはディスクI/Oの遅延なのかを見極める必要があります。
vmstatはCPUやメモリ、プロセスの状態を数値化して表示し、iostatはCPUとストレージI/Oの状況を把握するのに適しています。
両者を組み合わせることで、システム全体の負荷分布を効率よく把握でき、どこにボトルネックがあるのかを明確にできます。
サーバーの性能低下を的確に切り分けるために欠かせないツール群として、基本的な見方から実際の利用シーンまで整理しています。
ボトルネックが特定できない場合の対策
[原因の切り分け]
| 原因 | 確認方法 | 解決策 |
|---|---|---|
| vmstat の指標を理解していない | vmstat 1 で CPU / wait を確認 | CPU待機時間・メモリスワップの意味を整理し、他コマンドと併用 |
| iostat の分析が不足 | iostat -x で I/O を分析 | 高い %util や await を基準にディスク負荷を判断し、必要に応じて分散 |
| 長期観測データ不足 | 継続的に出力を保存して傾向を分析 | sar や sysstat を導入し履歴を収集、閾値を設定して監視 |
| ネットワーク要因を除外していない | iftop や sar -n DEV でトラフィックを確認 | 帯域使用率を可視化し、他リソースと合わせて総合的に判断 |
| 複数リソースの相関を見落としている | vmstat, iostat, sar を並行確認 | CPU・メモリ・I/O・ネットワークを突き合わせ、隠れたボトルネックを特定 |
もっと詳しく
👉 【Linuxの基礎知識】vmstatとiostatでボトルネックを見抜く
sarコマンドでサーバー性能を長期監視する方法
サーバーの動作が重いとき、その原因を突き止めるには一瞬の状態を見るだけでは不十分で、時間の経過による変化を追うことが欠かせません。
sar コマンドは sysstat パッケージに含まれるツールで、CPUやメモリ、ディスクI/O、ネットワークなどのリソース利用状況を定期的に収集し、履歴として蓄積します。
これにより、過去にさかのぼって障害の発生タイミングやリソース逼迫の兆候を確認することができ、突発的な不具合の原因調査や将来の性能劣化を予測する手がかりとなります。
長期的な視点でサーバーを監視し、安定稼働を維持するために重要なコマンドのひとつです。
長期的な負荷推移が追えない場合の対策
[原因の切り分け]
| 原因 | 確認方法 | 解決策 |
|---|---|---|
| sar 未導入 | rpm -qa | grep sysstat で確認 | パッケージマネージャで sysstat をインストール |
| ログ収集が有効化されていない | systemctl status sysstat で確認 | systemctl enable --now sysstat で常駐化 |
| 監視項目の不足 | sar -u, -r, -n などのオプション確認 | 必要な指標を指定して定期収集、グラフ化ツールと連携 |
| 保存期間が短すぎる | cat /etc/sysconfig/sysstat でHISTORY設定を確認 | 保存日数を延長し、長期傾向を分析できるよう調整 |
| データ容量不足で古いログが消える | df -h で /var の空き容量を確認 | ディスク容量を確保し、ログ用パーティションを分離 |
もっと詳しく
top / htopの違いと使い分け｜リアルタイム監視の基本
Linuxで稼働中のシステムを監視する際に定番となるのが top と htop です。
どちらもCPUやメモリ、プロセスの状況をリアルタイムに確認できるツールですが、特徴は大きく異なります。
top は標準で多くのディストリビューションに搭載されており、軽量かつ確実に動作する一方、表示はシンプルで操作は限定的です。
対して htop は色分けされた直感的な表示やカーソル操作に対応しており、プロセスの階層構造を視覚的に確認できる点が強みです。
両者を比較して理解しておくことで、状況に応じて適切に使い分けることができ、日常の監視から障害対応まで効率的に進められるようになります。
リアルタイム監視が難しい場合の対策
[原因の切り分け]
| 原因 | 確認方法 | 解決策 |
|---|---|---|
| top の基本操作を知らない | top 実行時のキー操作を確認 | 主要ショートカット(q, k, h, 数字キー)を習得し、必要に応じてカスタマイズ |
| htop を導入していない | yum install htop で導入状況を確認 | htop を導入し、色分け表示やプロセスツリーを活用 |
| I/O 負荷の把握不足 | iotop を使って I/O の状況を確認 | iotop を導入し、ディスク負荷の原因プロセスを特定 |
| ネットワーク負荷の可視化不足 | iftop や nload で通信量を確認 | iftop を導入し、リアルタイムで通信状況を監視 |
| 複数サーバーの統合監視ができない | 監視基盤の有無を確認 | Prometheus や Zabbix を導入し、集中管理・可視化を実現 |
もっと詳しく
👉 【Linuxの基礎知識】top / htopの違いと使い分け｜リアルタイム監視の基本
rsyslogでログを転送する方法と設定例
複数台のサーバーを管理していると、ログを一か所に集約できれば効率的だと感じることは多いでしょう。
障害発生時に各サーバーへログインして確認するのは手間がかかり、情報が分散していると原因の切り分けも遅れてしまいます。
そこで役立つのが rsyslog のログ転送機能です。Linuxに標準搭載されている rsyslog は、ログの収集や分類、保存に加えて、ネットワーク経由で別のサーバーへ送信する仕組みを備えています。
専用のログサーバーを構築すれば、アプリケーションやデータベースなど各サーバーのログを集中管理でき、監視や障害対応を大幅に効率化できます。
セキュリティ監査や長期的な保管、さらには分析基盤との連携にも活用できる実践的な仕組みです。
ログを他サーバーに転送できない場合の対策
[原因の切り分け]
| 原因 | 確認方法 | 解決策 |
|---|---|---|
| rsyslog 転送設定未導入 | /etc/rsyslog.conf を確認 | 転送先の設定行（*.* @@host:514 など）を追記して rsyslog を再起動 |
| 転送ルールの誤り | /etc/rsyslog.d/ を確認 | 対象ファイル・優先度の指定を修正し、正しくルールを記述 |
| 受信サーバー設定不足 | 受信側でポート開放や保存状況を確認 | 受信側の rsyslog.conf でモジュール imudp/imtcp を有効化し、firewalld でポートを開放 |
| ネットワーク疎通不良 | ping 宛先IP / nc -z 宛先IP 514 | 通信経路を確認し、ファイアウォールやルータでポートを開放 |
| SELinux による制約 | getenforce で SELinux 状態を確認 | 必要に応じて semanage port で rsyslog のポートを許可 |
もっと詳しく
よくあるエラーと解決法
ログや監視の仕組みを扱う際には、コマンド未導入や権限不足、設定ミスといったトラブルが頻発します。
ここでは、実務で遭遇しやすいエラーとその解決方法を一覧化しました。
| エラー内容 | 原因 | 解決法 |
|---|---|---|
| journalctl: command not found | systemd-journald 関連パッケージが未導入 | sudo dnf install systemd |
| Failed to get journal fields | journal ファイルの破損／権限不足 | sudo journalctl --verify sudo chmod 640 /var/log/journal/* |
| logrotate not working | /etc/logrotate.conf の書式誤り、cron が無効 | sudo logrotate -d /etc/logrotate.conf systemctl status crond |
| dmesg: read kernel buffer failed | カーネルメッセージの読み取り権限不足 | sudo dmesg journalctl -k |
| vmstat: command not found | sysstat パッケージが未導入 | sudo dnf install sysstat |
| sar: Cannot open /var/log/sa/saXX | sysstat サービスが無効、ログ収集が開始されていない | sudo systemctl enable --now sysstat sar -u |
| rsyslog: cannot open socket | 転送先サーバー未稼働／firewall でブロック | telnet target-host 514 sudo firewall-cmd --list-all |
次のおすすめ記事
実践環境を整える
ここまで学んだ知識を実際に試すには、Linuxを動かす環境が必要です。手軽に始めるならVPSを利用するのがおすすめです。
→ VPS徹底比較！ConoHa・さくら・Xserverの選び方
VPSを利用してLinux環境を準備したら、実際の設定は下記の記事が参考になります。
→ VPSに開発環境を自動構築する方法｜Apache＋Tomcat＋PostgreSQL
