重要

このページの日本語コンテンツは古くなっている可能性があります。最新の英語版コンテンツをご覧になるには、こちらをクリックしてください。

Confluent Cloud のメトリクス¶

Confluent Cloud のメトリクスは、サードパーティのモニタリングプロバイダーとの最高クラスの統合によって、または Confluent Cloud Metrics API を直接クエリすることで利用できます。Confluent Cloud のモニタリングを行うユーザーは、モニタリングに要する運用上の負荷を減らすために、統合を利用することが推奨されています。Confluent Cloud Metrics API は多様なクエリパターンのセットをサポートしていて、時間の経過に伴う使用状況とパフォーマンスの分析を行うことができます。

このページでは、Confluent Cloud が提供するメトリクスの利用を開始する方法について説明します。Confluent Cloud Metrics API の詳細については、API リファレンスを参照してください。

メトリクスのクイックスタート¶

前提条件

Confluent Cloud へのアクセス
インターネット接続。

注釈

Confluent Cloud RBAC MetricsViewer ロールでは、組織内のすべてのクラスターを対象に、Metrics API へのサービスアカウントアクセスが提供されます。また、このロールを割り当てられたサービスアカウントは、サードパーティのメトリクスプラットフォームにメトリクスをインポートすることもできます。詳細については、以下の「Confluent Cloud Console で MetricsViewer ロールを新しいサービスアカウントに追加する」を参照してください。

Metrics API への認証を受けるための Cloud API キーを作成します。その例を次に示します。

confluent login
confluent api-key create --resource cloud

注釈

Metrics API と通信するためには Cloud API キーの使用が "必須" です。Kafka との通信用の Cluster API キーを使用すると、認証エラーになります。

参考

Apache Kafka® クライアントアプリケーションおよび Confluent Cloud メトリクスをモニタリングする方法の例と、さまざまな失敗のシナリオに対応してメトリクスの結果を表示する手順については、Confluent Cloud に接続する Apache Kafka® クライアント用の Observability のデモを参照してください。

Confluent Cloud Console で MetricsViewer ロールを新しいサービスアカウントに追加する¶

MetricsViewer ロールでは、組織内のすべてのクラスターを対象に、Metrics API へのサービスアカウントアクセスが提供されます。また、このロールを割り当てられたサービスアカウントは、サードパーティのメトリクスプラットフォームにメトリクスをインポートすることもできます。

MetricsViewer ロールを新しいサービスアカウントに割り当てるには、次のようにします。

In the top-right administration menu (☰) in the upper-right corner of the Confluent Cloud user interface, click ADMINISTRATION > Cloud API keys.
Add key をクリックします。
Granular access タイルをクリックし、API キーの範囲を設定します。Next をクリックします。
Create a new one をクリックし、サービスアカウント名と、オプションで説明を指定します。Next をクリックします。
API キーとシークレットがサービスアカウントに対して生成されます。クラスターに接続するには、この API キーとシークレットが必要になるため、必ずこの情報を安全な場所に保管してください。Save をクリックします。新規サービスアカウントと API キー、および関連付けられた ACL が作成されます。API access タブで、新しく作成した API キーを表示して確認できます。
右上の管理メニューの Accounts & access に戻り、Accounts の下の Service accounts タブをクリックして、すべてのサービスアカウントを表示します。MetricsViewer ロールを追加するサービスアカウントを選択して、Access タブをクリックします。
Add role assignment をクリックし、MetricsViewer タイルを選択します。Save をクリックします。

Accounts & access で、組織のリソースを表示できます。また、作成したサービスアカウントに MetricsViewer ロールバインディングがあることが確認できます。

CLI を使用して MetricsViewer ロールをサービスアカウントに追加する¶

次のコマンドを実行して、MetricsViewer のロールバインディングを新しいサービスアカウントに追加します。最初に confluent login コマンドを使用してログインしてください。

サービスアカウントを作成します。

confluent iam service-account create MetricsImporter --description "A test service account to import Confluent Cloud metrics into our monitoring system"

出力は以下のようになります。

+-------------+--------------------------------+
| ID          | sa-123abc                      |
| Name        | MetricsImporter                |
| Description | A test service account to      |
|             | import Confluent Cloud metrics |
|             | into our monitoring system     |
+-------------+--------------------------------+

ID フィールドをメモします。

MetricsViewer ロールバインディングをサービスアカウントに追加します。

