モニタリングの概要
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)です。
- 85を超えるデータ・ポイント値の場合、評価はtrue (
- アラームは、トリガー・ルール条件が3分間連続して満たされるまで起動しません。この構成は、アラームのトリガー遅延(
pendingDuration)で、PT3Mとして設定されます。 - 最新の1分間、違反状態がクリアされると、アラームの状態がOKに更新されます。
次の図は、サンプル・アラームの集計メトリック・ストリームを示しています。各データ・ポイントは正方形で示されます。
次の表に、例のアラーム評価を連続して示します。アラームは、3分間隔の変動ウィンドウで評価されます。
| 評価期間タイムスタンプ | 所要時間(分) | データ・ポイント評価* | ステータス |
|---|---|---|---|
| 3 | [1, 2, 3] | [0, 0, 0] | 結構です |
| 4 | [2, 3, 4] | [0, 0, 1] | 結構です |
| 5 | [3, 4, 5] | [0, 1, 1] | 結構です |
| 6 | [4, 5, 6] | [1, 1, 1] | 起動 |
| 7 | [5, 6, 7] | [1, 1, 1] | 起動 |
| 8 | [6, 7, 8] | [1, 1, 0] | 結構です |
| 9 | [7, 8, 9] | [1, 0, 0] | 結構です |
| 10 | [8, 9, 10] | [0, 0, 0] | 結構です |
*1の値は、トリガー・ルール条件が満たされていることを意味します。
内部リセット期間について
内部リセット期間は、アラームが、前回の評価で起動状態をトリガーした不在メトリックのチェックを停止するタイミングを決定します。メトリックが期間全体に存在しない場合、後でアラーム評価によって示されたメトリック・ストリームは無視されます。アラームの起動状態の原因となっているメトリック・ストリームが他にない場合、アラームはOKに遷移し、RESETメッセージを送信します。デフォルトでは、RESETメッセージは13分(内部リセット期間とデフォルトのスラック期間3分)後に届きます。スラック期間をカスタマイズできます。
内部リセット期間の長さはグローバルに10分で構成されるため、アラーム履歴に10分の差分が表示されます。
内部リセット期間の開始は、アラームのタイプによって異なります。しきい値アラームの場合、最初の不在が検出されると、内部リセット期間が開始されます。休暇欠勤アラームの場合、内部リセット期間は、休暇欠勤検出期間(2時間)の完了後に開始されます。
内部リセット期間中に取得されたデータ・ポイント
10分間の内部リセット期間中の各評価では、その期間内のすべてのデータ・ポイントが考慮されます。
たとえば、しきい値を超えるメトリック・ストリーム(A)を考えてみます(次の図では赤色の破線)。アラームが起動します(F)。生成されたデータ・ポイントがないことが検出されると、内部リセット期間が開始されます。
次の図は、メトリック・ストリームAの単一の内部リセット期間(t5からt15の時間)を示しています。t16の時点で、メトリック・ストリームAは評価されなくなりました。
次の図は、メトリック・ストリームAの内部リセット期間(t3からt5、t6からt16)を2つ示しています。Aは、t6にデータ・ポイントを発行し、別の内部リセット期間を開始します。t17の時点で、メトリック・ストリームAは評価されなくなりました。
しきい値アラームの例
しきい値アラームは、しきい値の範囲外で発生したメトリック・ストリームについてレポートします。以前に問題のあるメトリック・ストリームがない場合、アラームはメトリック・ストリームの内部リセット期間を開始します。
この例では、4つのメトリック・ストリームがしきい値アラームによって評価されます。コンソールに、初期起動(1:30)およびOK(1:51)遷移状態が表示されます。内部リセット期間は、アラームが起動状態にある間に発生します。
次の表で、この例の内部リセット期間およびその他の重要なイベントについて説明します。
| 時間 | 状態 | 遷移 | イベント | 通知(メッセージ・タイプを参照) |
|---|---|---|---|---|
| 12:00 | 結構です | 結構です | すべての排出量はしきい値内です。 | FIRING_TO_OK |
| 1:30 | 起動 | 起動 | resource1からの排出がしきい値を超えています。 | OK_TO_FIRING |
| 1:35 | 起動 | -- | resource1の排出は検出されません。アラームは、resource1の内部リセット期間を開始します。 | -- |
| 1:38 | 起動 | -- | resource2の排出は検出されません。アラームは、resource2の内部リセット期間を開始します。 | -- |
| 1:45 | 起動 | -- | 内部リセット期間はresource1で終了するため、アラームではresource1からの排出がチェックされなくなります。ただし、resource2は依然として独自の内部リセット期間にあるため、アラームは起動し続けます。 | -- |
| 1:48 | 結構です | 結構です | 内部リセット期間はresource2で終了するため、アラームではresource2からの排出がチェックされなくなります。残りのリソース(resource3およびresource4)からの排出はしきい値内です。 | RESET (3分間のスラック期間の後、約1:51に送信) |
休暇欠勤アラームの例
不在アラームは、不在メトリック・ストリームについてレポートします。メトリック・ストリームがない場合、アラームはメトリック・ストリームの不在検出期間を開始します(デフォルトは2時間で、カスタマイズできます)。休暇欠勤検出期間の完了後、アラームはメトリック・ストリームの内部リセット期間を開始します。
この例では、メトリック・ストリームは、デフォルトの2時間の休暇欠勤検出期間とデフォルトの3分間のスラック期間を使用する休暇欠勤アラームによって評価されます。コンソールに、初期起動(2:00)およびOK(4:10)遷移状態が表示されます。内部リセット期間は、アラームが起動状態にある間に発生します。
次の表で、この例の内部リセット期間およびその他の重要なイベントについて説明します。
| 時間 | 状態 | 遷移 | イベント | 通知(メッセージ・タイプを参照) |
|---|---|---|---|---|
| 1:00 | 結構です | -- | 排出が検出されます。 | |
| 2:00 | 起動 | 起動 | resource-zの放出は検出されません。アラームは、resource-zの休暇欠勤検出期間を開始します。 | OK_TO_FIRING |
| 4:00 | 起動 | -- | resource-zの休暇欠勤検出期間が終了します。アラームは、resource-zの内部リセット期間を開始します。 | -- |
| 4:10 | 結構です | 結構です | 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 |
重要: このメッセージ・タイプは、アラームが1つ以上の内部リセットの後に 存在しないメトリック・ストリームの考えられる原因: メトリックを発行したリソースが移動または終了したか、メトリックが障害発生時にのみ発行される場合があります。内部リセット期間の詳細は、「内部リセット期間について」を参照してください。 |
メッセージの書式および例
「アラーム・メッセージの例」および「アラーム・メッセージ形式」を参照してください。
モニタリングの概念
モニタリングを作業するには、次の概念が必要です。
- 集計データ
- メトリックのRAWデータ・ポイントの選択内容に統計および間隔を適用した結果。たとえば、メトリック
CpuUtilizationのRAWデータ・ポイントの最後の24時間に統計maxおよび間隔1h(1時間)を適用できます。集計されたデータは、コンソールのデフォルトのメトリック・チャートに表示されます。集計データの特定のセットに対してメトリック問合せを作成することもできます。手順については、デフォルトのメトリック・チャートの表示およびメトリック問合せの作成を参照してください。 - アラーム
- 評価されるアラーム問合せ、およびアラームが起動状態にあるときに、その他のアラーム・プロパティとともに使用される通知宛先。
- アラーム問合せ
- アラームを評価するMonitoring Query Language (MQL)式。アラームの問合せは、メトリック、統計、間隔およびトリガー・ルール (しきい値または不在)を指定する必要があります。モニタリング・サービスのアラーム機能は、返された各時系列の結果をブール値として解釈します。0はfalse、0以外の値はtrueを表します。true値は、トリガー・ルール条件が満たされたことを意味します。
- データ・ポイント
- 指定されたメトリックのタイムスタンプ/値ペア。例:
2022-05-10T22:19:00Z, 10.4 - ディメンション
- メトリック定義で指定される修飾子。例: oci_computeagentメトリックの定義で指定されるリソース識別子(
resourceId)。ディメンションを使用してメトリック・データをフィルタ処理またはグループ化します。可用性ドメインでフィルタ処理するためのディメンション名/値ペアの例:availabilityDomain = "VeBZ:PHX-AD-1" - 頻度
- メトリックについて、ポストされた各Rawデータ・ポイント間の期間。(RAWデータ・ポイントは、メトリック・ネームスペースによってモニタリング・サービスにポストされます。)頻度はメトリックによって異なりますが、デフォルトのサービス・メトリックの頻度は通常60秒です(1分当たりに1つのデータ・ポイントがポストされます)。レゾリューションも参照してください。
- 間隔
- rawデータ・ポイントのセットの変換に使用される時間ウィンドウ。
- メッセージ
- モニタリング・サービスのアラーム機能がアラームの構成済通知宛先のトピックに公開する内容。アラームが別の状態に遷移する(
OKからFIRINGへなど)と、メッセージが送信されます。 - メタデータ
- メトリック定義で指定される参照。例: oci_computeagentメトリック
DiskBytesReadの定義で指定された単位(バイト)。メタデータを使用して、メトリックに関する追加情報を調べます。メトリックの定義は、サポートされているサービスを参照してください。 - メトリック
- リソースのヘルス、容量またはパフォーマンスに関連する測定。例: コンピュート・インスタンスの使用状況を測定する
oci_computeagentメトリックCpuUtilization。メトリックの定義は、サポートされているサービスを参照してください。 - メトリック定義
- メトリックのメトリック・ネームスペースにより提供される参照、修飾子およびその他の情報のセット。たとえば、oci_computeagentメトリック
DiskBytesReadは、ディメンション(リソース識別子など)とメタデータ(単位のバイトを指定)およびそのメトリック・ネームスペース(oci_computeagent)の識別によって定義されます。ポストされた各データ・ポイント・セットには、この情報が送信されます。ListMetricData API操作を使用してメトリック定義を取得します。メトリックの定義は、サポートされているサービスを参照してください。 - メトリック・ネームスペース
- メトリックを発行するリソース、サービスまたはアプリケーションのインジケータ。メトリック定義で指定されます。たとえば、コンピュート・インスタンスでOracle Cloud Agentソフトウェアによって発行された
CpuUtilizationメトリック定義には、メトリック・ネームスペースoci_computeagentがCpuUtilizationメトリックのソースとしてリストされます。メトリックの定義は、サポートされているサービスを参照してください。 - メトリック・ストリーム
- メトリックおよびゼロ以上のディメンション値の集計データの個別のセット。
- 次の図は、チャート内のメトリック・ストリームを示しています。チャートの各線は、メトリック・ストリームに対応します。
- 通知宛先
- アラームが別の状態に遷移する(
OKからFIRINGなど)ときのメッセージ送信の詳細。詳細と設定は、宛先サービスによって異なる場合があります。使用可能な宛先サービスには、通知およびストリーミングが含まれます。 - 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商用リージョンで使用できます。使用可能なリージョンのリストと、関連する場所、リージョン識別子、リージョン・キーおよび可用性ドメインは、リージョンおよび可用性ドメインについてを参照してください。
サポートされているサービス
次のサービスには、モニタリングにメトリックを発行できるリソースまたはコンポーネントが含まれます。
- アナリティクス・クラウド - Oracle Analytics Cloudのメトリックについてを参照してください
- APIゲートウェイ - APIゲートウェイ・メトリックを参照してください
- アプリケーション・パフォーマンス・モニタリング - アプリケーション・パフォーマンス・モニタリングのメトリックを参照してください
- 自律型リカバリ・サービス - リカバリ・サービス・メトリックを参照してください
- 要塞 - 要塞メトリックを参照してください
- ビッグ・データ・サービス - クラスタのメトリックの表示を参照してください
- ブロック・ボリューム - ブロック・ボリューム・メトリックを参照してください
- ブロックチェーン・プラットフォーム - メトリックのモニター(ブロックチェーン・プラットフォーム)を参照してください
-
コンピュート - 次のページを参照してください:
-
Compute Cloud@Customer - Compute Cloud@Customerメトリックを参照してください
- コネクタ・ハブ - コネクタ・ハブ・メトリックを参照してください
- Container Engine for Kubernetes - Container Engine for Kubernetesメトリックを参照してください
- コンテナ・インスタンス - コンテナ・インスタンス・メトリックを参照してください
- データ・カタログ - データ・カタログ・メトリックを参照してください
- データ・フロー - データ・フロー・メトリックを参照してください
- データ統合 - データ統合メトリックを参照してください
- データ・サイエンス - ノートブック・セッション・メトリックについてを参照してください
- データ転送 - これらのページを参照してください:
- ディスクベースのデータ・インポート: データ転送のディスクベース・メトリックの表示
- アプライアンス・ベースのデータ・インポート: データ転送のアプライアンス・インポートベース・メトリックの表示
- データ・エクスポート: データ転送のアプライアンス・エクスポートベース・メトリックの表示
- データベース - 次のページを参照してください:
- Autonomous Databaseメトリックを使用したパフォーマンスのモニター (Autonomous Databaseサーバーレス)
- Autonomous Databaseメトリックを使用したデータベースのモニター(専用Exadataインフラストラクチャ上のAutonomous Database)
- モニタリング・サービスのOracle Exadata Database Service on Dedicated Infrastructure用のメトリック(Exadata Cloud Infrastructureリファレンス・ガイドから)
- データベース管理サービスでのベース・データベース・サービスのメトリック: データベース管理メトリックを使用したデータベースのモニター
- 外部データベースのメトリック
- データベース管理 - データベース管理メトリックを参照してください
- データベース移行 - データベース移行メトリックを参照してください
- PostgreSQLを使用したOCIデータベース - PostgreSQLメトリックを使用したOCIデータベースを参照してください
- DevOps - DevOpsメトリックを参照してください
- デジタル・アシスタント - デジタル・アシスタント・メトリックを参照してください
- DNS - DNSメトリックを参照してください
- 電子メール配信 - 電子メール配信メトリックを参照してください
- イベント - イベント・メトリックを参照してください
- ファイル・ストレージ - ファイル・システム・メトリックを参照してください
- ファンクション - ファンクション・メトリックを参照してください
- グローバルに分散したAutonomous Database - Autonomous Databaseメトリックを使用したパフォーマンスのモニターを参照してください
- GoldenGate: Oracle Cloud Infrastructure GoldenGateメトリックを参照してください
- ヘルス・チェック - ヘルス・チェック・メトリックを参照してください
- 統合: 次のページを参照してください。
- 統合生成2: メッセージ・メトリックの表示
- 統合3: メッセージ・メトリックおよび請求可能メッセージの表示
- Java管理 - Java管理メトリックを参照してください
- ロード・バランサ - ロード・バランサ・メトリックを参照してください
- ロギング - ロギング・メトリックを参照してください
- ログ・アナリティクス - サービス・メトリックを使用したログ・アナリティクスのモニターを参照してください
- メディア・ストリーム - メディア・ストリーム・メトリックを参照してください
- 管理エージェント - 管理エージェント・メトリックを参照してください
- HeatWave - メトリックを参照してください
-
ネットワーキング - 次のページを参照してください:
- NoSQLデータベース・クラウド - サービス・メトリックを参照してください
- 通知 - 通知メトリックを参照してください
- ネットワーク・ファイアウォール - ネットワーク・ファイアウォール・メトリックを参照してください
- オブジェクト・ストレージ - オブジェクト・ストレージ・メトリックを参照してください
- Opsインサイト - オペレーション・インサイトのメトリックを参照してください
- Oracle APEX Application Development - APEXサービス・パフォーマンスのモニターを参照してください
- OS管理 - OS管理メトリックを参照してください
- OS管理ハブ - OS管理ハブ・メトリックを参照してください
- プロセス自動化 - プロセス自動化メトリックを参照してください
- キュー - キュー・メトリックを参照してください
- サービス・メッシュ - サービス・メッシュ・メトリックを参照してください
- スタック・モニタリング - スタック・モニタリング・メトリック・リファレンスを参照してください
- ストリーミング - ストリーミング・メトリックを参照してください
- ボールト - ボールト・リソースのモニタリングを参照してください
- 脆弱性スキャン: スキャン・メトリックを参照してください
- WAF - エッジ・ポリシー・メトリックを参照してください
リソース識別子
モニタリングにアクセスする方法
Oracle Cloud Infrastructure (OCI)には、コンソール(ブラウザベースのインタフェース)、REST APIまたはOCI CLIを使用してアクセスできます。 コンソール、APIおよびCLIの使用手順は、このドキュメント全体のトピックに記載されています。使用可能なSDKのリストは、ソフトウェア開発キットとコマンドライン・インタフェースを参照してください。
コンソール: コンソールを使用してモニタリングにアクセスするには、サポートされているブラウザを使用する必要があります。コンソールのサインイン・ページに移動するには、このページの上部にあるナビゲーション・メニューを開き、「Infrastructureコンソール」をクリックします。クラウド・テナント、ユーザー名およびパスワードの入力を求められます。ナビゲーション・メニューを開き、「監視および管理」をクリックします。「モニタリング」で、「サービス・メトリック」をクリックします。
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のメトリック・ストリームをトラッキングします。アラーム評価の詳細は、このページのアラーム評価を参照してください。
たとえば、トピックを宛先として使用して、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操作)を参照してください。
- ストリーム: ストリーミング・リソースの制限 を参照してください。
トラブルシューティングの制限
メトリック・ストリームが多すぎるという問合せエラーをトラブルシューティングするには、エラー: 最大メトリック・ストリーム数を超えましたを参照してください。
トラブルシューティング情報は、モニタリングのトラブルシューティングを参照してください。
セキュリティ
このトピックでは、モニタリングのセキュリティについて説明します。
セキュリティ情報や推奨事項など、モニタリングを保護する方法の詳細は、モニタリングの保護を参照してください。