メトリクスタイプは、メトリクスとそのエミッションソースで表す指標です。COUNT および RATE メトリクスタイプは、同じコンセプトである「経時的なメトリクス値の変化」を表すため、お互いとてもよく似ていますが、それぞれ異なるロジックを使用します。

• RATE: 正規化された値の経時的な変化（1秒ごと）。
• COUNT: 特定の時間間隔における絶対値の変動。

使用例や送信方法に応じて、適したメトリクスタイプは異なる場合があります。例えば、

RATE および COUNT は同じメトリクスタイプではないため、Datadog のグラフおよびモニターにおける行動や形状が異なります。RATE と COUNT が表すメトリクスを調整するには、グラフやモニターで Datadog のアプリケーション内モディファイアー関数を使用します。

アプリ内モディファイアー

主要なアプリ内モディファイアーは as_count() と as_rate() の2つです。

適用したメトリクスタイプに応じて、動作は異なります。

修飾子 weighted()

pod name や container_name などのタグは、特にコスト管理、キャパシティプランニング、コンテナ型アプリケーションのオートスケーリングなどのクエリを作成する際に、高いタグ破棄率が発生します。タグ破棄率に関係なく、ゲージのクエリの数学的な正確さを保証するために、.weighted() というアプリケーション内修飾子を利用することができます。修飾子 .weighted() は、Datadog がこれらの頻繁に破棄されるタグの寿命に基づいて、メトリクス値を適切に重み付けすることを可能にします。

修飾子 .weighted() は、以下の両方の条件を満たす場合のみ、ゲージに関するクエリに自動的に付加されます。

• 隙間なく補間することができるように、ゲージメトリクスが定期的に送信されている。
• 送信間隔が正しく定義され、設定されている。

Datadog Agent またはインテグレーションのいずれかが、取り込み時にメトリクスの送信間隔を設定します。Metrics Summary ページで送信間隔を変更します。

Datadog 内でメトリクスのタイプを変更する

通常は必要ありませんが、Metrics Summary ページでメトリクスのタイプを変更することができます。

使用例:

1. 処理されたリクエスト数をカウントする app.requests.served というメトリクスを、誤って StatsD から GAUGE として送信しました。そのため、そのメトリクスの Datadog タイプは GAUGE になっています。

2. 時間集計のため、app.requests.served は、StatsD の COUNT メトリクスとして送信するつもりでした。そうすれば、「昨日処理されたリクエスト数の合計はいくつか」という質問には、sum:app.requests.served{*} というクエリで答えることができます (GAUGE メトリクスタイプでは意味がないクエリです)。

3. しかし、app.requests.served という名前を引き続き使いたいので、適切な COUNT タイプの新しいメトリクス名を送信するのではなく、app.requests.served のタイプを変更することにしました。

• N 個のリクエストが処理された後で dogstatsd.increment('app.requests.served', N) を呼び出すように、送信コードを更新します。
• メトリクスサマリーページから Datadog アプリ内タイプを RATE に更新します。

この結果、app.requests.served のタイプを変更する前に送信されたデータは、正しく動作しません。これは、アプリ内タイプ RATE ではなく GAUGE として解釈される形式で保存されているためです。手順 3 の後に送信されるデータは、正しく解釈されます。

GAUGE として送信された履歴データを失いたくない場合は、app.requests.served のタイプは変更せずに、適切なタイプの新しいメトリクス名を作成します。

注: Agent チェックの self.increment は、単調増加カウンターの増分を計算するのではなく、チェック実行時に渡された値を報告します。単調増加カウンターの増分値を送信する場合は、self.monotonic_count を使用してください。