モニタリングの概要

Oracle Cloud Infrastructure Monitoringサービスを使用すると、メトリックおよびアラーム機能を使用してクラウド・リソースを能動的および受動的にモニターできます。モニタリングの動作について学習します。

この図は、モニタリング・サービスで使用されるメトリックおよびアラームを示しています。

ヒント

サービスの概要ビデオを視聴してください。

モニタリングの動作

モニタリング・サービスは、メトリックを使用してリソースおよびアラームをモニターし、これらのメトリックがアラームで指定されたトリガーを満たしたときに通知を行います。

メトリックは、モニタリング・サービスに対し、Rawデータ・ポイントまたはタイムスタンプ/値ペアとして、ディメンションおよびメタデータとともに発行されます。メトリックは様々なソースから取得されます:

Oracle Cloud Infrastructureリソースによって自動的にポストされたリソース・メトリック。たとえば、コンピュート・サービスは、oci_computeagentネームスペースを通じてモニタリング対応のコンピュート・インスタンスのメトリックをポストします。このようなメトリックの1つは、CpuUtilizationです。サポートされているサービスおよびデフォルトのメトリック・チャートの表示を参照してください。
モニタリングAPIを使用して公開されたカスタム・メトリック。
コネクタ・ハブを使用して新規または既存のメトリックに送信されるデータ(コネクタのターゲット・サービスとしてモニタリングを使用)。

コネクタ・ハブを使用して、メトリックをモニタリング・システムから転送できます。詳細は、モニタリング・ソースとのコネクタの作成を参照してください。

モニタリング・サービスにポストされるメトリック・データは、メトリック・データの使用を有効にするOracle Cloud Infrastructureの機能によってのみ、表示または使用されます。

メトリックを問い合せると、モニタリング・サービスは指定されたパラメータに従って集計データを返します。範囲(過去24時間など)、統計および間隔を指定できます。コンソールには、選択したリソースのメトリックごとに1つのモニタリング・チャートが表示されます。各チャート内の集計データは、選択した統計および間隔を反映します。APIリクエストは、必要に応じてディメンションでフィルタリングし、レゾリューションを指定できます。APIレスポンスには、メトリック名とともにソースのコンパートメントとメトリック・ネームスペースが含まれます。集計されたデータをビジュアライゼーションまたはグラフ化ライブラリにフィードできます。

メトリックおよびアラーム・データには、コンソール、CLIおよびAPIからアクセスできます。保持期間については、ストレージの制限を参照してください。

モニタリング・サービスのアラーム機能は、通知のトピックやストリーミングのストリームなど、構成された宛先にアラーム・メッセージを公開します。

メトリック機能の概要

メトリック機能では、クラウド・リソースのヘルス、容量およびパフォーマンスに関するメトリック・データをリレーします。

メトリックとは、リソースのヘルス、容量またはパフォーマンスに関連する測定です。リソース、サービスおよびアプリケーションが、モニタリング・サービスにメトリックを発行します。共通メトリックには、次に関連したデータが反映されます:

可用性およびレイテンシ
アプリケーションの稼働時間と停止時間
完了済トランザクション
失敗した操作と成功した操作
売上数量やエンゲージメント数量などのキー・パフォーマンス・インジケータ(KPI)

このデータのモニタリングを問い合せることで、顧客にコミットしているサービス・レベルを達成するために、システムとプロセスがどの程度機能しているかを理解できます。たとえば、コンピュート・インスタンスのCPU使用率およびディスク読取りをモニタリングできます。このデータを使用して、負荷の増加を処理するためにより多くのインスタンスをプロビジョニングするタイミングを決定したり、インスタンスの問題のトラブルシューティングを行うことができ、またはシステム動作の理解をより深めることができます。

メトリックの例: 失敗率

アプリケーション・ヘルスの場合、一般的なKPIの1つが失敗率で、共通の定義は、失敗したトランザクションの数を合計トランザクション数で割ったものです。通常、このKPIはアプリケーションのモニタリングおよび管理ソフトウェアを通じて提供されます。

開発者は、カスタム・メトリックを使用して、アプリケーションからこのKPIを取得できます。アプリケーション・トランザクションが発生するたびに観測データを記録し、そのデータをモニタリング・サービスにポストします。この場合、失敗したトランザクション、成功したトランザクションおよびトランザクション・レイテンシ(完了したトランザクションごとに費やされた時間)を取得するようにメトリックを設定します。

アラーム機能の概要

アラームを使用して、クラウド・リソースのヘルス、容量およびパフォーマンスをモニタリングします。

リソースはメトリック・データ・ポイントをモニタリングに発行します。トリガーされると、アラームは構成済の宛先にメッセージを送信します。通知の場合、メッセージは、構成済トピックのサブスクリプションに送信されます。ストリーミングの場合、メッセージは構成済ストリームに送信されます)。

モニタリング・サービスのアラーム機能は、構成済宛先サービスと連携し、メトリックがアラーム指定のトリガーを満たしたときに通知します。前の図は、メトリック・データ・ポイントをモニタリングに発行するリソースから始まるフローを示しています。トリガーされると、アラームはアラーム・メッセージを構成済の宛先に送信します。通知の場合、メッセージは構成済トピックのサブスクリプションに送信されます。ストリーミングの場合、メッセージは構成済ストリームに送信されます。(この図は、Rawおよび集計メトリック・データについては説明していません。これらの詳細は、このページの上部にある「モニタリングの概要」の図を参照してください。)

