# 高カーディナリティ操作の管理
<a name="Application-Signals-Cardinality"></a>

Application Signals には、操作のカーディナリティを管理したり、コストを最適化するためにメトリクスのエクスポートを管理したりできる CloudWatch エージェントの設定が含まれています。デフォルトでは、あるサービスの個別操作の数がデフォルトのしきい値である 500 件を超えると、メトリクス制限機能が有効になります。構成設定を調整することで動作を調整できます。

## メトリクス制限が有効かどうかを確認する
<a name="Limiting-Activated"></a>

以下の方法を使用して、デフォルトのメトリクス制限が行われているかどうかを確認できます。行われている場合は、次のセクションのステップに従ってカーディナリティの制御の最適化を検討する必要があります。
+ CloudWatch コンソールで、**[Application Signals]**、**[サービス]** の順に選択します。**[AllOtherOperations]** という名前の **[操作]**、または **[AllOtherRemoteOperations]** という名前の **[RemoteOperation]** が表示される場合は、メトリクス制限が行われています。
+ Application Signals によって収集されたメトリクスのいずれかに `Operation` ディメンションの値「`AllOtherOperations`」がある場合、メトリクス制限が行われています。
+ Application Signals によって収集されたメトリクスのいずれかに `RemoteOperation` ディメンションの値「`AllOtherRemoteOperations`」がある場合、メトリクス制限が行われています。

### カーディナリティコントロールの最適化
<a name="Optimize-Cardinality"></a>

カーディナリティコントロールを最適化するには、以下を実行できます。
+ カスタムルールを作成して操作を集約します。
+ メトリクス制限ポリシーを設定します。

#### カスタムルールを作成して操作を集約する
<a name="Optimize-Cardinality-Custom-Rules"></a>

高カーディナリティ操作は、コンテキストから抽出された不適切な一意の値が原因で発生することがあります。例えば、ユーザー ID やセッション ID をパスに含む HTTP/S リクエストを送信すると、何百もの個別の操作が発生する可能性があります。このような問題を解決するには、CloudWatch エージェントにカスタマイズルールを設定して、これらの操作を書き換えることをお勧めします。

`PUT /api/customer/owners/123`、`PUT /api/customer/owners/456` などの個別の `RemoteOperation` 呼び出しで多数の異なるメトリクスの生成が急増している場合は、これらの操作を単一の `RemoteOperation` に統合することをおすすめします。1 つのアプローチは、`PUT /api/customer/owners/` で始まるすべての `RemoteOperation` 呼び出しを統一された形式 (具体的には `PUT /api/customer/owners/{ownerId}`) に標準化することです。以下に示しているのはこのポリシーの例です。その他のカスタマイズルールについては、「[CloudWatch Application Signals を有効にする](CloudWatch-Agent-Application_Signals.md)」を参照してください。

```
{
   "logs":{
      "metrics_collected":{
         "application_signals":{
            "rules":[
               {
                  "selectors":[
                     {
                        "dimension":"RemoteOperation",
                        "match":"PUT /api/customer/owners/*"
                     }
                  ],
                  "replacements":[
                     {
                        "target_dimension":"RemoteOperation",
                        "value":"PUT /api/customer/owners/{ownerId}"
                     }
                  ],
                  "action":"replace"
               }
            ]
         }
      }
   }
}
```

また、カーディナリティの高いメトリクスが `AllOtherRemoteOperations` に集約されていて、具体的にどのようなメトリクスが含まれているのか不明瞭な場合もあります。CloudWatch エージェントは、ドロップされた操作を記録できます。ドロップされた操作を特定するには、次の例の設定を使用して、問題が再発するまでログ記録を有効にします。次に、CloudWatch エージェントログ (コンテナ `stdout` または EC2 ログファイルからアクセス可能) を調べ、キーワード `drop metric data` を検索します。

```
{
  "agent": {
    "config": {
      "agent": {
        "debug": true
      },
      "traces": {
        "traces_collected": {
          "application_signals": {
          }
        }
      },
      "logs": {
        "metrics_collected": {
          "application_signals": {
            "limiter": {
              "log_dropped_metrics": true
            }
          }
        }
      }
    }
  }
}
```

#### メトリクス制限ポリシーを作成する
<a name="Optimize-Cardinality-Metric-Limiting"></a>

デフォルトのメトリクス制限設定がサービスのカーディナリティに対応していない場合は、メトリクス制限設定をカスタマイズできます。これを行うには、CloudWatch エージェント設定ファイルの `logs/metrics_collected/application_signals` セクション内に `limiter` セクションを追加します。

次の例では、メトリクス制限のしきい値を 500 個の個別メトリクスから 100 個に引き下げています。

```
{
  "logs": {
    "metrics_collected": {
      "application_signals": {
        "limiter": {
          "drop_threshold": 100
        }
      }
    }
  }
}
```