confluent iam rbac role-binding create --role MetricsViewer --principal User:sa-123abc

出力は以下のようになります。

+-----------+----------------+
| Principal | User:sa-123abc |
| Role      | MetricsViewer  |
+-----------+----------------+

ロールバインディングのリストを表示し、MetricViewer ロールが作成されたことを確認します。

confluent iam rbac role-binding list --principal User:sa-123abc

出力は以下のようになります。

    Principal    | Email |     Role      | Environment | ...
-----------------+-------+---------------+-------------+----
  User:sa-123abc |       | MetricsViewer |             |

既存のサービスアカウントのリストを表示します。

confluent iam service-account list

出力は以下のようになります。

     ID     |              Name              |           Description
------------+--------------------------------+-----------------------------------
  sa-1a2b3c | test-account                   | for testing
  sa-112233 | ProactiveSupport.1614189731753 | SA for Proactive Support
  sa-aabbcc | KSQL.lksqlc-ab123              | SA for KSQL w/ ID lksqlc-ab123
            |                                | and Name ksqlDB_app_0
  ...

API キーを作成し、新しいサービスアカウントに追加します。

confluent api-key create --resource cloud --service-account sa-123abc

出力は以下のようになります。

It may take a couple of minutes for the API key to be ready.
Save the API key and secret. The secret is not retrievable later.
+---------+------------------------------------------------------------------+
| API Key | 1234567ABCDEFGHI                                                 |
| Secret  | ABCDEF123456.................................................... |
+---------+------------------------------------------------------------------+

API キーとシークレットをセキュアな場所に保管します。

サードパーティのモニタリングとの統合¶

サードパーティのモニタリングツールと直接統合すると、Confluent Cloud を他のアプリケーションと並行してモニタリングすることができます。

Datadog¶

Datadog と統合を行うと、ユーザーが Cloud API キーを Datadog UI に入力し、モニタリング対象のリソースを選択すれば、すぐに利用開始できるダッシュボードでわずか数分でメトリクスを確認できます。Datadog の使用を開始するには Cloud API キーを作成して、Datadog の手順に従います。

Dynatrace¶

Dynatrace provides an extension where users can input a Cloud API key into the Dynatrace Monitoring Configuration, select resources to monitor, and see metrics in minutes in a prebuilt dashboard. If you use Dynatrace, create your Cloud API key and follow the instructions to get started.

Grafana Cloud¶

Grafana Labs と統合を行うと、ユーザーが Cloud API キーを Grafana Cloud UI に入力し、モニタリング対象のリソースを選択すれば、すぐに利用開始できるダッシュボードでわずか数分でメトリクスを確認できます。Grafana Cloud の使用を開始するには Cloud API キーを作成して手順に従います。

Prometheus¶

Prometheus サーバーは、export エンドポイントを使用して Confluent Cloud Metrics API を直接スクレイピングできます。このエンドポイントは、ラベルの組み合わせごとに、各メトリックの単一の最新データポイントを Prometheus exposition フォーマットまたは Open Metrics フォーマットで返します。詳細については、「Export metric values」を参照してください。

Metrics API を使用した検出¶

以下の例では、cURL ではなく HTTPie を使用しています。このソフトウェアパッケージでは、最も一般的に利用されているソフトウェアパッケージマネージャーをインストールできます（こちらのドキュメントを参照)。

Confluent Cloud Metrics API を使用して、エンドポイントは、使用可能なリソースとそのメトリクスをプログラムにより検出できます。このリソースとメトリックのメタデータは、descriptor オブジェクトで表現されます。

検出エンドポイントを使って、クライアントのスクリプトにメトリック名とリソース名をハードコードすることを回避できます。

使用可能なメトリクスをリスト表示する¶

リソースは、メトリクスを収集できる対象を表します。たとえば、Kafka クラスター、Kafka コネクター、ksqlDB アプリケーションなどです。

API の descriptors エンドポイントに GET リクエストを送信して、使用可能なメトリクスの説明を取得します。

http 'https://api.telemetry.confluent.cloud/v2/metrics/cloud/descriptors/resources' --auth '<API_KEY>:<SECRET>'

これによって、クエリ可能なリソースとそのラベルが記載された JSON ドキュメントが返されます。

使用可能なメトリクスをリスト表示する¶

API の descriptors エンドポイントに GET リクエストを送信して、使用可能なメトリクスの説明を取得します。

