O blog da AWS

Automatize a criação de casos de suporte da AWS usando os alarmes do Amazon CloudWatch e o Amazon Bedrock

Por Amer Al Okeh, traduzido ao Português por Felipe Brito
Para aplicações de produção, o tempo médio de recuperação (MTTR – Mean time to Recover) é fundamental. De acordo com isso, a AWS oferece planos de suporte Business, Enterprise On-Ramp e Enterprise, nos quais os clientes da AWS podem se beneficiar de um tempo de resposta mais curto para casos relacionados à produção e workloads críticos para os negócios. No entanto, sem ter uma forma automatizada de notificar o suporte da AWS, criar um caso é um processo manual que exige a disponibilidade de engenheiros e o acesso a uma conta da AWS no momento do evento. Isso introduz um atraso na intervenção do suporte AWS, que pode ser crucial no processo de recuperação.Neste post, compartilharemos uma solução para criar automaticamente um caso de suporte acionado pela ação de alarmes do Amazon CloudWatch. Essa solução utiliza os alarmes do Amazon Bedrock e CloudWatch para criar um fluxo automatizado baseado em IA. O Bedrock utilizará um conjunto de dados contendo informações de CTI do suporte AWS e metadados de processos de eventos de alarme do CloudWatch para oferecer recomendações sobre classificação de incidentes.

É fundamental a rapidez com que o suporte da AWS é notificado quando algo dá errado no ambiente de produção. Portanto, ter um mecanismo para criar automaticamente um caso de suporte com base em um alarme do CloudWatch pode agilizar a atenção necessária do suporte da AWS. Ele permite que você concentre seus recursos em lidar com o impacto nos negócios simultaneamente, enquanto a equipe de suporte realiza verificações primárias no recurso relatado pelo alarme.

Exemplos de casos de uso

  • Solução de um problema intermitente, em que você deseja notificar a AWS assim que o problema ocorrer novamente para solução de problemas ao vivo.
  • Respondendo às verificações de saúde do Amazon Route 53 que você estabelece para monitorar a integridade do aplicativo.
  • Automatizando a solicitação de aumento do limite de serviço. Você pode criar um alarme do CloudWatch para notificá-lo quando estiver próximo de um limite de valor de cota.

Visão geral da solução

Essa solução é implantada como uma stack do AWS CloudFormation, que cria os seguintes recursos em sua conta da AWS:

  1. Um tópico do Amazon Simple Notification Service (Amazon SNS) que pode ser usado como uma ação para que o alarme do CloudWatch acione a função AWS Lambda.
  2. Uma função do AWS Lambda que contém código Python.
  3. Uma tabela do Amazon DynamoDB usada para registrar os casos de suporte gerados por esse fluxo de trabalho para futuras verificações de status.
  4. Um tópico do SNS para receber notificações sobre as atividades do AWS Support processadas pelo fluxo de trabalho.
  5. Uma função de execução do Lambda usada pela função Lambda com todas as permissões necessárias para executar as tarefas da solução.

High level architecture showing the deployment of SNS, Lambda function and DynamoDB

Figura 1: Arquitetura em alto nível para a solução

Pré-requisitos

Os seguintes pré-requisitos são necessários:

  • Uma conta da AWS.
  • É necessário um usuário com permissões do IAM para criar tabelas no Amazon DynamoDB, a camada do AWS Lambda, a função do AWS Lambda, a função de execução do AWS Lambda e o tópico do Amazon SNS.
  • A conta da AWS deve estar inscrita no Business Support, Enterprise On-Ramp ou Enterprise Support para acessar a API do AWS Support.
  • Acesso ao modelo de linguagem grande (LLM) Claude 2 da Anthropic in Bedrock.

