# 管理高基数操作
<a name="Application-Signals-Cardinality"></a>

Application Signals 包括 CloudWatch 代理中的设置，您可以使用这些设置来管理操作的基数和管理指标导出，以优化成本。默认情况下，当服务的不同操作数随着时间的推移超过默认阈值 500 时，指标限制功能将变为活动状态。您可以通过调整配置设置来调整行为。

## 确定指标限制是否已激活
<a name="Limiting-Activated"></a>

您可以使用以下方法了解是否发生默认指标限制。如果是，应考虑执行下一节中的步骤，优化基数控制。
+ 在 CloudWatch 控制台中，依次选择 **Application Signals**、**服务**。如果您看到名为 **AllOtherOperations** 的**操作**或名为 **AllOtherRemoteOperations** 的**远程操作**，则表示发生指标限制。
+ 如果 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 代理，以重写这些操作。

如果通过单个 `RemoteOperation` 调用（例如 `PUT /api/customer/owners/123`、`PUT /api/customer/owners/456` 和类似的请求）生成大量不同的指标激增，则建议您将这些操作合并到一个 `RemoteOperation` 中。一种方法是将所有以 `PUT /api/customer/owners/` 开头的 `PUT /api/customer/owners/{ownerId}` 调用标准化为统一的格式，尤其是 `RemoteOperation`。以下示例对此进行了说明。有关其他自定义规则的信息，请参阅 [启用 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
        }
      }
    }
  }
}
```