http 'https://api.telemetry.confluent.cloud/v2/metrics/cloud/descriptors/metrics?resource_type=kafka' --auth '<API_KEY>:<SECRET>'

注釈

メトリクスを表示するリソースのタイプを指定するには、resource_type クエリパラメーターが必要です。有効なリソースタイプは、/descriptors/resources エンドポイントを使用して確認できます。

これによって、クエリ可能なメトリクスの詳細を含む JSON BLOB が返されます。現在使用可能なメトリクスのリストは以下のとおりです。

人が読める形式の、現在のメトリクスのリストについては、API リファレンスを参照してください。

クエリの例¶

Confluent Cloud Metrics API には、時系列データを柔軟にフィルタリングしたりグループ化したりできる、表現力豊かなクエリ言語があります。クエリのサンプルがテンプレートとして提供されています。サンプルはさらに Cloud Console 内にもあり、これらも Confluent Cloud Metrics API を使用します。

1 分あたりトピック別にグループ化してコンシューマーに送信されたバイトのクエリ¶

以下のテンプレートを使用して、sent_bytes_query.json という名前のファイルを作成します。lkc-XXXXX とタイムスタンプ値は、必要に応じて変更します。

{
  "aggregations": [
    {
      "metric": "io.confluent.kafka.server/sent_bytes"
    }
  ],
  "filter": {
    "field": "resource.kafka.id",
    "op": "EQ",
    "value": "lkc-XXXXX"
  },
  "granularity": "PT1M",
  "group_by": [
    "metric.topic"
  ],
  "intervals": [
    "2019-12-19T11:00:00-05:00/2019-12-19T11:05:00-05:00"
  ],
  "limit": 25
}

次のコマンドを使用して、クエリを POST として送信します。API_KEY と SECRET は、環境に合わせて変更します。

http 'https://api.telemetry.confluent.cloud/v2/metrics/cloud/query' --auth '<API_KEY>:<SECRET>' < sent_bytes_query.json

出力は以下のようになります。

{
  "data": [
    {
      "timestamp": "2019-12-19T16:01:00Z",
      "metric.topic": "test-topic",
      "value": 0.0
    },
    {
      "timestamp": "2019-12-19T16:02:00Z",
      "metric.topic": "test-topic",
      "value": 157.0
    },
    {
      "timestamp": "2019-12-19T16:03:00Z",
      "metric.topic": "test-topic",
      "value": 371.0
    },
    {
      "timestamp": "2019-12-19T16:04:00Z",
      "metric.topic": "test-topic",
      "value": 0.0
    }
  ]
}

注釈

時間ウィンドウ内にデータを生成しなかった場合、特定のトピックのデータセットが空になります。

1 分あたりトピック別にグループ化してプロデューサーから送信されたバイトのクエリ¶

以下のテンプレートを使用して、received_bytes_query.json という名前のファイルを作成します。lkc-XXXXX およびタイムスタンプ値は、必要に応じて変更します。

{
  "aggregations": [
    {
      "metric": "io.confluent.kafka.server/received_bytes"
    }
  ],
  "filter": {
    "field": "resource.kafka.id",
    "op": "EQ",
    "value": "lkc-XXXXX"
  },
  "granularity": "PT1M",
  "group_by": [
    "metric.topic"
  ],
  "intervals": [
    "2019-12-19T11:00:00-05:00/2019-12-19T11:05:00-05:00"
  ],
  "limit": 25
}

次のコマンドを使用して、クエリを POST として送信します。API_KEY と SECRET は、環境に合わせて変更します。

http 'https://api.telemetry.confluent.cloud/v2/metrics/cloud/query' --auth '<API_KEY>:<SECRET>' < received_bytes_query.json

出力は以下のようになります。

{
  "data": [
    {
      "timestamp": "2019-12-19T16:00:00Z",
      "metric.topic": "test-topic",
      "value": 72.0
    },
    {
      "timestamp": "2019-12-19T16:01:00Z",
      "metric.topic": "test-topic",
      "value": 139.0
    },
    {
      "timestamp": "2019-12-19T16:02:00Z",
      "metric.topic": "test-topic",
      "value": 232.0
    },
    {
      "timestamp": "2019-12-19T16:03:00Z",
      "metric.topic": "test-topic",
      "value": 0.0
    },
    {
      "timestamp": "2019-12-19T16:04:00Z",
      "metric.topic": "test-topic",
      "value": 0.0
    }
  ]
}