構成すると、繰返し通知により継続的に起動状態であることが構成した繰返し間隔で通知されます。アラームがOK状態に戻ったとき、またはアラームがリセットされたときにも通知されます。

アラーム評価

モニタリングは、アラームのステータスを検出するために、1分間に1回アラームを評価します。

アラームが通知を分割する場合、モニタリングはトラッキングされた各メトリック・ストリームを評価します。そのメトリック・ストリームの評価が新しいFIRINGステータスまたはその他の条件を満たすイベントを示している場合、モニタリングはアラーム・メッセージを送信します。

モニタリングは、条件を満たすイベントについてアラームごとにメトリック・ストリームをトラッキングしますが、メッセージは宛先サービス制限の対象となります。

アラーム評価の図

メトリックCpuUtilizationの90パーセンタイルを測定するアラームについて考えてみます。

{
  "compartmentId": "ocid1.compartment.oc1..exampleuniqueID",
  "destinations": ["ocid1.onstopic.exampleuniqueID"],
  "displayName": "High CPU Utilization",
  "id": "ocid1.alarm.oc1..exampleuniqueID",
  "lifecycleState": "ACTIVE",
  "metricCompartmentId": "ocid1.compartment.oc1..exampleuniqueID",
  "namespace": "oci_computeagent",
  "pendingDuration": "PT3M",
  "query": "CpuUtilization[1m]{availabilityDomain = \"cumS:PHX-AD-1\"}.groupBy(availabilityDomain).percentile(0.9) > 85",
  "repeatNotificationDuration": "PT2H",
  "severity": "WARNING",
  "isEnabled": true,
  "timeCreated": "2023-02-01T01:02:29.600Z",
  "timeUpdated": "2023-02-03T01:02:29.600Z"
}

このアラームの例に関するノート:

パーセンタイルは、統計 (太字)として問合せで指定されます。

