RHEL 実践 #4 モニタリング: Cockpit、PCP

インフラ Linux RHEL Red Hat
読了 11分

Web サーバ、データベース、コンテナワークロードを順に載せたら、次はその上で何が起きているかを覗く番です。CPU がどこで跳ねるのか、メモリがどのプロセスに縛られているのか、ディスクがいつ飽和したのかが見えなければ、障害が起きたときに手を付ける場所が見つかりません。この記事では RHEL のモニタリングを 2 つの軸で整理します。ブラウザでサーバを管理する Web コンソール Cockpit と、パフォーマンスメトリクスを収集・記録する Performance Co-Pilot (PCP) です。

2 つのツールは役割が違います。Cockpit は今この瞬間の状態を一目で見てサービスに手を入れる管理コンソールで、PCP はメトリクスを地道に積んでおいて過去を辿る記録装置です。RHEL ではこの 2 つが噛み合って動くので、Cockpit の画面の中で PCP が集めたパフォーマンスグラフをそのまま見られます。まずは Cockpit から載せます。

Cockpit: ブラウザでサーバを管理する Web コンソール #

Cockpit は Red Hat が RHEL に標準で載せている Web ベースの管理コンソールです。ターミナルなしでブラウザだけで、サービスの開始・停止、ストレージ確認、ログ閲覧、ネットワーク設定、さらには Web ターミナルまで 1 画面で処理できます。SSH に慣れていない同僚とサーバを一緒に運用するときや、複数台を 1 か所にまとめて見たいときに特に役立ちます。

インストールとサービス登録 #

最小インストールの RHEL には Cockpit が入っていないことがあるので、dnf でインストールします。

# インストール
sudo dnf install -y cockpit

# 起動時に自動開始 + 即時開始 (一度に)
sudo systemctl enable --now cockpit.socket

# 状態確認
systemctl status cockpit.socket

ここで登録する unit が cockpit.service ではなく cockpit.socket である点が重要です。Cockpit は socket activation 方式で動き、普段はソケットだけが待機し、誰かが 9090 ポートに接続した瞬間にサービスが目を覚まします。接続がないときはメモリをほとんど使わないので、管理コンソールを常時立ち上げておく負担が少なくて済みます。

firewalld で 9090 ポートを開ける #

Cockpit は 9090 ポートを使います。RHEL 実践 #1 で扱ったファイアウォールの流れそのままに、サービス単位で永続的に開放します。firewalld には cockpit サービス定義がすでに入っているので、ポート番号を直接書かなくて済みます。

# cockpit サービスを永続許可
sudo firewall-cmd --add-service=cockpit --permanent

# 反映
sudo firewall-cmd --reload

# 確認
sudo firewall-cmd --list-services

--permanent で永続ルールを作ってから --reload でランタイムに反映する 2 段階は、RHEL ファイアウォール作業の基本の流れです。どちらかを抜かすと再起動後に 9090 がまた塞がります。

ブラウザで接続 #

これで別の PC のブラウザから https://サーバアドレス:9090 に接続します。http ではなく https である点に注意します。Cockpit は最初に自己署名証明書を使うのでブラウザが警告を出しますが、内部網では例外として進めて構いません。外部に公開する場合は正式な証明書に差し替えるか、reverse proxy の後ろに置くほうが安全です。

ログイン画面ではサーバの一般ユーザアカウントで入ります。ログイン後の画面で権限が必要な作業をするときは、上部の Administrative access を有効にすると sudo 権限に切り替わります。

Cockpit で何をするか #

ログインすると、左側のメニューで次を扱えます。

  • 概要 (Overview)。CPU・メモリ・ディスク使用率をリアルタイムグラフで見せます。ハードウェア情報と稼働時間 (uptime) もここで確認します。
  • サービス (Services)。systemd unit の一覧です。クリック 1 回でサービスを開始・停止・再起動し、enable の有無をトグルします。RHEL 実践 #1 でコマンドで扱った systemctl を画面で代わりにこなすわけです。
  • ログ (Logs)。journald ログを優先度・時間・unit で絞って見ます。ターミナルの journalctl を可視化した画面です。
  • ストレージ (Storage)。ファイルシステム使用量、マウント状態、LVM ボリュームを確認し、ディスク入出力の推移を見ます。
  • ターミナル (Terminal)。ブラウザの中ですぐにシェルを立ち上げます。画面で処理されない作業はここでコマンドで仕上げます。

アドオンで機能拡張 #

Cockpit はパッケージを足して機能を広げられます。前の記事で扱ったコンテナと仮想化を画面で管理するには、次をインストールします。

