OCI Monitoringのカスタム・メトリックでディスク使用率を監視する（その2：Prometheus Exporter 編）

2026年10月16日

はじめに

前回記事（OCI Monitoringのカスタム・メトリックでディスク使用率を監視する）では、 Python スクリプトと Instance Principal を使って、ディスク使用率をカスタム・メトリックとして OCI Monitoring に送信する方法が紹介されました。

今回は同じようにファイルシステムの使用量などを OCI Monitoring で扱う、別のパターンを紹介します。スクリプトを自作する代わりに、 Prometheus 形式でメトリックを公開する Exporter と、 OCI Management Agent の Prometheus Data Source を組み合わせます。

Linux の OS メトリックを取得する代表的な Exporter である node_exporter を使用し、 OCI Monitoring のカスタム・メトリックとして取り込んでみます。

今回の構成

今回の構成は以下です。

それぞれの役割は次のとおりです。

コンポーネント	役割
node_exporter	OS のメトリックを Prometheus 形式で HTTP 公開
Management Agent（Prometheus Data Source）	Exporter のエンドポイントを定期的にスクレイプし、 Monitoring へ送信
OCI Monitoring	カスタム・メトリックとして保存・検索・可視化

Prometheus Exporter と Management Agent は同一 VM 上に配置でき、 Management Agent から Exporter のエンドポイントへアクセスできる構成であれば利用できます。

本記事では次の条件で進めています。

OS：Oracle Linux 9
Exporter：node_exporter（同一 VM 上、 localhost:9100）
Metric Namespace：custom_os_metrics（任意の名前）

手順 1: node_exporter の導入と動作確認

まず、データの発生元である node_exporter を用意します。

Management Agent を設定する前に Exporter 単体で動作を確認しておくと、後の切り分けが楽になります。

インストール

Oracle Linux では dnf コマンドで導入できます。（EPEL を有効にして node-exporter をインストールします）

sudo dnf install oracle-epel-release-el9
sudo dnf config-manager --enable ol9_developer_EPEL
sudo dnf install node-exporter

sudo dnf install oracle-epel-release-el9

sudo dnf config-manager --enable ol9_developer_EPEL

sudo dnf install node-exporter

起動

動作確認では単純に実行ファイルを起動します。（前回記事と同様に /mnt/blockvolume1 を取得するために、デフォルトで取得されるマウントポイントに mnt を追加して起動します。）

sudo /usr/bin/node_exporter --collector.filesystem.mount-points-include="^/(|boot|var/oled|mnt)($|/)"

1 2	sudo /usr/bin/node_exporter --collector.filesystem.mount-points-include="^/(\|boot\|var/oled\|mnt)($\|/)"

起動すると、デフォルトでは HTTP の 9100 ポートでメトリックを公開します。

動作確認が取れれば node_exporter.service のサービスを用いて自動起動するようにしますが、本記事では動作確認・値取得までを目的としているため直接起動しています。

補足: サービス起動する場合のオプション指定方法

systemd のサービスで起動する場合は以下のオプションをサービスファイルに追記してください。

NODE_EXPORTER_ARGS="--collector.filesystem.mount-points-include=^/(|boot|var/oled|mnt)($|/)"

1 2	NODE_EXPORTER_ARGS="--collector.filesystem.mount-points-include=^/(\|boot\|var/oled\|mnt)($\|/)"

接続確認

curl http://localhost:9100/metrics

1 2	curl http://localhost:9100/metrics

正常に動作していれば、 Prometheus 形式のメトリックが大量に表示されます。

# HELP node_cpu_guest_seconds_total Seconds the CPUs spent in guests (VMs) for each mode.
# TYPE node_cpu_guest_seconds_total counter
node_cpu_guest_seconds_total{cpu="0",mode="nice"} 0
node_cpu_guest_seconds_total{cpu="0",mode="user"} 0
...
# HELP node_filesystem_avail_bytes Filesystem space available to non-root users in bytes.
# TYPE node_filesystem_avail_bytes gauge
node_filesystem_avail_bytes{...} ...