CpuUtilization[1m]{availabilityDomain = \"cumS:PHX-AD-1\"}.groupBy(availabilityDomain).percentile(0.9) > 85

各データ・ポイントは、1分間のウィンドウの90パーセンタイル(percentile(0.9))であり、問合せで間隔(太字)として指定されます。
```
CpuUtilization[1m]{availabilityDomain = \"cumS:PHX-AD-1\"}.groupBy(availabilityDomain).percentile(0.9) > 85
```
この統計のデータ・ポイント値は、null (不在)から100までです。
データ・ポイントの評価:
- 85を超えるデータ・ポイント値の場合、評価はtrue (1)です。true評価は、トリガー・ルール条件が満たされたことを意味します。
- 85を超えないデータ・ポイント値の場合、評価はfalse (0)です。
アラームは、トリガー・ルール条件が3分間連続して満たされるまで起動しません。この構成は、アラームのトリガー遅延(pendingDuration)であり、PT3Mとして設定されます。
直近の1分間で違反状態がクリアされると、アラームの状態はOKに更新されます。

次の図は、アラーム例の集計メトリック・ストリームを示しています。各データ・ポイントは正方形で示されます。

次の表に、アラーム例の連続したアラーム評価を示します。アラームは、3つの1分間隔の変動ウィンドウで評価されます。


評価期間タイムスタンプ	期間内の分数	データ・ポイントの評価*	ステータス
3	[1, 2, 3]	[0, 0, 0]	`OK`
4	[2, 3, 4]	[0, 0, 1]	`OK`
5	[3, 4, 5]	[0, 1, 1]	`OK`
6	[4, 5, 6]	[1, 1, 1]	`FIRING`
7	[5, 6, 7]	[1, 1, 1]	`FIRING`
8	[6, 7, 8]	[1, 1, 0]	`OK`
9	[7, 8, 9]	[1, 0, 0]	`OK`
10	[8, 9, 10]	[0, 0, 0]	`OK`

*1の値は、トリガー・ルール条件が満たされていることを意味します。

データ・ポイントのカウント方法

この項では、アラームによって取得されるデータ・ポイント(またはデータポイント)の数を決定する方法について説明します。この数値は、モニタリングの価格の見積りに役立ちます。

アラームによって取得されたデータ・ポイントの数を確認するには、最初に問合せストリームの数と分析された分数を取得します。

問合せストリームの数は、アラーム問合せによって返されるメトリック・ストリームによって異なります。
分析された分数は、アラーム属性interval、resolutionおよびpendingDurationによって異なります。アラーム問合せの場合、resolutionの有効な値は1mのみです。intervalの詳細は、間隔を参照してください。resolutionおよびpendingDurationの詳細は、モニタリングAPIを参照してください。

各アラームは毎分1回評価されるため、各アラームは1日に1440回評価されます。各評価は、intervalで定義された時間ウィンドウ内のデータを問い合せ、pendingDurationで定義された、アラームが存続する期間をチェックします。したがって、毎分分析された分数は、次の式で計算されます:

毎分分析された分数 = interval * ceiling(pendingDuration / resolution)

内部リセット期間について

内部リセット期間は、アラームが、前の評価で起動状態をトリガーした不在メトリックのチェックを停止するタイミングを決定します。メトリックが期間全体に存在しない場合、後のアラーム評価では、示されたメトリック・ストリームが無視されます。アラームの起動状態の原因となるメトリック・ストリームが他にない場合、アラームはOKに遷移し、RESETメッセージを送信します。デフォルトでは、RESETメッセージは13分後に届きます(内部リセット期間に3分のデフォルト・スラック期間を加えたもの)。スラック期間はカスタマイズできます。

内部リセット期間の長さは10分でグローバルに構成されるため、アラーム履歴に10分の差異が示されます。

内部リセット期間の開始は、アラームのタイプによって異なります。しきい値アラームの場合、最初の不在が検出されると内部リセット期間が開始されます。不在アラームの場合、内部リセット期間は不在検出期間の完了後に開始されます(デフォルトは2時間で、カスタマイズできます)。

内部リセット期間中に収集されるデータ・ポイント

10分間の内部リセット期間中の各評価では、その期間内のすべてのデータ・ポイントが考慮されます。

たとえば、しきい値を超えるメトリック・ストリーム(A)を考えてみます(次の図では赤色の破線)。アラームが起動します(F)。発行されたデータ・ポイントがないことが検出されると、内部リセット期間が開始されます。

次の図は、メトリック・ストリームAの内部リセット期間(t5からt15)を1つ示しています。t16の時点で、メトリック・ストリームAは評価されなくなります。

次の図は、メトリック・ストリームAの内部リセット期間(t3からt5、およびt6からt16)を2つ示しています。Aは、t6にデータ・ポイントを発行し、別の内部リセット期間を開始します。t17の時点で、メトリック・ストリームAは評価されなくなります。

しきい値アラームの例

しきい値アラームは、しきい値の外で発生したメトリック・ストリームについて報告します。以前に問題があったメトリック・ストリームが存在しない場合、アラームによってメトリック・ストリームの内部リセット期間が開始されます。

この例では、4つのメトリック・ストリームがしきい値アラームによって評価されます。コンソールには、最初の起動(1:30)およびOK(1:51)遷移状態が表示されます。アラームが起動状態の間、内部リセット期間が発生します。

この例での内部リセット期間およびその他の重要なイベントについて、次の表で説明します。

時間	状態	遷移	イベント	通知(メッセージ・タイプを参照)
12:00	`OK`	`OK`	すべての発行はしきい値内です。	`FIRING_TO_OK`
1:30	`FIRING`	`FIRING`	resource1からの発行がしきい値を超えています。	`OK_TO_FIRING`
1:35	`FIRING`	`--`	resource1の発行は検出されません。アラームによって、resource1の内部リセット期間が開始されます。	`--`
1:38	`FIRING`	`--`	resource2の発行は検出されません。アラームによって、resource2の内部リセット期間が開始されます。	`--`
1:45	`FIRING`	`--`	resource1の内部リセット期間は終了するため、アラームはresource1からの発行をチェックしなくなります。ただし、resource2はまだそれ自体の内部リセット期間内にあるため、アラームは起動しています。	`--`
1:48	`OK`	`OK`	resource2の内部リセット期間は終了するため、アラームはresource2からの発行をチェックしなくなります。残りのリソース(resource3およびresource4)からの発行はしきい値内です。	`RESET` (3分間のスラック期間の後、1:51頃に送信)

不在アラームの例

不在アラームは、不在メトリック・ストリームについて報告します。メトリック・ストリームが存在しない場合、アラームによって、メトリック・ストリームの不在検出期間が開始されます(デフォルトは2時間で、カスタマイズできます)。不在検出期間の完了後、アラームによってメトリック・ストリームの内部リセット期間が開始されます。

この例では、メトリック・ストリームは、デフォルトの2時間の不在検出期間とデフォルトの3分間のスラック期間を使用する不在アラームによって評価されます。コンソールには、最初の起動(2:00)およびOK(4:10)遷移状態が表示されます。アラームが起動状態の間、内部リセット期間が発生します。

この例での内部リセット期間およびその他の重要なイベントについて、次の表で説明します。

時間	状態	遷移	イベント	通知(メッセージ・タイプを参照)
1:00	`OK`	--	発行が検出されました。
2:00	`FIRING`	`FIRING`	resource-zの発行は検出されません。アラームによって、resource-zの不在検出期間が開始されます。	`OK_TO_FIRING`
4:00	`FIRING`	`--`	resource-zの不在検出期間が終了します。アラームによって、resource-zの内部リセット期間が開始されます。	`--`
4:10	`OK`	`OK`	resource-zの内部リセット期間は終了するため、アラームはresource-zからの発行をチェックしなくなります。アラームによってメトリック・ストリームはモニタリングされないため、アラームはOK状態に遷移します。	`RESET` (3分間のスラック期間の後、4:13頃に送信)

アラームの更新を反映するために必要な時間

アラームの更新には、すべての場所で反映されるまでに最大5分かかります。

たとえば、通知を分割するようにアラームを更新した場合、メトリック・ストリーム・ステータスがコンソールに移入されるまで最大5分かかることがあります。

アラームの検索

サポートされている属性を使用してアラームを検索します。

検索の詳細は、検索の概要を参照してください。属性の詳細は、アラーム・リファレンスを参照してください。

アラームの検索対応の属性

id
displayName
compartmentId
metricCompartmentId
namespace
query
severity
destinations
suppression
isEnabled
lifecycleState
timeCreated
timeUpdated
tags

メッセージ・タイプ

メッセージ・タイプは、メッセージが送信された理由を示します。

ノート

指定されたメッセージ・タイプは、指定された時刻にアラームの構成済トリガー遅延(ある場合)を加えて送信されます。

アラームで構成されている場合は、繰返しメッセージも送信されます。

次の表に、各メッセージ・タイプのアラーム状態と遷移を示します。

メッセージ・タイプ	状態	遷移	コメント
`OK_TO_FIRING`	`FIRING`	`OK`から`FIRING`
`FIRING_TO_OK`	`OK`	`FIRING`から`OK`
`REPEAT`	`FIRING`	--	このメッセージ・タイプは、アラームが`FIRING`状態を維持し、アラームが繰返し通知用に構成されている場合に送信されます。
`RESET`	`OK`	`FIRING`から`OK`	重要 `RESET`ステータスの変更が発生した場合は、リソースのヘルスを確認してください。このメッセージ・タイプは、1つ以上の内部リセット後にアラームが`OK`状態に遷移したときに送信されます。内部リセットは、アラームを`FIRING`状態に遷移させたメトリック・ストリームが、内部リセット期間全体にわたって継続的に存在しない場合に発生します。内部的にリセットされたメトリック・ストリームは、アラームによってトラッキングされなくなります。不在メトリック・ストリームの考えられる原因: メトリックを発行していたリソースが移動または終了したか、あるいはメトリックがエラー時にのみ発行される可能性があります。内部リセット期間の詳細は、内部リセット期間についてを参照してください。

メッセージの書式および例

アラーム・メッセージの例およびアラーム・メッセージの書式を参照してください。

モニタリングの概念

モニタリングの作業では、次の概念が必要です。

集計データ

メトリックのRAWデータ・ポイントの選択内容に統計と間隔を適用した結果。たとえば、メトリックCpuUtilizationのRAWデータ・ポイントの最後の24時間に統計maxおよび間隔1h (1時間)を適用できます。集計されたデータは、コンソールのデフォルトのメトリック・チャートに表示されます。集計データの特定のセットに対してメトリック問合せを作成することもできます。手順については、デフォルトのメトリック・チャートの表示およびメトリック問合せの作成を参照してください。

アラーム

評価されるアラーム問合せ、およびアラームが起動状態にあるときに、その他のアラーム・プロパティとともに使用される通知宛先。

アラームを作成するには、基本アラームの作成を参照してください。

アラーム問合せ

アラームを評価するMonitoring Query Language (MQL)式。アラームの問合せは、メトリック、統計、間隔およびトリガー・ルール (しきい値または不在)を指定する必要があります。モニタリング・サービスのアラーム機能は、返された各時系列の結果をブール値として解釈します。0はfalse、0以外の値はtrueを表します。true値は、トリガー・ルール条件が満たされたことを意味します。

基本的なアラーム問合せを作成するには、アラーム・メトリック・チャートを生成するための基本問合せの作成を参照してください。アラームを作成するには、基本アラームの作成を参照してください。

データ・ポイント

指定されたメトリックのタイムスタンプ/値ペア。例: 2022-05-10T22:19:00Z, 10.4

データ・ポイントはRawまたは集計のいずれかです。RAWデータ・ポイントは、PostMetricData操作を使用してメトリック・ネームスペースによりモニタリング・サービスにポストされます。ポストされるデータ・ポイントの頻度は、メトリック・ネームスペースによって異なります。たとえば、カスタム・ネームスペースによって、メトリックのデータ・ポイントが20秒の頻度で送信される場合があります。

集計されたデータ・ポイントは、統計および間隔をRAWデータ・ポイントに適用した結果です。集計されたデータ・ポイントの間隔は、SummarizeMetricsDataリクエストで指定されます。たとえば、統計sumおよび間隔1h (1時間)を指定するリクエストでは、メトリックで使用可能なRAWデータ・ポイントの毎時にsum値が返されます。

ディメンション

メトリック定義で指定される修飾子。例: oci_computeagentメトリックの定義で指定されるリソース識別子(resourceId)。ディメンションを使用してメトリック・データをフィルタ処理またはグループ化します。可用性ドメインでフィルタ処理するためのディメンション名/値ペアの例: availabilityDomain = "VeBZ:PHX-AD-1"

メトリック・チャートまたは問合せのディメンションを選択するには、メトリックをフィルタするためのディメンションの選択および問合せのディメンションの選択を参照してください。

アラームの間隔を選択するには、アラーム問合せの間隔の選択を参照してください。

頻度

メトリックについて、ポストされた各Rawデータ・ポイント間の期間。(RAWデータ・ポイントは、メトリック・ネームスペースによってモニタリング・サービスにポストされます。)頻度はメトリックによって異なりますが、デフォルトのサービス・メトリックの頻度は通常60秒です(1分当たりに1つのデータ・ポイントがポストされます)。レゾリューションも参照してください。

間隔

Rawデータ・ポイントのセットの変換に使用される時間ウィンドウ。

集計されたデータ・ポイントのタイムスタンプは、RAWデータ・ポイントが評価される時間ウィンドウの終わりに対応します。たとえば、5分間隔では、タイムスタンプ「2:05」は2:00:nから2:05:00までの5分間の時間ウィンドウに対応します。

この図は、集計データ・ポイントのタイムスタンプが間隔にどのように対応するかを示しています。

次の問合せの例(MQL式)では、5分間隔を指定しています。MQL式の有効な間隔オプションについては、間隔(Monitoring Query Language (MQL)リファレンス)を参照してください。

CpuUtilization[5m].max()

ノート

間隔でサポートされる値は、メトリック問合せで指定された時間範囲によって異なります(アラーム問合せには適用されません)。時間範囲が小さくなるほど、多くの間隔値がサポートされます。たとえば、時間範囲に1時間を選択すると、すべての間隔値がサポートされます。時間範囲に90日を選択した場合、1時間から1日の間の間隔値のみがサポートされます。

メトリック・チャートまたは問合せの間隔を選択するには、デフォルトのメトリック・チャートの間隔の変更および問合せの間隔の選択を参照してください。

アラームの間隔を選択するには、アラーム問合せの間隔の選択を参照してください。

レゾリューションも参照してください。

メッセージ

モニタリング・サービスのアラーム機能がアラームの構成済通知宛先のトピックに公開する内容。アラームが別の状態に遷移する(OKからFIRINGへなど)と、メッセージが送信されます。

アラーム・メッセージの詳細は、メッセージの書式および例を参照してください。

メタデータ

メトリック定義で指定される参照。例: oci_computeagentメトリック DiskBytesReadの定義で指定された単位(バイト)。メタデータを使用して、メトリックに関する追加情報を調べます。メトリックの定義は、サポートされているサービスを参照してください。

メトリック

リソースのヘルス、容量またはパフォーマンスに関連する測定。例: コンピュート・インスタンスの使用状況を測定するoci_computeagentメトリックCpuUtilization。メトリックの定義は、サポートされているサービスを参照してください。

ノート

メトリックのリソースにはOCIDがありません。

メトリック定義

メトリックのメトリック・ネームスペースにより提供される参照、修飾子およびその他の情報のセット。たとえば、oci_computeagentメトリックDiskBytesReadは、ディメンション(リソース識別子など)とメタデータ(単位のバイトを指定)およびそのメトリック・ネームスペース(oci_computeagent)の識別によって定義されます。ポストされた各データ・ポイント・セットには、この情報が送信されます。ListMetricData API操作を使用してメトリック定義を取得します。メトリックの定義は、サポートされているサービスを参照してください。

問合せのメトリック名を選択するには、問合せのメトリック名の選択を参照してください。

アラームのメトリック名を選択するには、アラーム・メトリック・チャートを生成するための基本問合せの作成および基本アラームの作成を参照してください。

メトリック・ネームスペース

メトリックを発行するリソース、サービスまたはアプリケーションのインジケータ。メトリック定義で指定されます。たとえば、コンピュート・インスタンスでOracle Cloud Agentソフトウェアによって発行されたCpuUtilizationメトリック定義には、メトリック・ネームスペースoci_computeagentがCpuUtilizationメトリックのソースとしてリストされます。メトリックの定義は、サポートされているサービスを参照してください。

メトリック・チャートまたは問合せのメトリック・ネームスペースを選択するには、メトリック・ネームスペースのデフォルト・メトリック・チャートの表示(複数リソース)および問合せのメトリック・ネームスペースの選択を参照してください。

アラームのメトリック・ネームスペースを選択するには、アラーム・メトリック・チャートを生成するための基本問合せの作成および基本アラームの作成を参照してください。

メトリック・ストリーム

メトリックおよびゼロ以上のディメンション値の集計データの個別のセット。

メトリック・ストリームのステータス・ページでは、各メトリック・ストリームはディメンションのキーと値のペアのセットに対応します。

メトリック・チャート(コンソール内)では、各メトリック・ストリームが線で示されます(すべてのメトリック・ストリームを集計しないかぎり)。

次の図は、チャート内のメトリック・ストリームを示しています。チャートの各線は、メトリック・ストリームに対応します。

この図は、チャート内のメトリック・ストリームを示しています。チャートの各線は、メトリック・ストリームに対応します。

たとえば、AD-1可用性ドメインに3つのコンピュート・インスタンスを含み(ipexampleインスタンス・プールに2つを含む)、AD-2可用性ドメインに4番目のインスタンスを含むコンパートメントがあるとします。この例では、「CPU使用率」メトリック・チャートに4本の線(インスタンスごとに1行)が表示されています。AD-1可用性ドメインでフィルタ処理されると、チャートに3本の線が表示されます。ipexampleインスタンス・プールでさらにフィルタ処理されると、チャートに2つの線が表示されます。

問合せでメトリック・ストリームを選択するには、メトリックをフィルタするためのディメンションの選択、問合せのディメンションの選択およびアラーム問合せのディメンションの選択を参照してください。

メトリック・ストリームごとの通知のアラームを設定するには、メトリック・ストリーム別にメッセージを分割するアラームの作成およびシナリオ: メトリック・ストリーム別のメッセージの分割を参照してください。

通知宛先

アラームが別の状態に遷移する(OKからFIRINGへなど)ときのメッセージ送信の詳細。詳細と設定は、宛先サービスによって異なる場合があります。使用可能な宛先サービスには、通知およびストリーミングが含まれます。

通知サービスには、トピックを指定します。(アラームのトピックを作成する場合は、1つ以上のサブスクリプション・プロトコル(PagerDutyなど)も指定します。

ストリーミング・サービスには、ストリームを指定します。

トピックおよびストリームに送信されるアラーム・メッセージの例については、アラーム・メッセージの例を参照してください。

アラームに通知の宛先を設定するには、アラームの通知の定義を参照してください。

Oracle Cloud Agentソフトウェア

Rawデータ・ポイントをモニタリング・サービスにポストするためにコンピュート・インスタンスによって使用されるソフトウェア。サポートされているイメージの最新バージョンで自動的にインストールされます。コンピュート・インスタンスのモニタリングの有効化を参照してください。

query

集計データを返すために評価するMonitoring Query Language (MQL)式および関連情報(メトリック・ネームスペースなど)。問合せには、メトリック、統計および間隔を指定する必要があります。

メトリック問合せを作成するには、問合せの作成を参照してください。

アラーム問合せを作成するには、アラーム・メトリック・チャートを生成するための基本問合せの作成を参照してください。

レゾリューション

時間ウィンドウ間の期間、または時間ウィンドウが移動する際の規則性。たとえば、1mのレゾリューションを使用すると、1分ごとに集計が取得されます。

ノート

メトリック問合せの場合、選択した間隔によって、戻されるデータの最大時間範囲を決定する、リクエストのデフォルトのレゾリューションが決定されます。

アラームの問合せの場合、指定した間隔はリクエストのレゾリューションに影響しません。アラーム問合せリクエストのレゾリューションで有効な値は、1mのみです。アラーム問合せに使用されるレゾリューションのパラメータの詳細は、アラームを参照してください。

次の図に示すように、レゾリューションは前のウィンドウに対する各集計ウィンドウの開始時間を制御しますが、間隔はウィンドウの長さを制御します。両方のリクエストは、(間隔からの) 5分間の各ウィンドウ内のデータに統計maxを適用し、そのウィンドウで最も高いCPUutilizationカウンタを表す単一の集計データ・ポイントを生成します。レゾリューションの値のみが異なります。このレゾリューションによって、集計ウィンドウが移動する規則性、または連続する集計ウィンドウの開始時間が変更されます。リクエストAはレゾリューションを指定しないため、間隔と同じデフォルト値(5分)を使用します。このリクエストの5分間の集計ウィンドウは、0:nから5:00、5:nから10:00などから発行されたデータ・ポイントのセットから取得されます。リクエストBは1分のレゾリューションを指定しているため、その5分間の集約ウィンドウは、0:nから5:00、1:nから6:00などから1分ごとに発行されるデータ・ポイントのセットから取得されます。

この図は、レゾリューションに従って集計ウィンドウがどのように開始されるかを示しています。

間隔とは異なるデフォルト以外のレゾリューションを指定するには、問合せのデフォルト以外のレゾリューションの選択およびアラームの作成を参照してください。

リソース・グループ

フィルタまたは結果の集計に使用できるカスタム・メトリックで提供されるカスタム文字列。リソース・グループは、ポストされたメトリックの定義内に存在する必要があります。メトリックごとに適用できるリソース・グループは1つのみです。

問合せでリソース・グループを選択するには、問合せでのリソース・グループの選択を参照してください。

アラーム問合せでリソース・グループを選択するには、アラーム問合せでのリソース・グループの選択を参照してください。

統計

Rawデータ・ポイントのセットに適用される集計関数。

メトリック・チャートまたは問合せの統計を選択するには、デフォルト・メトリック・チャートの統計の変更および問合せの統計の選択を参照してください。

アラーム問合せの統計を選択するには、アラーム問合せの統計の選択を参照してください。

suppression

指定した時間範囲内にメッセージの公開を停止するための構成。システムの保守中にアラーム通知を一時停止するのに役立ちます。

アラームを抑制するには、単一のアラームの抑制および複数のアラームの抑制を参照してください。

時間範囲

必要なメトリック・データの境界(タイムスタンプ)。たとえば、過去1時間などです。

メトリック・チャートまたは問合せの時間範囲を選択するには、デフォルト・メトリック・チャートの時間範囲の変更、カスタム・メトリック・チャートの時間範囲の変更および問合せのデフォルト以外の時間範囲の選択を参照してください。

トリガー・ルール

アラームを起動状態にするために満たす必要がある条件。トリガー・ルールは、メトリックのしきい値または不在に基づきます。

アラームにトリガー・ルールを設定するには、アラームへのトリガー・ルールの追加を参照してください。

可用性

モニタリング・サービスは、すべてのOracle Cloud Infrastructure商用リージョンで使用できます。使用可能なリージョンのリストと、関連する場所、リージョン識別子、リージョン・キーおよび可用性ドメインは、リージョンおよび可用性ドメインについてを参照してください。

サポートされているサービス

次のサービスには、モニタリングにメトリックを発行できるリソースまたはコンポーネントが含まれます。

アナリティクス・クラウド - メトリックのモニターを参照してください
APIゲートウェイ - APIゲートウェイ・メトリックを参照してください
アプリケーション・パフォーマンス・モニタリング - アプリケーション・パフォーマンス・モニタリングのメトリックを参照してください
自律型リカバリ・サービス - リカバリ・サービス・メトリックを参照してください
要塞 - 要塞メトリックを参照してください
ビッグ・データ・サービス - クラスタ・メトリックの管理を参照してください
ブロック・ボリューム - ブロック・ボリューム・メトリックを参照してください
ブロックチェーン・プラットフォーム - メトリックのモニターを参照してください
コンピュート - コンピュート・メトリックおよびモニタリングを参照してください
Compute Cloud@Customer - Compute Cloud@Customerメトリックを参照してください
コネクタ・ハブ - コネクタ・ハブのメトリックを参照してください
コンテナ・インスタンス - コンテナ・インスタンス・メトリックを参照してください
データ・カタログ - データ・カタログ・メトリックを参照してください
データ・フロー - データ・フロー・メトリックを参照してください
データ統合 - データ統合メトリックを参照してください
データ・サイエンス - メトリックを参照してください
データベース - 次のページを参照してください:
- Autonomous Databaseメトリックを使用したパフォーマンスのモニター (Autonomous Database Serverless)
- Autonomous Databaseメトリックを使用したデータベースの監視(専用Exadataインフラストラクチャ上のAutonomous Database)
- モニタリング・サービスのOracle Exadata Database Service on Dedicated Infrastructureのメトリック (Exadata Cloud Infrastructureのリファレンス・ガイドから)
- データベース管理サービスでのベース・データベース・サービスのメトリック: データベース管理メトリックを使用したデータベースのモニター
- 外部データベースのメトリック
データベース管理 - Oracle Databasesのデータベース管理メトリックを参照してください
データベース移行 - データベース移行メトリックを参照してください
OCI Database with PostgreSQL - OCI Database with PostgreSQLのメトリックを参照してください
DevOps - DevOpsメトリックを参照してください
デジタル・アシスタント - デジタル・アシスタント・メトリックを参照してください
DNS - DNSメトリックを参照してください
電子メール配信 - 電子メール配信メトリックを参照してください
イベント - イベント・メトリックを参照してください
ファイル・ストレージ - ファイル・システム・メトリックを参照してください
ファンクション - ファンクション・メトリックを参照してください
Globally Distributed Autonomous Database - Autonomous Databaseメトリックを使用したパフォーマンスのモニターを参照してください
Globally Distributed Exadata Database on Exascale Infrastructure (モニタリング・サービスのOracle Exadata Database Service on Dedicated Infrastructureのメトリックを参照)
GoldenGate - Oracle Cloud Infrastructure GoldenGateメトリックを参照してください
ヘルス・チェック - ヘルス・チェック・メトリックを参照してください
統合生成2: メッセージ・メトリックの表示
統合3: メッセージ・メトリックおよび請求可能メッセージの表示
Java管理 - Java管理メトリックを参照してください
Kubernetesエンジン - Kubernetesエンジン(OKE)のメトリックを参照してください
ロード・バランサ - ロード・バランサ・メトリックを参照してください
ロギング - ロギング・メトリックを参照してください
ログ・アナリティクス - サービス・メトリックを使用したログ・アナリティクスのモニターを参照してください
メディア・ストリーム(メディア・サービス) - メディア・ストリームのメトリックを参照してください
管理エージェント - 管理エージェント・メトリックを参照してください
HeatWave - メトリックを参照してください
ネットワーキング - ネットワーキング・メトリックを参照してください
NoSQLデータベース・クラウド - サービス・メトリックを参照してください
通知 - 通知メトリックを参照してください
ネットワーク・ファイアウォール - ファイアウォールのモニタリングを参照してください
オブジェクト・ストレージ - オブジェクト・ストレージ・メトリックを参照してください
Opsインサイト - Opsインサイトのメトリックを参照してください
Oracle APEX Application Development - APEXサービス・パフォーマンスのモニターを参照してください
OS管理ハブ - OS管理ハブのメトリックを参照してください
プロセス自動化 - Oracle Cloud Infrastructure Process Automationのモニターを参照してください
キュー - キュー・メトリックを参照してください
サービス・メッシュ - サービス・メッシュ・メトリックを参照してください
スタック・モニタリング - メトリック・リファレンスを参照してください
ストリーミング - ストリーミング・メトリックを参照してください
ボールト - ボールト・リソースのモニタリングを参照してください
脆弱性スキャン - スキャン・メトリックを参照してください
WAF - エッジ・ポリシー・メトリックを参照してください

リソース識別子

ほとんどのタイプのOracle Cloud Infrastructureリソースには、Oracle Cloud ID (OCID)と呼ばれる、Oracleによって割り当てられた一意の識別子があります。OCIDのフォーマットおよびその他のリソース識別方法の詳細は、リソース識別子を参照してください。リソース識別子を参照してください。

ノート

メトリックのリソースにはOCIDがありません。

モニタリングへのアクセス方法

Oracle Cloud Infrastructure (OCI)には、コンソール(ブラウザベースのインタフェース)、REST APIまたはOCI CLIを使用してアクセスできます。コンソール、APIおよびCLIの使用手順は、このドキュメント全体のトピックに記載されています。使用可能なSDKのリストについては、ソフトウェア開発キットとコマンドライン・インタフェースを参照してください。

コンソール: コンソールを使用してモニタリングにアクセスするには、サポートされているブラウザを使用する必要があります。コンソールのサインイン・ページに移動するには、このページの上部にあるナビゲーション・メニューを開き、「インフラストラクチャ・コンソール」を選択します。クラウド・テナント、ユーザー名およびパスワードの入力を求められます。ナビゲーション・メニューを開き、「監視および管理」を選択します。「モニタリング」で、「サービス・メトリック」を選択します。

API: APIを介してモニタリングにアクセスするには、メトリックおよびアラームにモニタリングAPIを使用し、通知に通知APIを使用します(アラームと使用)。

CLI: モニタリングのコマンドライン・リファレンスおよび通知のコマンドライン・リファレンスを参照してください。

認証と認可

Oracle Cloud Infrastructureの各サービスは、すべてのインタフェース(コンソール、SDKまたはCLI、およびREST API)の認証および認可のためにIAMと統合されています。

組織の管理者は、どのユーザーがどのサービスとリソースにアクセスできるか、およびアクセスのタイプを制御する、グループ、コンパートメントおよびポリシーを設定する必要があります。たとえば、ポリシーは、新規ユーザーの作成、クラウド・ネットワークの作成と管理、インスタンスの作成、バケットの作成、オブジェクトのダウンロードなどを実行できるユーザーを制御します。詳細は、アイデンティティ・ドメインの管理を参照してください。異なる各サービスに対するポリシーの記述の詳細は、ポリシー・リファレンスを参照してください。

会社が所有するOracle Cloud Infrastructureリソースを使用する必要がある通常のユーザー(管理者ではない)の場合は、ユーザーIDを設定するよう管理者に連絡してください。管理者は、ユーザーが使用できるコンパートメントを確認できます。

モニタリングのユーザー認可の詳細は、IAMポリシーを参照してください。

管理者: グループにメトリックへのアクセス権を付与する共通ポリシーについては、グループのメトリック・アクセスを参照してください。共通アラーム・ポリシーについては、グループのアラーム・アクセスを参照してください。インスタンスなどのリソースを認可してAPIコールを実行するには、リソースを動的グループに追加します。動的グループの照合ルールを使用してリソースを追加してから、メトリックへの動的グループ・アクセスを可能にするポリシーを作成します。リソースのメトリック・アクセスを参照してください。

モニタリングの制限

適用可能な制限の一覧と制限の引上げをリクエストする手順は、モニタリング制限を参照してください。

その他の制限は次のとおりです。

ストレージの制限


項目	格納された時間範囲
メトリックの定義	90日
アラーム履歴エントリ	90日

戻りデータ制限(メトリック)

メトリックを問い合せてメトリック・チャートを表示する場合、戻されるデータは一定の制限に従います。返されるデータの制限情報には、100,000データ・ポイントの最大値と時間範囲の最大値(レゾリューションによって決定され、間隔に関連しています)が含まれます。MetricDataを参照してください。

アラーム・メッセージの制限

アラーム評価ごとのメッセージの最大数は、アラームの宛先によって異なります。制限は、宛先に使用されるOracle Cloud Infrastructureサービスに関連付けられています。

モニタリングは、条件を満たすイベントについて、アラーム当たり200,000のメトリック・ストリームをトラッキングします。アラーム評価の詳細は、このページのアラーム評価を参照してください。

アラームの宛先	配信	評価当たりの最大アラーム・メッセージ数
トピック(通知)	少なくとも1回	60
ストリーム(ストリーミング)	少なくとも1回	100,000

たとえば、トピックを宛先として使用して、200個のメトリック・ストリーム間で通知を分割するアラームの次の評価を考えてみます。

アラーム評価(時間)	メトリック・ストリーム遷移	生成済メッセージ	送信済メッセージ	削除済メッセージ
00:01:00	110個のメトリック・ストリームがOKからFIRINGに移行します。	110	60	50
00:02:00	90個のメトリック・ストリームがOKからFIRINGに移行します。	90	60	30

トピックまたはストリームが過剰に使用されると、アラーム通知が遅延する可能性があります。複数のリソースがそのトピックまたはストリームを使用している場合に、過剰使用が発生する可能性があります。

制限内で作業するためのベスト・プラクティス

大量のアラーム通知が予想される場合は、次のベスト・プラクティスに従って、アラーム・メッセージ制限の超過および関連する遅延を防止してください。

大量のアラームで使用する単一のトピックまたはストリームを予約します。複数の大量アラームには、1つのトピックまたはストリームを使用しないでください。
1分当たり60を超えるメッセージが予想される場合は、アラームの宛先としてストリーミングを指定します。
ストリーム:
- 予想される負荷に基づいてパーティションを作成します。ストリーミング・リソースの制限を参照してください。
- アラーム・メッセージがストリーム領域を超える場合は、より多くのパーティションを持つ別のストリームを使用するようにアラームを更新します。たとえば、元のストリームに5個のパーティションが含まれている場合は、10個のパーティションを含むストリームを作成してから、新しいストリームを使用するようにアラームを更新します。
  ノート
  
  メッセージが欠落しないようにするには、メッセージを受信しなくなるまで元のストリームを消費し続けます。
テナンシの制限を増やす:
- トピック: メッセージの公開の制限(PublishMessage操作)を参照してください。
- ストリーム: ストリーミング・リソースの制限を参照してください。

トラブルシューティングの制限

メトリック・ストリームが多すぎるという問合せエラーをトラブルシューティングするには、エラー: 最大メトリック・ストリーム数を超えましたを参照してください。

トラブルシューティング情報は、モニタリングのトラブルシューティングを参照してください。

セキュリティ

このトピックでは、モニタリングのセキュリティについて説明します。

セキュリティ情報や推奨事項など、モニタリングを保護する方法の詳細は、モニタリングの保護を参照してください。

Oracle Cloud Infrastructureドキュメント