注釈

時間ウィンドウ内にデータを生成しなかった場合、特定のトピックのデータセットが空になります。

クラスター lkc-XXXX で 2 時間以上保持された最大保持バイト数/時を照会するクエリ¶

以下のテンプレートを使用して、cluster_retained_bytes_query.json という名前のファイルを作成します。lkc-XXXXX およびタイムスタンプ値は、必要に応じて変更します。

{
  "aggregations": [
    {
      "metric": "io.confluent.kafka.server/retained_bytes"
    }
  ],
  "filter": {
    "field": "resource.kafka.id",
    "op": "EQ",
    "value": "lkc-XXXXX"
  },
  "granularity": "PT1H",
  "intervals": [
    "2019-12-19T11:00:00-05:00/P0Y0M0DT2H0M0S"
  ],
  "limit": 5
}

次のコマンドを使用して、クエリを POST として送信します。API_KEY と SECRET は、環境に合わせて変更します。

http 'https://api.telemetry.confluent.cloud/v2/metrics/cloud/query' --auth '<API_KEY>:<SECRET>' < cluster_retained_bytes_query.json

出力は以下のようになります。

{
  "data": [
    {
      "timestamp": "2019-12-19T16:00:00Z",
      "value": 507350.0
    },
    {
      "timestamp": "2019-12-19T17:00:00Z",
      "value": 507350.0
    }
  ]
}

トピックおよびコンシューマーグループでグループ分けされた、過去 1 時間の平均コンシューマーラグのクエリ¶

以下のテンプレートを使用して、consumer_lag_max_hour.json という名前のファイルを作成します。必ず lkc-XXXXX を変更してください。また間隔は 1 分間隔で、過去 1 時間に対するものです。

{
  "aggregations": [
    {
      "metric": "io.confluent.kafka.server/consumer_lag_offsets"
    }
  ],
  "filter": {
    "field": "resource.kafka.id",
    "op": "EQ",
    "value": "lkc-XXXXX"
  },
  "granularity": "PT1H",
  "group_by": [
    "metric.consumer_group_id",
    "metric.topic"
  ],
  "intervals": [
    "PT1M/now"
  ],
  "limit": 25
}

次のコマンドを使用して、クエリを POST として送信します。API_KEY と SECRET は、環境に合わせて変更します。

http 'https://api.telemetry.confluent.cloud/v2/metrics/cloud/query' --auth '<API_KEY>:<SECRET>' < consumer_lag_max_hour.json

出力は以下のようになります。

{
  "data": [
    {
      "metric.consumer_group_id": "group_1",
      "metric.topic": "test_topic_1",
      "timestamp": "2022-03-23T21:00:00Z",
      "value": 0.0
    },
    {
      "metric.consumer_group_id": "group_2",
      "metric.topic": "test_topic_2",
      "timestamp": "2022-03-23T21:00:00Z",
      "value": 6.0
    }
  ]
}

ksqlDB クラスター `lksqlc-XXXXX` について、使用されたストリーミングユニット数/時間に対するクエリ¶

以下のテンプレートを使用して、cluster_retained_bytes_query.json という名前のファイルを作成します。lkc-XXXXX およびタイムスタンプ値は、必要に応じて変更します。

{
  "aggregations": [
    {
      "metric": "io.confluent.kafka.ksql/streaming_unit_count"
    }
  ],
  "filter": {
    "field": "resource.ksql.id",
    "op": "EQ",
    "value": "lksqlc-XXXXX"
  },
  "granularity": "PT1H",
  "intervals": [
    "2021-02-24T10:00:00Z/2021-02-24T11:00:00Z"
  ],
  "group_by": [
    "resource.ksql.id"
  ]
}

次のコマンドを使用して、クエリを POST として送信します。API_KEY と SECRET は、環境に合わせて変更します。

http 'https://api.telemetry.confluent.cloud/v2/metrics/cloud/query' --auth '<API_KEY>:<SECRET>' < ksql_streaming_unit_count.json

出力は以下のようになります。

{
  "data": [
    {
      "resource.ksql.id": "lksqlc-XXXXX",
      "timestamp": "2021-02-24T10:00:00Z",
      "value": 4.0
    }
  ]
}

ksqlDB クラスター `lksqlc-XXXXX` のすべての CSU で使用されているストレージの最大容量（%）に対するクエリ¶