A solução funciona da seguinte forma:

  1. Um tópico do SNS é adicionado à ação de alarme do CloudWatch.
  2. Se a ação de alarme for acionada, o tópico do SNS enviará um objeto JSON contendo detalhes sobre a alteração do estado do alarme para a função Lambda assinada (2).
  3. A função Lambda é executada e executa as seguintes etapas:
      1. Analisando os detalhes da alteração do estado do alarme, a função extrai o namespace de informações, metric_name, new_state_reason, alarm_arn e dimensões.
      2. Verificando a tabela do DynamoDB em busca de casos relacionados ao mesmo alarm_arn. Se existir um caso de suporte não resolvido para o mesmo alarme, a função envia uma notificação aos assinantes do Amazon SNS e inclui a atualização mais recente do caso de suporte. Caso contrário, ele prossegue para a próxima etapa e cria um novo caso de suporte. Essa etapa é essencial para evitar que alarmes ruidosos gerem casos duplicados.
      3. Realizando a classificação de incidentes. A API do AWS Support exige variáveis ServiceCode, CategoryCode e SeverityCode, que podem variar dependendo do incidente. Para classificar o incidente adequadamente, a função aproveita o modelo Anthropic Claude v2 via Bedrock para realizar uma pesquisa semântica baseada em IA. O Bedrock determina os valores de ServiceCode e CategoryCode com base nos dados analisados do evento de alarme. Posteriormente, na Etapa 5, discutiremos como o SeverityCode é determinado.
      4. Extraindo tags de recursos de alarme. O Lambda extrai as tags de alarme e as utiliza como contexto adicional nos detalhes do caso de suporte. Isso ajuda o AWS Support a entender melhor como fornecer a assistência necessária.
      5. Criação do caso de suporte usando os valores de classificação de incidentes retornados do Bedrock combinados com as tags do alarme definidas pelo usuário.
      6. Registrando o novo caso de suporte na tabela do DynamoDB para referência futura.
      7. Enviar uma notificação para todos os endpoints inscritos em um tópico do SNS.

A support case example created by the automation

Figura 2: Um caso de suporte criado usando o alarme do CloudWatch para solicitar o aumento do limite da VPC quando o uso da VPC atingiu mais de 75% da cota disponível.

Considerações sobre o uso na produção

Leve em consideração as seguintes considerações ao usar na produção:

Uso na produção: essa solução não pretende ser o único meio de geração de relatórios de incidentes. Use-o em conjunto com seus processos existentes de gerenciamento de incidentes, relatórios e notificação.

Criptografia: a melhor prática é usar a criptografia em qualquer lugar. No código de exemplo fornecido com esta postagem, os tópicos do SNS não estão criptografados. Ao usar essa solução na produção, criptografe esses recursos usando o AWS Key Management Service (AWS KMS).

Retenção de registros: o código de amostra fornecido com esta publicação tem um período de retenção codificado do Amazon CloudWatch Logs de 30 dias. É recomendável considerar as políticas de retenção de armazenamento de dados da sua organização ao usá-lo na produção.

Detalhes do caso de suporte: o código de amostra fornecido combina os valores da chave do evento de alarme e as tags de recursos do alarme do CloudWatch para fornecer mais contexto sobre a situação. Adicionar tags como SeverityCode, OwnerEmail, Details, ApplicationName, CallBack e qualquer informação adicional compartilhável ajudará o AWS Support a entender melhor o impacto desse evento.

Métricas personalizadas: o código de amostra também oferece suporte às métricas personalizadas do CloudWatch. Para receber recomendações sobre classificação de incidentes, o Bedrock exige o namespace, metric_name e os parâmetros de detalhes da métrica do CloudWatch. É essencial que esses valores sejam descritivos para correlacionar o incidente com a equipe de suporte de serviço relevante. Você pode escolher um valor de namespace na lista de serviços da AWS que publicam métricas do CloudWatch.

Passo a passo

Etapa 1: implantar a solução usando o console do CloudFormation

Siga as etapas abaixo para implantar o modelo YAML do CloudFormation.

  1. Clone o repositório Git ou baixe o arquivo YAML para seu diretório local.
  2. No console do AWS CloudFormation, escolha Create a stack.
  3. Em Pré-requisito — Preparar modelo, selecione Template is ready. Em Specify template, selecione Upload a template file. Escolha Escolher arquivo e navegue até o local do arquivo YAML em sua máquina, selecione o arquivo YAML e escolha Abrir.
  4. Escolha Avançar.

Step 1 during stack creation where the YAML file location needs to be provided

Figura 3: Etapa 1: Visualização do console de seleção de arquivos YAML da pilha do CloudFormation

5. Na página Criar stack, insira o nome da stack.