# Podman コンテナを Cockpit で管理
sudo dnf install -y cockpit-podman

# 仮想マシン (KVM) を Cockpit で管理
sudo dnf install -y cockpit-machines

cockpit-podman をインストールすると、RHEL 実践 #3 で載せた Podman コンテナを Cockpit 画面で見て、イメージを取得したりコンテナを開始・停止したりできます。cockpit-machines は同じ方式で KVM 仮想マシンを扱います。アドオンはインストールした途端に左メニューに項目として現れるので、別途の登録作業は要りません。ただしアドオンを入れるほど Cockpit が扱える範囲が広がるので、外部に公開するコンソールなら実際に使うアドオンだけを選んでインストールするのが攻撃面を減らす道です。

複数台の RHEL を運用しているなら、1 台の Cockpit から別のサーバを引き込んで一緒に管理することもできます。左上のホスト選択で別のサーバを SSH で登録すると、そのサーバにも Cockpit が立っている場合は画面を切り替えながら複数台を 1 つのコンソールで行き来できます。

PCP: パフォーマンスを記録する Performance Co-Pilot #

Cockpit が今を見せるなら、PCP は過去を辿らせてくれます。Performance Co-Pilot はシステムのあちこちのメトリクスを一定間隔で収集し、ディスクにアーカイブとして積んでおくパフォーマンスモニタリングフレームワークです。深夜 3 時に CPU が跳ねたという報告を翌朝に受け取ったとき、PCP アーカイブがあればその時刻に戻って何があったかを確認できます。

インストールとサービス登録 #

# インストール
sudo dnf install -y pcp

# メトリクス収集デーモンとロギングデーモンを一緒に開始
sudo systemctl enable --now pmcd
sudo systemctl enable --now pmlogger

# 状態確認
systemctl status pmcd pmlogger

PCP は 2 つの中核サービスに分かれます。pmcd (Performance Metrics Collector Daemon) はメトリクスを集める収集デーモンで、pmlogger はそうやって集めたメトリクスを定期的にディスクに記録するロギングデーモンです。リアルタイム照会だけなら pmcd だけで足りますが、過去を辿るには pmlogger まで点けてアーカイブを残す必要があります。

リアルタイムメトリクス照会 #

PCP はコマンドでメトリクスをすぐに取り出して見られます。よく使う 3 つを整理します。

# vmstat スタイルのシステム要約を定期的に出力
pmstat

# 指定したメトリクスを表形式で出力 (2 秒間隔、5 回)
pmrep -t 2 -s 5 kernel.all.load mem.util.free

# 単一メトリクスの値だけ簡単に確認
pmval -t 1 -s 3 kernel.all.cpu.user

pmstat はシステム全般を vmstat のように 1 行に要約し、素早く見渡すときに使います。pmrep は欲しいメトリクスを選んで表に取り出すツールで、CPU・メモリ・ディスクを 1 画面に並べて見たいときに役立ちます。pmval はメトリクス 1 つの値だけを追うので、特定の指標を絞って覗くのに適しています。使えるメトリクス名は pminfo コマンドで全リストを確認できます。

過去データのアーカイブ #

pmlogger が残すアーカイブは /var/log/pcp/pmlogger の下にホスト名別のディレクトリで積まれます。1 日単位のファイルで保管され、同じ照会コマンドに -a オプションでアーカイブを指定すると、その時点のデータを読み直してきます。

# アーカイブディレクトリ確認
ls /var/log/pcp/pmlogger/$(hostname)/

# 昨日のアーカイブから特定の時間帯の負荷を再照会
pmrep -a /var/log/pcp/pmlogger/$(hostname)/20260505 \
      -S @03:00 -T @04:00 kernel.all.load

-S は開始時刻、-T は終了時刻を意味します。こうするとリアルタイムではなく、記録された過去の区間をそのまま再生するように覗けます。アーカイブがディスクを圧迫しすぎるなら、PCP に付属する整理タスクが古いファイルを自動で圧縮し、保管期間を過ぎたものを削除してくれるので、保管ポリシーだけ設定に合わせておけば済みます。デフォルトでも数日分は無難に積まれますが、長期トレンドを見る必要があるサーバなら保管期間を延ばし、その分だけディスクの余裕を確保しておきます。

複数台を運用しているなら、1 台を中央収集サーバに置いて別のサーバの pmlogger がそちらへメトリクスを送るように束ねることもできます。ただし最初から中央化に手を付けるより、まず各サーバでローカルアーカイブを残す基本構成で始め、運用に慣れてから拡張するほうが安全です。

Cockpit と連携してパフォーマンスグラフを見る #