次のテンプレートを使用して ksql_storage_utilization.json という名前のファイルを作成します。lksqlc-XXXXX とタイムスタンプの値は、必要に応じて変更します。

{
  "aggregations": [
    {
      "metric": "io.confluent.kafka.ksql/storage_utilization"
    }
  ],
  "filter": {
    "field": "resource.ksql.id",
    "op": "EQ",
    "value": "lksqlc-xxxxx"
  },
  "granularity": "PT1M",
  "intervals": [
    "2021-02-24T10:00:00Z/2021-02-24T11:00:00Z"
  ]
}

次のコマンドを使用して、クエリを POST として送信します。API_KEY と SECRET は、環境に合わせて変更します。

http 'https://api.telemetry.confluent.cloud/v2/metrics/cloud/query' --auth '<API_KEY>:<SECRET>' < ksql_storage_utilization.json

出力は以下のようになります。

{
  "data": [
    {
      "resource.ksql.id": "lksqlc-XXXXX",
      "timestamp": "2021-02-24T10:00:00Z",
      "value": 0.85
    }
  ]
}

ksqlDB クラスター `lksqlc-XXXXX` でクエリによって使用される ksqlDB ストレージのバイト数に対するクエリ¶

次のテンプレートを使用して ksql_query_storage.json という名前のファイルを作成します。lksqlc-XXXXX とタイムスタンプの値は、必要に応じて変更します。

{
  "aggregations": [
    {
      "metric": "io.confluent.kafka.ksql/task_stored_bytes"
    }
  ],
  "filter": {
    "field": "resource.ksql.id",
    "op": "EQ",
    "value": "lksqlc-xxxxx"
  },
  "granularity": "PT1M",
  "group_by": [
    "metric.query_id"
  ],
  "intervals": [
    "2021-02-24T10:00:00Z/2021-02-24T11:00:00Z"
  ]
}

次のコマンドを使用して、クエリを POST として送信します。API_KEY と SECRET は、環境に合わせて変更します。

http 'https://api.telemetry.confluent.cloud/v2/metrics/cloud/query' --auth '<API_KEY>:<SECRET>' < ksql_query_storage.json

出力は以下のようになります。

{
  "data": [
    {
      "resource.ksql.id": "lksqlc-XXXXX",
      "metric.query_id": "CTAS_PAGEVIEWS_2",
      "timestamp": "2021-02-24T10:00:00Z",
      "value": 7688174488
    }
  ]
}

ksqlDB クラスター `lksqlc-XXXXX` でタスクによって使用されるストレージのバイト数に対するクエリ¶

次のテンプレートを使用して ksql_task_storage.json という名前のファイルを作成します。lksqlc-XXXXX とタイムスタンプの値は、必要に応じて変更します。

{
  "aggregations": [
    {
      "metric": "io.confluent.kafka.ksql/task_stored_bytes"
    }
  ],
  "filter": {
    "field": "resource.ksql.id",
    "op": "EQ",
    "value": "lksqlc-xxxxx"
  },
  "granularity": "PT1M",
  "group_by": [
    "metric.query_id",
    "metric.task_id"
  ],
  "intervals": [
    "2021-02-24T10:00:00Z/2021-02-24T11:00:00Z"
  ]
}

次のコマンドを使用して、クエリを POST として送信します。API_KEY と SECRET は、環境に合わせて変更します。

http 'https://api.telemetry.confluent.cloud/v2/metrics/cloud/query' --auth '<API_KEY>:<SECRET>' < ksql_task_storage.json

出力は以下のようになります。

{
  "data": [
    {
      "resource.ksql.id": "lksqlc-XXXXX",
      "metric.task_id": "1_1",
      "metric.query_id": "CTAS_PAGEVIEWS_2",
      "timestamp": "2021-02-24T10:00:00Z",
      "value": 1079295760
    }
  ]
}

ksqlDB クラスター `lksqlc-XXXXX` のクエリ飽和に対するクエリ¶

次のテンプレートを使用して ksql_query_saturation.json という名前のファイルを作成します。lksqlc-XXXXX とタイムスタンプの値は、必要に応じて変更します。