6. Em Parâmetros, insira cada um dos seguintes:

    • BedrockRegionalEndpoint — no momento de escrita deste blog, o Bedrock tinha 5 endpoints regionais de API. Para selecionar entre os endpoints de API padrão disponíveis, acesse este link. A solução utiliza endpoints padrão e não endpoints FIPS. O endpoint regional da API deve estar na seguinte sintaxe, incluindo o protocolo HTTPS:
      protocol: //bedrock-runtime.region-code.amazonaws.com
    • BedrockRegion — insira o código da região com base no BedrockRegionalEndpoint selecionado na etapa anterior.

Step 2 is specifying stack details during the CloudFormation deployment for the solution

Figura 4: Exibição do console de requisitos de parâmetros da stack do CloudFormation, página 2

7. Selecione os padrões para o resto das páginas e escolha Avançar.

8. Na página Revisar, confirme e selecione o aviso de Capacidades. Escolha Create Stack para continuar.

 

Showing step 4 of the stack deployment where user acknowledgment is required.   Figura 5: Confirmação e análise da implantação da pilha a pilha

Etapa 2: criar uma camada Lambda

O SDK Python Boto3 versão 1.28.57 ou superior é necessário para que o Lambda acesse a biblioteca para chamadas da API Bedrock. No momento em que escrevo este blog, o Lambda não estava atualizado com a biblioteca Boto3 para oferecer suporte às APIs Bedrock. As camadas do Lambda pode ser usada para incluir as dependências de função necessárias para a API Bedrock.

Siga as etapas para criar a camada Lambda:

  1. Instale as bibliotecas em um diretório de pacotes com o pip.
    mkdir python
    pip3 install -t. /python boto3==1.28.57
  2. Crie um arquivo ZIP das bibliotecas instaladas no diretório python.
    zip -r python.zip. /python/ *
  3. Crie uma camada Lambda
      1. No console do AWS Lambda, abra a página Layers e escolha Create layer
      2. Insira um nome e uma descrição opcional para sua camada
      3. Selecione Carregar um arquivo.zip, escolha seu arquivo python.zip e escolha Abrir
      4. Para tempos de execução compatíveis, selecione Python 3.11
      5. Escolha Criar
Etapa 3: adicionar a camada Lambda à função
  1. Abra a página de Funções do console Lambda.
  2. Escolha a função CW-Alarms-Support-Cases para configurar.
  3. Em Camadas, escolha Adicionar uma camada.
  4. Em Escolher uma camada, escolha Camadas personalizadas.
  5. No menu suspenso de Camadas personalizadas, selecione a camada que você criou na Etapa 2.
  6. Em Versão, escolha 1.
  7. Escolha Adicionar.
Etapa 4: Inscrever-se no tópico do SNS que fornece notificações de atualização do fluxo de trabalho

Depois que a implantação da stack for concluída, você poderá se inscrever no tópico do SNS e receber todas as notificações das atividades da solução. Faça login no console do Amazon SNS e selecione a região em que a pilha de soluções está implantada.

Para inscrever um novo usuário no tópico

  1. No painel de navegação, escolha Tópicos.
  2. Na lista de tópicos do SNS, selecione o nome do tópico – AlarmSupportCasesNotifications-xxxxxxxx<Your-stack-name>.
  3. No painel Assinaturas, escolha Criar assinatura.
  4. Na página Criar assinatura:
      1. Para o ARN do tópico, o ARN selecionado é <Your-stack-name>AlarmSupportCasesNotifications-xxxxxxxx.
      2. Em Protocolo, escolha E-mail ou, opcionalmente, você pode usar qualquer um dos outros protocolos disponíveis.
      3. Para Endpoint, insira um endereço de e-mail que possa receber notificações.
      4. Escolha Criar assinatura.
  5. Verifique sua caixa de entrada de e-mail e escolha Confirmar assinatura no e-mail das Notificações da AWS. O ID do remetente geralmente é no-reply@sns.amazonaws.com.
  6. O Amazon SNS abre seu navegador e exibe uma confirmação de assinatura com seu ID de assinatura.

SNS protocol endpoint selection view in SNS console under the solution SNS topic that users can subscribe to receive notifications.Figura 6: Visualização da seleção do endpoint do protocolo SNS no console do SNS, no tópico da solução SNS, em que os usuários podem se inscrever para receber notificações.

