

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

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

Application Signals 包含 CloudWatch 代理程式中的設定，可用來管理操作的基數和指標匯出，以最佳化成本。根據預設，對服務而言，當一段時間內不同操作的數量超過預設閾值 500 時，指標限制函式會變成作用中。您可以透過調整組態設定來調整行為。

## 判斷指標限制是否啟用
<a name="Limiting-Activated"></a>

可以使用下列方法來確定預設指標限制是否生效。如果是，應該考慮遵循下一節中的步驟，以最佳化基數控制。
+ 在 CloudWatch 主控台中，依次選擇 **Application Signals**、**服務**。如果您看到名為 **AllOtherOperations** 的 **Operation** 或名為 **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 代理程式，以重寫這些操作。

如果透過個別 `RemoteOperation` 呼叫產生許多不同的指標，例如 `PUT /api/customer/owners/123`、`PUT /api/customer/owners/456` 和類似的請求，建議您將這些操作合併到單一 `RemoteOperation`。其中一種方法是將所有以 `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
        }
      }
    }
  }
}
```