原因不明のサーバーダウンにより、深夜に上司から呼び出される悪夢
私がこの業界に入りたての頃、会社の基幹システムを動かしていたサーバーが大晦日の夜に突然ダウンしたことがありました。当時はただ慌ててSSHで接続し、topやdf -hを叩いて絶望するしかありませんでした。サーバーが完全に落ちてしまうと、いつから過負荷になっていたのかという過去のデータはもう手に入りません。メモリリークなのか、それとも未知のプロセスによるCPU占有だったのか。誰も知る由もありませんでした。
苦い経験から学んだ教訓は、「監視（Monitoring）ダッシュボードのないシステム運用は、ヘッドライトを点けずに夜道を運転するようなもの」だということです。壁に激突して初めて、異常が起きたことに気づくのでは遅すぎるのです。
なぜログの手動確認は「時間の罠」なのか？
多くのIT担当者は、トラブルが発生してから/var/log/messagesや<a href="https://itfromzero.com/ja/linux/centos-vi-ja-linux/centos-stream-9-%e3%81%ab%e3%81%8a%e3%81%91%e3%82%8b-rsyslog-%e3%81%a7%e3%81%ae%e9%9b%86%e4%b8%ad%e3%83%ad%e3%82%b0%e7%ae%a1%e7%90%86%ef%bc%9a%e3%83%ad%e3%82%b0%e3%82%92%e4%b8%80%e5%85%83%e5%8c%96.html">journalctl</a>を調べ始める習慣があります。この方法は間違いではありませんが、以下の理由から非常に非効率です：
- 予測可能性の欠如： メモリ使用率の推移が見えません。例えば、1 hourごとに1%ずつ着実に増加している場合、それはメモリリーク（memory leak）の兆候ですが、ログファイルから即座に判断するのは困難です。
- リソースの浪費： 5〜10GBもあるファイルから数百万行のログを
grepで検索するのは、もはや苦行です。 - 上層部への説得が困難： 上司は無機質なログの羅列を理解してくれません。サーバー増強の予算を承認してもらうには、直感的なグラフ（可視化）が必要です。
Grafana – Prometheus：DevOpsにおける最強の組み合わせ
以前はZabbixを使用していましたが、動作が重く、インターフェースも少し古臭く感じていました。DockerやCentOS Stream 9を扱うようになってからは、PrometheusとGrafanaのペアを優先的に採用しています。
Prometheusは強力な時系列データベース（Time Series Database）として機能し、Grafanaは「可視化の主役」として、無機質な数字を美しいダッシュボードへと変貌させます。実際、私はこの組み合わせを20台のLinuxサーバー群に導入し、障害原因の特定時間を30分からわずか2分に短縮しました。
CentOS Stream 9での実践的な構築手順
以下のロードマップで進めていきます：Node Exporterのインストール（データ収集） -> Prometheusのインストール（蓄積） -> Grafanaのインストール（可視化） -> セキュリティ設定。
ステップ1：Node ExporterとPrometheusのインストール
Node Exporterは、サーバー上で動作してCPU、メモリ、ディスクなどのメトリクスを送信する軽量なツールです。まずはシステムの安全性を確保するため、専用のユーザーを作成します：
# サービス実行用ユーザーの作成
sudo useradd --no-create-home --shell /bin/false node_exporter
# Node Exporter v1.7.0のダウンロードとインストール
wget https://github.com/prometheus/node_exporter/releases/download/v1.7.0/node_exporter-1.7.0.linux-amd64.tar.gz
tar -xvf node_exporter-1.7.0.linux-amd64.tar.gz
sudo mv node_exporter-1.7.0.linux-amd64/node_exporter /usr/local/bin/
Node Exporterを管理しやすくするために、サービスファイルを作成します：
sudo nano /etc/systemd/system/node_exporter.service
# [ファイル内容: User=node_exporter, ExecStart=/usr/local/bin/node_exporter]
sudo systemctl daemon-reload
sudo systemctl enable --now node_exporter
ステップ2：公式リポジトリからのGrafanaインストール
GrafanaはCentOS 9向けのRPMリポジトリを公式に提供しているため、後のdnf updateも非常に簡単です。まずリポジトリファイルを作成しましょう：
sudo nano /etc/yum.repos.d/grafana.repo
Grafana Labsの公式リポジトリ設定を追加した後、インストールコマンドを実行します：
sudo dnf install grafana -y
sudo systemctl enable --now grafana-server
ステップ3：FirewalldとSELinuxによるセキュリティ強化
これはジュニアエンジニアが忘れがちなステップで、ダッシュボードにアクセスできない原因の多くがこれです。CentOS Stream 9はデフォルトでほとんどの外部ポートをブロックしています。
Firewalldの設定： Grafana用の3000番ポートとPrometheus用の9090番ポートを開放します。
sudo firewall-cmd --permanent --add-port={3000,9090}/tcp
sudo firewall-cmd --reload
SELinux의 処理： 安易にSELinuxを無効化（disable）しないでください。Grafanaが別サーバーのデータベースに接続する必要がある場合は、特定の権限のみを許可します：
sudo setsebool -P httpd_can_network_connect 1
注意：ファイル権限を正しく設定したにもかかわらずログに「Permission Denied」と表示される場合、99%の確率でSELinuxがデータディレクトリへのアクセスをブロックしています。
ステップ4：5分で完了する接続とダッシュボード作成
http://サーバーIP:3000にアクセスし、初期アカウントadmin/adminでログインします。パスワード変更後、以下の手順を行います：
- Data SourcesメニューでPrometheusを選択します。
- URLに
http://localhost:9090を入力し、Save & Testをクリックします。 - ヒント： ゼロからグラフを作る必要はありません。「Import」メニューでID 1860を入力してください。これはコミュニティで広く信頼されている、非常に詳細な「Node Exporter Full」テンプレートです。
現場での運用ノウハウ
RHEL系OSで長年システム管理を行ってきた経験から、3つの重要なポイントを伝えます：
- SELinuxを絶対にオフにしない：
setenforce 0で解決するのではなく、audit2allowを使ってエラーの原因を特定しましょう。SELinuxを無効にするのは、サーバーの最後の鎧を脱ぎ捨てるのと同じです。 - 保存期間（Retention）の制御： Prometheusのデフォルトのデータ保持期間は15日です。サーバーのディスク容量が20GB程度しかない場合は、
--storage.tsdb.retention.time=7dというパラメータで7日間に短縮し、ディスクフルによるシステム停止を防ぎましょう。 - アラート通知を優先する： 美しいダッシュボードは眺めるためのものです。TelegramやSlackでアラートを設定しましょう。スマホに届く「5分間CPU使用率 > 90%」という通知は、どんなグラフよりも早くあなたを救ってくれます。
CentOS Stream 9でGrafanaをマスターすることは、業務を効率化するだけでなく、プロフェッショナルとしての評価を高めることにも繋がります。皆さんの構築が成功することを祈っています！
