- 重要な情報
- はじめに
- 用語集
- ガイド
- エージェント
- インテグレーション
- OpenTelemetry
- 開発者
- API
- CoScreen
- アプリ内
- Service Management
- インフラストラクチャー
- アプリケーションパフォーマンス
- 継続的インテグレーション
- ログ管理
- セキュリティ
- UX モニタリング
- 管理
メトリクスタイプは、メトリクスとそのエミッションソースで表す指標です。COUNT
および RATE
メトリクスタイプは、同じコンセプトである「経時的なメトリクス値の変化」を表すため、お互いとてもよく似ていますが、それぞれ異なるロジックを使用します。
RATE
: 正規化された値の経時的な変化(1秒ごと)。COUNT
: 特定の時間間隔における絶対値の変化。送信に適したメトリクスタイプは、使用例や送信方法によりそれぞれ異なります。たとえば、
送信されたメトリクスタイプ | 使用例 |
---|---|
RATE | 複数のホストにおいて受信したリクエストの数を経時的にモニターしたい場合。 |
RATE | ソースでの経時的なカウント送信の一貫性をコントロールできないため、アップストリームで比較できるように個々の間隔で正規化します。 |
COUNT | 関数が呼び出された回数をカウントしたい場合。 |
COUNT | 指定された期間内の収益を数える場合。 |
RATE
および COUNT
は同じメトリクスタイプではないため、Datadog のグラフおよびモニターにおける行動や形状が異なります。RATE
と COUNT
が表すメトリクスを調整するには、グラフやモニターで Datadog のアプリケーション内モディファイアー関数を使用します。
主要なアプリ内モディファイアーは as_count()
と as_rate()
の2つです。
モディファイアー | 説明 |
---|---|
as_count() | COUNT 形式で指定されたメトリクスを表示するのに必要な操作を設定し、rollup 間隔のメトリクス値の絶対変数を取得します。注: Rollup 間隔に依存するため、長めの間隔でグラフを作成するとグラフの形が変化します。 |
as_rate() | RATE 形式で指定されたメトリクスを表示するのに必要な操作を設定し、1秒あたりのメトリクス値の絶対変数を取得します。 |
適用したメトリクスタイプに応じて、動作は異なります。
as_count()
の効果SUM
に設定します。as_rate()
の効果SUM
に設定します。[1,1,1,1].as_rate()
を送信する次のポイントは、[0.05, 0.05, 0.05, 0.05]
を生成します。注: 間隔が短くて時間集計が発生しない場合、正規化は行われず、未加工のメトリクス値カウントが戻されます。
GAUGE
メトリクスタイプはメトリクスの絶対値と最終値を表します。as_count()
や as_rate()
モディファイアーは影響しません。
weighted()
pod name
や container_name
などのタグは、コスト管理、キャパシティプランニング、コンテナ型アプリケーションのオートスケーリングなどのクエリを作成する際に、特に高いタグ破棄率を引き起こします。タグ破棄率に関係なく、ゲージのクエリの数学的な正確さを保証するために、.weighted()
というアプリケーション内修飾子を使用できます。修飾子 .weighted()
により、Datadog はこれらの頻繁に破棄されるタグの寿命に基づいて、メトリクス値を適切に重み付けすることができるようになります。
以下の 2 つの条件が共に満たされる場合に限り、ゲージのクエリに .weighted()
修飾子が自動的に追加されます。
Datadog Agent またはインテグレーションのいずれかが、取り込み時にメトリクスの送信間隔を設定します。Metrics Summary ページで送信間隔を変更します。
通常は必要ありませんが、Metrics Summary ページでメトリクスのタイプを変更することができます。
使用例:
処理されたリクエスト数をカウントする app.requests.served
というメトリクスを、誤って StatsD から GAUGE
として送信しました。そのため、そのメトリクスの Datadog タイプは GAUGE
になっています。
時間集計のため、app.requests.served
は、StatsD の COUNT
メトリクスとして送信するつもりでした。そうすれば、「昨日処理されたリクエスト数の合計はいくつか」という質問には、sum:app.requests.served{*}
というクエリで答えることができます (GAUGE
メトリクスタイプでは意味がないクエリです)。
しかし、app.requests.served
という名前を引き続き使いたいので、適切な COUNT
タイプの新しいメトリクス名を送信するのではなく、app.requests.served
のタイプを変更することにしました。
dogstatsd.increment('app.requests.served', N)
を呼び出すように、送信コードを更新します。RATE
に更新します。この結果、app.requests.served
のタイプを変更する前に送信されたデータは、正しく動作しません。これは、アプリ内タイプ RATE
ではなく GAUGE
として解釈される形式で保存されているためです。手順 3 の後に送信されるデータは、正しく解釈されます。
GAUGE
として送信された履歴データを失いたくない場合は、app.requests.served
のタイプは変更せずに、適切なタイプの新しいメトリクス名を作成します。
注: Agent チェックの self.increment
は、単調増加カウンターの増分を計算するのではなく、チェック実行時に渡された値を報告します。単調増加カウンターの増分値を送信する場合は、self.monotonic_count
を使用してください。