Etapa 5: Configurar a ação de alarme do CloudWatch para enviar eventos de alarme ao tópico do SNS

Você pode adicionar o tópico do Amazon SNS aos alarmes existentes e aos novos alarmes. Nas etapas a seguir, criaremos um novo alarme do CloudWatch.

  1. Faça login no console do CloudWatch. Navegue até a região em que a pilha do CloudFormation está implantada.
  2. No painel de navegação esquerdo, escolha Todos os alarmes.
  3. Na página de alarmes, clique no botão Criar alarme.
  4. Na página Especificar métricas e condições, escolha Selecionar métrica.
  5. Pesquise a métrica do CloudWatch com a qual você deseja configurar seu alarme.
  6. Marque a caixa de seleção ao lado da métrica desejada e escolha Selecionar métrica. Você pode escolher entre qualquer métrica única e métrica matemática.
  7. Defina os parâmetros de condição para quando o estado do alarme será ativado e escolha Avançar.
  8. Na página Configurar ações, em Notificação, configure cada uma:
      1. Um trigger do estado de alarme: escolha entre Em alarme, OK e Dados insuficientes. Isso decidirá qual novo estado do alarme acionará a solução.
      2. Escolha Selecionar um tópico SNS existente
      3. Em Enviar uma notificação, escolha o tópico SNS -CreateSupportCaseTopic-xxxxxxxx <Your-stack-name>
      4. Escolha Avançar
  9. Na página Adicionar nome e descrição, em nome, insira um nome para seu alarme. A descrição do alarme é opcional. No entanto, detalhes adicionais sobre o impacto desse alarme e a quais negócios esse alarme se refere ajudam a direcionar o suporte da AWS para o conjunto certo de ações necessárias para fornecer feedback primário.
  10. Escolha Avançar e, em seguida, escolha Criar alarme.
  11. Além disso, a função verifica as tags abaixo com distinção entre maiúsculas e minúsculas, se configuradas no alarme. Considere usar essas tags quando aplicável.
    • SeverityCode (opcional): você pode definir isso como um dos valores mencionados abaixo. Caso contrário, todos os casos receberão uma severidade padrão baixa:
        • baixo — Orientação geral
        • normal — Sistema comprometido
        • alto — Sistema de produção comprometido
        • urgente — Sistema de produção inativo
        • crítico — sistema essencial para os negócios inativo. A gravidade desse caso está disponível somente para clientes dos planos Enterprise On-Ramp e Enterprise.
    • OwnerEmail (opcional): Por padrão, os casos de suporte da AWS enviam correspondências relacionadas às atualizações de casos para o e-mail principal da conta da AWS e o e-mail alternativo operacional. Para incluir contatos adicionais, use essa tag para receber correspondências relacionadas aos casos de suporte criados para esse alarme. Você pode adicionar vários endereços de e-mail separados por vírgulas (“,”).
    • A solução retorna todas as tags adicionais adicionadas ao alarme e as inclui no corpo da mensagem do caso.

Limpando os recursos

Para excluir todos os recursos associados a essa solução, você pode navegar até o CloudFormation no console da AWS, selecionar a stack que você implantou na Etapa 1 e escolher Excluir.

Conclusão

O fluxo de trabalho automático apresentado neste blog fornece uma solução para notificar imediatamente o suporte da AWS em resposta a eventos de alarme do CloudWatch. Com a introdução do Amazon Bedrock nessa solução, podemos aproveitar os recursos da IA generativa para resolver os requisitos de classificação de incidentes por meio da API de suporte em grande escala.

Ao incorporar essa abordagem em ambientes de produção, a atenção e o feedback imediatos do suporte da AWS podem potencialmente reduzir o MTTR.

Este conteúdo é uma tradução do blog original em inglês (link aqui).

Sobre o autor

Amer Al Okeh é gerente técnico sênior de contas (TAM) na Amazon Web Services (AWS). Como TAM, Amber se concentra em ajudar os clientes do Enterprise Support a atingir suas metas de negócios, enfrentando desafios técnicos, explorando oportunidades de otimização de custos e alcançando a excelência operacional.

 

Sobre o tradutor

Felipe Brito é arquiteto de soluções na AWS e guia clientes nas melhores práticas de arquitetura na nuvem. Possui experiência com projetos de desenvolvimento de software e análise de dados.