{
  "aggregations": [
    {
      "metric": "io.confluent.kafka.ksql/query_saturation"
    }
  ],
  "filter": {
    "field": "resource.ksql.id",
    "op": "EQ",
    "value": "lksqlc-xxxxx"
  },
  "granularity": "PT1M",
  "intervals": [
    "2021-02-24T10:00:00Z/2021-02-24T11:00:00Z"
  ]
}

次のコマンドを使用して、クエリを POST として送信します。API_KEY と SECRET は、環境に合わせて変更します。

http 'https://api.telemetry.confluent.cloud/v2/metrics/cloud/query' --auth '<API_KEY>:<SECRET>' < ksql_query_saturation.json

出力は以下のようになります。

{
  "data": [
    {
      "resource.ksql.id": "lksqlc-XXXXX",
      "timestamp": "2021-02-24T10:00:00Z",
      "value": 0.85
    }
  ]
}

スキーマレジストリクラスター `lsrc-XXXXX` のスキーマ数に対するクエリ¶

以下のテンプレートを使用して、sent_bytes_query.json という名前のファイルを作成します。lkc-XXXXX とタイムスタンプ値は、必要に応じて変更します。

{
  "aggregations": [
    {
      "metric": "io.confluent.kafka.schema_registry/schema_count"
    }
  ],
  "filter": {
    "field": "resource.schema_registry.id",
    "op": "EQ",
    "value": "lsrc-XXXXX"
  },
  "granularity": "PT1M",
  "intervals": [
    "2021-02-24T10:00:00Z/2021-02-24T10:01:00Z"
  ],
  "group_by": [
    "resource.schema_registry.id"
  ]
}

次のコマンドを使用して、クエリを POST として送信します。API_KEY と SECRET は、環境に合わせて変更します。

http 'https://api.telemetry.confluent.cloud/v2/metrics/cloud/query' --auth '<API_KEY>:<SECRET>' < schema_count.json

出力は以下のようになります。

{
  "data": [
    {
      "resource.schema_registry.id": "lsrc-XXXXX",
      "timestamp": "2021-02-24T10:00:00Z",
      "value": 1.0
    }
  ]
}

シンクコネクター `lcc-XXXXX` によって受信された 1 時間あたりのレコード数に対するクエリ¶

以下のテンプレートを使用して、sent_bytes_query.json という名前のファイルを作成します。lkc-XXXXX とタイムスタンプ値は、必要に応じて変更します。

{
  "aggregations": [
    {
      "metric": "io.confluent.kafka.connect/received_records"
    }
  ],
  "filter": {
    "field": "resource.connector.id",
    "op": "EQ",
    "value": "lcc-XXXXX"
  },
  "granularity": "PT1H",
  "intervals": [
    "2021-02-24T10:00:00Z/2021-02-24T11:00:00Z"
  ],
  "group_by": [
    "resource.connector.id"
  ]
}

次のコマンドを使用して、クエリを POST として送信します。API_KEY と SECRET は、環境に合わせて変更します。

http 'https://api.telemetry.confluent.cloud/v2/metrics/cloud/query' --auth '<API_KEY>:<SECRET>' < sink_connector_records.json

出力は以下のようになります。

{
  "data": [
    {
      "resource.connector.id": "lcc-XXXXX",
      "timestamp": "2021-02-24T10:00:00Z",
      "value": 26455991.0
    }
  ]
}

特定のプリンシパル ID のメトリクスのクエリ¶

metric.principal_id ラベルを使用して、特定のユーザーまたはサービスアカウントごとにメトリクスをフィルターできます。メトリクス io.confluent.kafka.server/active_connection_count や io.confluent.kafka.server/request_count などが metric.principal_id ラベルによるフィルタリングをサポートしています。現在このラベルをサポートしているすべてのメトリクスについては、API リファレンスを参照してください。

次のテンプレートを使用して、principal_query.json という名前のファイルを作成します。lkc-XXXXX とタイムスタンプの値は、必要に応じて変更します。

{
  "aggregations": [
    {
      "metric": "io.confluent.kafka.server/active_connection_count"
    }
  ],
  "filter": {
    "field": "resource.kafka.id",
    "op": "EQ",
    "value": "lkc-XXXXX"
  },
  "granularity": "PT1H",
  "group_by": [
    "metric.principal_id"
  ],
  "intervals": [
    "2022-01-01T00:00:00Z/PT1H"
  ],
  "limit": 5
}

次のコマンドを使用して、クエリを POST として送信します。API_KEY と SECRET は、環境に合わせて変更します。