PCP の真価は Cockpit と連携するときに現れます。2 つのツールをつなぐパッケージをインストールすると、Cockpit 画面の中で PCP が集めたメトリクスをグラフで見られます。

# Cockpit と PCP をつなぐパッケージ
sudo dnf install -y cockpit-pcp

インストールした後 Cockpit に再接続すると、概要画面のグラフが単なるリアルタイム表示を超えて、過去の区間へ時間を遡りながら CPU・メモリ・ディスク・ネットワークの推移を見せます。コマンドでアーカイブを直接読む代わりに、画面で時間バーを引いて欲しい時点を指せるので、障害時刻を視覚的に素早く絞るときに便利です。

基本モニタリングコマンドは今も手に馴染ませておきます #

Cockpit と PCP を揃えても、ターミナルの基本コマンドは今も最速の診断ツールです。SSH で入ったばかりのサーバで何かがおかしいとき、追加インストールなしですぐ使えるからです。top は CPU・メモリを多く使うプロセスをリアルタイムの順位で見せ、ss -tlnp はどのポートがどのプロセスに開いているかを確認し、journalctl -u サービス名 -f は特定のサービスのログをリアルタイムで追います。そして sar は PCP を入れる前に最も軽く過去データを見るツールで、sysstat パッケージが収集しておいた CPU・メモリ・ディスク統計を時間帯別に振り返らせてくれます。

これらのコマンドをいつ取り出して使うかを整理するとこうなります。障害報告を受けて入ったばかりの直後には、top で負荷の主犯を、ss でポート状態を、journalctl で直前のログを 1 次的に見渡します。その場で原因が見えず過去を辿る必要があるときに PCP アーカイブや sar へ移り、複数の指標を 1 画面で視覚的に比較したいときに Cockpit へ上がる流れが自然です。ツールが多いからといって一度に全部点けるのではなく、軽いコマンドから重いコンソールへ段階を踏んで絞っていく順序が診断を速くします。

運用ポイント #

  • Cockpit は socket activation。cockpit.socket を enable すると接続があるときだけサービスが目を覚ますので、普段の負担が少ないです。
  • 9090 は https。ブラウザから https://サーバ:9090 で接続し、外部公開時には正式な証明書か reverse proxy を置きます。
  • PCP は pmcd と pmlogger の両方。リアルタイムだけ見るなら pmcd で足りますが、過去を辿るには pmlogger まで点けてアーカイブを残します。
  • アーカイブは -a で再生。/var/log/pcp/pmlogger の下のアーカイブを照会コマンドの -a オプションで指定すると、過去の時点をそのまま覗けます。
  • 連携は cockpit-pcp。このパッケージを入れると Cockpit 画面で PCP グラフを時間バーで遡って見ながら、障害時刻を素早く絞れます。
  • 基本コマンドは常に優先。top・ss・journalctl・sar は追加インストールなしで即使う 1 次診断ツールです。

まとめ #

この記事で押さえたことを整理します。Cockpit でブラウザからサービス・ストレージ・ログ・ターミナルを 1 画面で扱い、アドオンでコンテナと仮想マシンまで引き込みました。PCP ではメトリクスをリアルタイムで照会し、pmlogger アーカイブで過去を辿り、cockpit-pcp で 2 つをつないで画面でパフォーマンスグラフを時系列に見ました。最後に top・ss・journalctl・sar といった基本コマンドが今も最速の 1 次診断手段である点を確認しました。今を見るツールと過去を記録するツールを一緒に揃えると、障害が起きたときに手を付ける場所をようやく見つけられます。

モニタリングは一度設定して忘れる作業ではなく、普段から正常な状態がどのような姿かを目に馴染ませておくことに近いです。負荷が普段どの線を行き来するかを知っておいてこそ、その線を外れたときにようやく異常に気付けるからです。PCP アーカイブを数日分積んでおき Cockpit グラフをたまに覗く習慣が、いざ障害が来たときに最も頼れる基準線になります。

次回: Ansible で RHEL 自動化 #

ここまで Web・DB・コンテナ・モニタリングを 1 台ずつ手で載せながら、RHEL 運用の 1 サイクルを身につけました。ところがサーバが 1 台ではなく 10 台、100 台に増えると、同じ作業を手で繰り返すのはすぐに限界にぶつかります。

#5 Ansible で RHEL 自動化: RHCE トラックへつなぐ では、ここまで手でやったインストール・サービス登録・ファイアウォール・SELinux 作業を Ansible プレイブックに移し、複数台の RHEL を一度に一貫して構成する方法を整理します。あわせてこの流れが Red Hat の RHCE 資格とどうつながるかも押さえます。

X