# HELP node_cpu_guest_seconds_total Seconds the CPUs spent in guests (VMs) for each mode.

# TYPE node_cpu_guest_seconds_total counter

node_cpu_guest_seconds_total{cpu="0",mode="nice"} 0

node_cpu_guest_seconds_total{cpu="0",mode="user"} 0

...

# HELP node_filesystem_avail_bytes Filesystem space available to non-root users in bytes.

# TYPE node_filesystem_avail_bytes gauge

node_filesystem_avail_bytes{...} ...

ここで重要なのは、 Exporter 単体で /metrics にアクセスできることを確認すること です。

手順 2: Management Agent の有効化

次に、 Compute インスタンス上で Management Agent を有効化します。

OCI の現在のプラットフォーム・イメージでは Oracle Cloud Agent がデフォルトでインストールされており、 Compute インスタンスの Oracle Cloud Agent タブから Management Agent プラグインを有効化できます。

変更が反映されるまで最大 10 分程度かかります。ステータスが 実行中になれば有効化完了です。

Management Agent のバージョン

Prometheus Data Source を利用するためには、 Management Agent のバージョン要件があります。

Oracle のドキュメントでは、 Prometheus Data Source の前提条件として Management Agent version 231231.0001 以上 が必要であると記載されています。

Data Source を設定する前に、 Management Agent のバージョンも確認しておくとよいでしょう。 Management Agent のバージョン確認は、以下の方法で確認できます。

OCI コンソールの「監視および管理」＞「管理エージェント」＞「エージェント」の一覧で確認する。
/var/log/oracle-cloud-agent/plugins/oci-managementagent/oci-managementagent.log に出力されている agent.version を確認する。

日本語のドキュメント（機械翻訳）では「管理エージェント・バージョン231231.0001以上を使用してデプロイされました。」と少しわかりづらい表現となっていますので、あえて英語版のドキュメントへのリンクを提示しています。

手順 3: 動的グループと IAM ポリシー

Management Agent が OCI Monitoring にメトリックを送信するためには、 IAM ポリシーが必要です。 Management Agent を動的グループに所属させ、その動的グループに対象のカスタム・メトリック・ネームスペースへの use metrics 権限を与えます。

前回記事では、 Compute インスタンスを対象とする動的グループと、 use metrics in tenancy のポリシーを設定していました。

今回は Management Agent のリソースを対象とする動的グループを作成し、ポリシーも Namespace で絞り込んだ設定をしています。

動的グループ

ALL { resource.type='managementagent' resource.compartment.id='&lt;AGENT_COMPARTMENT_OCID&gt;'}

1 2	ALL { resource.type='managementagent' resource.compartment.id='<AGENT_COMPARTMENT_OCID>'}

Management Agent のリソースを指定し、コンパートメントを限定しています。

IAM ポリシー

続いて、その動的グループに Monitoring のメトリック利用権限を付与します。

ALLOW dynamic-group Management-Agent-Dynamic-Group to use metrics in compartment &lt;METRIC_COMPARTMENT_NAME&gt; where target.metrics.namespace = 'custom_os_metrics'

1 2	ALLOW dynamic-group Management-Agent-Dynamic-Group to use metrics in compartment <METRIC_COMPARTMENT_NAME> where target.metrics.namespace = 'custom_os_metrics'

ここで重要なのは、 Data Source に設定する Metric Namespace と IAM ポリシーの target.metrics.namespace を一致させること です。

手順 4: Prometheus Data Source の追加

OCI コンソールで「監視および管理」＞「管理エージェント」＞「エージェント」＞「対象エージェントの詳細」を開き、 Data Source を追加します。

設定例は以下です。

