# Gerenciamento de operações de alta cardinalidade
<a name="Application-Signals-Cardinality"></a>

O Application Signals inclui configurações no agente do CloudWatch que podem ser usadas para gerenciar a cardinalidade das operações e administrar a exportação de métricas para otimizar custos. Por padrão, a função de limitação de métricas torna-se ativa quando o número de operações distintas para um serviço ao longo do tempo excede o limite padrão de 500. É possível ajustar o comportamento ao adaptar as definições de configuração. 

## Como determinar se a limitação de métricas está ativada
<a name="Limiting-Activated"></a>

É possível usar os métodos apresentados a seguir para descobrir se a limitação de métricas padrão está ocorrendo. Se a limitação estiver ativada, considere otimizar o controle de cardinalidade ao seguir as etapas da próxima seção.
+ No console do CloudWatch, escolha **Application Signals** e, em seguida, selecione **Serviços**. Se você vir uma dimensão **Operation** chamada **AllOtherOperations** ou uma dimensão **RemoteOperation** chamada **AllOtherRemoteOperations**, a limitação de métricas estará ocorrendo.
+ Se alguma métrica coletada pelo Application Signals tiver o valor `AllOtherOperations` para a dimensão `Operation`, a limitação de métricas estará ocorrendo.
+ Se alguma métrica coletada pelo Application Signals tiver o valor `AllOtherRemoteOperations` para a dimensão `RemoteOperation`, a limitação de métricas estará ocorrendo.

### Como otimizar o controle de cardinalidade
<a name="Optimize-Cardinality"></a>

Para otimizar o controle de cardinalidade, é possível fazer o seguinte:
+ Criar regras personalizadas para agregar operações.
+ Configurar a política de limitação de métricas.

#### Criar regras personalizadas para agregar operações
<a name="Optimize-Cardinality-Custom-Rules"></a>

Às vezes, as operações de alta cardinalidade podem ser causadas por valores exclusivos inadequados que foram extraídos do contexto. Por exemplo, o envio de solicitações HTTP/S que incluem IDs de usuário ou IDs de sessão no caminho pode resultar em centenas de operações diferentes. Para resolver esses problemas, recomendamos configurar o agente do CloudWatch com regras de personalização para gravar novamente essas operações.

Nos casos em que há um aumento na geração de inúmeras métricas diferentes por meio de chamadas `RemoteOperation` individuais, como `PUT /api/customer/owners/123`, `PUT /api/customer/owners/456` e solicitações semelhantes, recomendamos consolidar essas operações em uma única `RemoteOperation`. Uma abordagem possível é padronizar todas as chamadas `RemoteOperation` que começam com `PUT /api/customer/owners/` para um formato uniforme, especificamente `PUT /api/customer/owners/{ownerId}`. Isso é ilustrado no exemplo a seguir. Para obter informações sobre outras regras de personalização, consulte [Habilitar o 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"
               }
            ]
         }
      }
   }
}
```

Em outros casos, as métricas de alta cardinalidade podem ter sido agregadas a `AllOtherRemoteOperations` e pode não estar claro quais métricas específicas estão incluídas. O agente do CloudWatch é capaz de registrar em log as operações descartadas. Para identificar as operações descartadas, use a configuração apresentada no exemplo a seguir para ativar o registro em log até que o problema ocorra novamente. Em seguida, inspecione os logs do agente do CloudWatch (acessíveis por `stdout` do contêiner ou por arquivos de log do EC2) e pesquise a palavra-chave `drop metric data`.

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

#### Criar a política de limitação de métricas
<a name="Optimize-Cardinality-Metric-Limiting"></a>

Se a configuração de limitação de métricas padrão não abordar a cardinalidade para o seu serviço, será possível personalizar a configuração do limitador de métricas. Para fazê-lo, adicione uma seção `limiter` na seção `logs/metrics_collected/application_signals` no arquivo de configuração do agente do CloudWatch.

O exemplo apresentado a seguir reduz o limite de limitação de métricas de 500 métricas distintas para 100.

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