http 'https://api.telemetry.confluent.cloud/v2/metrics/cloud/query' --auth '<API_KEY>:<SECRET>' < principal_query.json

出力は以下のようになります。

{
  "data": [
    {
      "metric.principal_id": "sa-abc123",
      "timestamp": "2022-01-01T00:00:00Z",
      "value": 430.99999999997
    },
    {
      "metric.principal_id": "u-def456",
      "timestamp": "2022-01-01T00:00:00Z",
      "value": 427.93333333332
    },
    {
      "metric.principal_id": "u-abc123",
      "timestamp": "2022-01-01T00:00:00Z",
      "value": 333.19999999997
    }
  ],
  "meta": {
    "pagination": {
      "next_page_token": "eyJ2ZXJzaW9uIjoiMSIsInJlcXVlc3RI",
      "page_size": 5
    }
  }

注釈

指定した間隔内に報告されたメトリック値が存在しないトピックは返されません。

FAQ¶

Metrics API を請求書の照合の使用可能の有無¶

いいえ、できません。Metrics API は、モニタリング、トラブルシューティング、キャパシティプラニングを目的として情報を提供するものです。現時点ではメトリクスには Kafka プロトコルのリクエストのオーバーヘッドが含まれていないので、請求書を照合する監査システムとして使用することはできません。詳細については、請求についてのドキュメントを参照してください。

`retained_bytes` 以外に、クエリに存在するトピックのデータセットが空になる¶

クエリを実行した時間範囲に 0.0 の値しかない場合は、API から空のデータセットが返されます。該当する時間範囲にゼロ以外のデータがある場合は、0.0 の値の時間スライスが返されます。

トピックの保持ポリシーを変更した後に、`retained_bytes` が減らなかった¶

retained_bytes の値は、各データポイントで表される間隔における最大値として計算されます。現行の間隔の中でデータが削除されても、その結果は次の時間範囲ウィンドウが始まるまで表に現れません。たとえば、過去 30 日間にわたって 1 日あたり 4 GB のデータを生成していた場合に、1 日間隔を指定して過去 3 日間の retained_bytes を照会すると、クエリから返される時系列の値は 112 GB、116 GB、120 GB となります。その後に、そのトピックのデータをすべて削除してデータの生成を停止しても、クエリから返される値は翌日まで同じです。翌日の最初にクエリを実行すると、同じクエリから 116 GB、120 GB、0 GB が返されます。

サポートされる単位について¶

データは 1 分間隔で保管されます。ただし、クエリ可能な単位は、クエリ間隔の長さによって制限されます。現在サポートされる単位とクエリの制限については、API リファレンスを参照してください。

コンシューマーラグはどのようにモニタリングすればよいですか。¶

Metrics API を使用して、平均コンシューマーラグのクエリを実行します。
また、クライアントのメトリクス、UI、CLI、Admin API などの他の方法でコンシューマーラグをモニタリングすることもできます。Confluent Cloud を使用する場合は、これらの方法をすべて使用可能です。

Metrics API のメトリクスの保持期間について¶

メトリクスは 7 日間保持されます。

特定のメトリクスがプレビュー版と一般提供（GA）版のどちらであるか、どうすればわかりますか。¶

Confluent は、新しいメトリクスを追加するため常に模索しています。ただし、新しいメトリクスを追加する際、安定化させる方法を公開するにはほとんどのユースケースに適していると確認するのに多少時間がかかります。/descriptors エンドポイントからの応答に、各メトリクスのライフサイクル段階（preview、generally available など）が含まれています。preview 段階のメトリクスは、API バージョンを変更することなく、その特性に対して重大な変更が加えられる可能性があります。プレビュー版では、可能な限り最高のエクスペリエンスを提供するために、何度も変更が繰り返されます。

Metrics API へのクエリでタイムアウト応答（HTTP エラーコード 504）が返された場合について¶

クエリがタイムアウト（最大クエリ時間は 60 秒）を超えた場合は、次の 2 つの方法のうちどちらかを実行することをお勧めします。

時間間隔を短くします。
返されるデータの単位を小さくします。
より少ないデータポイントが返されるように、クライアント側でクエリを分割します。たとえば、一度にすべてのトピックに対してクエリを実行するのではなく、特定のトピックを照会したり、時間間隔を短くすることもできます。

これらの方法は、パーティションレベルのデータに対して何日間にもわたる間隔でクエリを実行する場合に特に重要です。

Confluent Cloud メトリクスが 1 時間/6 時間/24 時間あたりのデータでのみ表示される理由¶

これは既知の制限であり、2,000 を超えるパーティションのある一部のクラスターで発生します。現在、この問題に取り組んでいますが、現時点では修正はありません。

クエリで 5xx 応答コードが返された場合について¶

Confluent は、このようなタイプの応答には再試行を行うことを推奨してきました。通常、これはサーバー側の一過性の問題を示しています。Metrics API に対してクエリを実行するためのクライアントの実装は、このようなタイプの応答に数分間対応できるように設計する必要があります。

Confluent Cloud のメトリクス¶

メトリクスのクイックスタート¶

Confluent Cloud Console で MetricsViewer ロールを新しいサービスアカウントに追加する¶

CLI を使用して MetricsViewer ロールをサービスアカウントに追加する¶

サードパーティのモニタリングとの統合¶

Datadog¶

Dynatrace¶

Grafana Cloud¶

Prometheus¶

Metrics API を使用した検出¶

使用可能なメトリクスをリスト表示する¶

使用可能なメトリクスをリスト表示する¶

クエリの例¶

1 分あたりトピック別にグループ化してコンシューマーに送信されたバイトのクエリ¶

1 分あたりトピック別にグループ化してプロデューサーから送信されたバイトのクエリ¶

クラスター lkc-XXXX で 2 時間以上保持された最大保持バイト数/時を照会するクエリ¶

トピックおよびコンシューマーグループでグループ分けされた、過去 1 時間の平均コンシューマーラグのクエリ¶

ksqlDB クラスター lksqlc-XXXXX について、使用されたストリーミングユニット数/時間に対するクエリ¶

ksqlDB クラスター lksqlc-XXXXX のすべての CSU で使用されているストレージの最大容量（%）に対するクエリ¶

ksqlDB クラスター lksqlc-XXXXX でクエリによって使用される ksqlDB ストレージのバイト数に対するクエリ¶

ksqlDB クラスター lksqlc-XXXXX でタスクによって使用されるストレージのバイト数に対するクエリ¶

ksqlDB クラスター lksqlc-XXXXX のクエリ飽和に対するクエリ¶

スキーマレジストリクラスター lsrc-XXXXX のスキーマ数に対するクエリ¶

シンクコネクター lcc-XXXXX によって受信された 1 時間あたりのレコード数に対するクエリ¶

特定のプリンシパル ID のメトリクスのクエリ¶

FAQ¶

Metrics API を請求書の照合の使用可能の有無¶

retained_bytes 以外に、クエリに存在するトピックのデータセットが空になる¶

トピックの保持ポリシーを変更した後に、retained_bytes が減らなかった¶

サポートされる単位について¶

コンシューマーラグはどのようにモニタリングすればよいですか。¶

Metrics API のメトリクスの保持期間について¶

特定のメトリクスがプレビュー版と一般提供（GA）版のどちらであるか、どうすればわかりますか。¶

Metrics API へのクエリでタイムアウト応答（HTTP エラーコード 504）が返された場合について¶

Confluent Cloud メトリクスが 1 時間/6 時間/24 時間あたりのデータでのみ表示される理由¶

クエリで 5xx 応答コードが返された場合について¶

おすすめのリソース¶

ksqlDB クラスター `lksqlc-XXXXX` について、使用されたストリーミングユニット数/時間に対するクエリ¶

ksqlDB クラスター `lksqlc-XXXXX` のすべての CSU で使用されているストレージの最大容量（%）に対するクエリ¶

ksqlDB クラスター `lksqlc-XXXXX` でクエリによって使用される ksqlDB ストレージのバイト数に対するクエリ¶

ksqlDB クラスター `lksqlc-XXXXX` でタスクによって使用されるストレージのバイト数に対するクエリ¶

ksqlDB クラスター `lksqlc-XXXXX` のクエリ飽和に対するクエリ¶

スキーマレジストリクラスター `lsrc-XXXXX` のスキーマ数に対するクエリ¶

シンクコネクター `lcc-XXXXX` によって受信された 1 時間あたりのレコード数に対するクエリ¶

`retained_bytes` 以外に、クエリに存在するトピックのデータセットが空になる¶

トピックの保持ポリシーを変更した後に、`retained_bytes` が減らなかった¶