項目	設定例
Data Source Type	`Prometheusエミッタ`
Name	任意
URL	`http://localhost:9100/metrics`
Metric Namespace	`custom_os_metrics`
Metric Compartment	メトリックの送信先コンパートメント
`allowMetrics`	`node_filesystem_avail_bytes,node_filesystem_size_bytes`
`scheduleMins`	`1`

必須項目は URL・Namespace・Compartment の 3 つです。 URL には Exporter がメトリックを公開している URL を指定します。今回は同一 VM 上なので localhost です。

なお、この URL は HTTP のみ がサポートされています。 https:// ではなくhttp:// で指定してください。

Metric Namespace には、 IAM ポリシーで指定したネームスペースを指定します。

`allowMetrics` で取り込むメトリックを絞る

Prometheus Exporter は非常に多くのメトリックを公開します。

最初からすべてを OCI Monitoring に送るのではなく、必要なものだけを allowMetrics で指定します。

node_filesystem_avail_bytes,node_filesystem_size_bytes

1 2	node_filesystem_avail_bytes,node_filesystem_size_bytes

前回記事と同じくファイルシステムの使用状況を取得するため、空き容量（node_filesystem_avail_bytes）と全体サイズ（node_filesystem_size_bytes）を指定しています。

まず少数のメトリックで、「Exporter → Management Agent → Monitoring」というデータ連携そのものが正常であることを確認し、その後に必要なメトリックを増やしていく方が問題を切り分けやすくなります。

増やす際の候補としては、 node_memory_MemAvailable_bytes や node_load1 などがあります。

`scheduleMins` でスクレイプ間隔を指定する

scheduleMins は Exporter をスクレイプする間隔（分）です。

ドキュメント（Prometheusメトリックを収集するための管理エージェントの設定）では、未指定の場合は 5 分、最小値は 1 分とされています。

間隔を短くするほどデータ収集処理の頻度が増えますので、監視要件に合わせて設定します。

スクリプト方式では cron で間隔を制御していましたが、 Exporter 方式ではこの scheduleMins で指定します。

`resourceGroup` で分類する（任意）

resourceGroup を設定すると、送信するメトリックに Resource Group を付与できます。

resourceGroup = production

1 2	resourceGroup = production

複数の環境や用途のメトリックを同一 Namespace へ集約する場合に、 Monitoring 側で Resource Group を指定して検索できます。

手順 5: OCI Monitoring で確認する

Data Source の設定が完了したら、 OCI Monitoring の「メトリック・エクスプローラ」で確認します。

Namespace に custom_os_metrics を選択する
node_filesystem_avail_bytes や node_filesystem_size_bytes が表示されることを確認する

前回記事のスクリプトは使用率（%）を算出して送信していましたが、 Exporter が公開する値はバイト数なので注意が必要です。

Alarm との連携

前回記事では、カスタム・メトリックの値として使用率（％）を送信しているためそのままの値でアラーム設定していましたが、 Exporter を用いる場合はトリガー・ルールの MQL で使用率を計算しアラーム設定します。

※画像では右側が切れてしまうため改行を挿入して整形しています。

(node_filesystem_avail_bytes[1m]{mountpoint = "/mnt/blockvolume1"}.mean() / node_filesystem_size_bytes[1m]{mountpoint = "/mnt/blockvolume1"}.mean()) &lt;= 0.2

1 2	(node_filesystem_avail_bytes[1m]{mountpoint = "/mnt/blockvolume1"}.mean() / node_filesystem_size_bytes[1m]{mountpoint = "/mnt/blockvolume1"}.mean()) <= 0.2

前回記事・標準メトリックとの違い

前回と今回の方式は、 OCI Monitoring の標準メトリックを置き換えるものではなく、標準メトリックでは不足する情報を補う用途です。

前回記事のスクリプト方式とは、次のように使い分けられます。

