As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Observabilidade operacional. A observabilidade é necessária para obter insights acionáveis sobre o desempenho de seus ambientes e ajudá-lo a detectar e investigar problemas. Ele também tem uma finalidade secundária que permite definir e medir os principais indicadores de desempenho (KPIs) e objetivos de nível de serviço (SLOs), como tempo de atividade. Para a maioria das organizações, operações importantes KPIs são o tempo médio de detecção (MTTD) e o tempo médio de recuperação (MTTR) de um incidente. Em toda a observabilidade, o contexto é importante, porque os dados são coletados e, em seguida, as tags associadas são coletadas. Independentemente do serviço, aplicação ou nível de aplicação em que você está se concentrando, você pode filtrar e analisar esse conjunto de dados específico. As tags podem ser usadas para automatizar a integração de CloudWatch alarmes, para que as equipes certas possam ser alertadas quando determinados limites métricos forem violados. Por exemplo, uma chave de tag `example-inc:ops:alarm-tag` e o valor nela podem indicar a criação do CloudWatch alarme. Uma solução que demonstra isso está descrita em [Use tags para criar e manter CloudWatch alarmes da Amazon para instâncias do Amazon EC2](https://aws.amazon.com/blogs/mt/use-tags-to-create-and-maintain-amazon-cloudwatch-alarms-for-amazon-ec2-instances-part-1/). Ter muitos alarmes configurados pode criar facilmente uma tempestade de alertas, quando um grande número de alarmes ou notificações sobrecarrega rapidamente os operadores e reduz sua eficácia geral, enquanto os operadores fazem a triagem e priorizam manualmente os alarmes individuais. Um contexto adicional para os alarmes pode ser fornecido na forma de tags, o que significa que as regras podem ser definidas na Amazon EventBridge para ajudar a garantir que o foco seja dado ao problema inicial, e não às dependências posteriores. O papel das operações paralelas geralmente DevOps é negligenciado, mas para muitas organizações, as equipes de operações centrais ainda fornecem uma primeira resposta crítica fora do horário comercial normal. (Mais detalhes sobre esse modelo podem ser encontrados no [whitepaper de Excelência operacional](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/separated-aeo-ieo-with-cent-gov-and-partner.html).) [Diferentemente da DevOps equipe responsável pela carga de trabalho, ela normalmente não tem a mesma profundidade de conhecimento. Portanto, o contexto que as tags fornecem nos painéis e alertas pode direcioná-las para o runbook correto para o problema ou iniciar um runbook automatizado (consulte a postagem do blog Automatizando os alarmes da Amazon com). CloudWatch AWS Systems Manager](https://aws.amazon.com/blogs/mt/automating-amazon-cloudwatch-alarms-with-aws-systems-manager/)