観点	標準メトリック	スクリプト方式（前回記事）	Exporter 方式（今回）
取得できる値	OCI が定義した範囲	スクリプトで取得できる任意の値	Exporter が公開する値
必要なもの	OCI の標準監視機能	Python + OCI SDK + cron	Exporter + Management Agent
認証・権限	不要	Instance Principal（動的グループ）	Management Agent の動的グループ
実行間隔の制御	OCI 側	cron（自前）	`scheduleMins`（最短 1 分）
値の加工	なし	スクリプト内で自由（例：使用率算出）	基本は Exporter の値そのまま
ディメンション	OCI が定義	自分で定義（mountPoint など）	Device や mountpoint など
Namespace	OCI サービスが定義	利用者が指定	利用者が指定
メトリックの選択	OCI が定義	スクリプトで指定	`allowMetrics` で限定可能
向いている場面	追加設定無しで監視したい場合	少数の独自値を送りたい	既存の Exporter を流用したい、項目が多い
スクリプトの作成	不要	必要（Python で取得・送信処理を作成し、cron で実行）	不要（Exporter の導入と Data Source の設定のみ）

どちらの方式も、 OCI Monitoring では「カスタム・メトリック」として扱われます。

うまくいかない場合のチェックポイント

問題が発生した場合は、次の順番で確認すると切り分けやすくなります。

Exporter
Management Agent
IAM ポリシー
OCI Monitoring

症状	確認すること
`curl` で `/metrics` が取得できない	Management Agent の設定以前の問題です。 Exporter の起動状態とポートを確認します
Management Agent が URL に到達できない	同一 VM なら `localhost` を指定します。別ホストの Exporter の場合は、ネットワーク的に到達できる必要があります
ログに `HTTP 404 NotAuthorized` が出る	IAM ポリシーを確認します。 Namespace（`target.metrics.namespace`）と Compartment が Data Source の設定と一致しているか
Exporter では取れるが Monitoring にない	`allowMetrics` で除外していないか確認します（例：指定外の `node_memory_MemAvailable_bytes` は対象外です）
Data Source の設定が反映されない	URL が `https://` になっていないか確認します。 HTTP のみ対応です

上記で原因が分からない場合は、 Management Agent のログで次の項目を確認します。

Data Source の設定
Exporter への接続
スクレイプ処理
Monitoring へのメトリック送信
IAM ポリシーによる認可

補足: 他の Exporter を使う

前回記事では、 OS 上の特定プロセスの稼働状態を数値として送信する例にも触れられていました。

Exporter 方式でも、用途に応じた Exporter を使うことで、同じ Data Source の仕組みで取り込めます。

プロセスの稼働状態などを取得するには、非公式ではありますがprocess-exporterを利用することで、/proc の情報を送信することが可能となります。

まとめ

前回記事のスクリプト方式に対して、 Prometheus Exporter と Management Agent の Prometheus Data Source を利用することで、スクリプトを書かずに OS レベルの情報を OCI Monitoring のカスタム・メトリックとして取り込むことができます。

特に重要なのは以下のポイントです。

Exporter の /metrics エンドポイントを HTTP の URL で指定する
IAM ポリシーの Namespace/Compartment と Data Source の設定を一致させる
allowMetrics で必要なメトリックだけに絞り、 scheduleMins は要件に応じて設定する
問題が発生した場合は Exporter → Management Agent → IAM → Monitoring の順番で切り分ける

まずは node_filesystem_avail_bytes と node_filesystem_size_bytes 程度の小さな構成から始めると、動作確認とトラブルシュートが容易です。

標準メトリックとスクリプト利用、 Prometheus Exporter 利用とそれぞれ取得できる値・手法が異なります。そのため、必要としているメトリックや既存構成などより、どのパターンを利用すれば良いのかを検討いただくのが良いかと思われます。

よかったらシェアしてね！

URLをコピーしました！

OCI Monitoringのカスタム・メトリックでディスク使用率を監視する