Bom, como eu falei, é extremamente importante você pensar em alarmes também. Não adianta você só colocar lá os dashboards, você colocar os logs e você não ter alarmes. Você precisa saber quando as coisas estão acontecendo. Você precisa saber quando tem um problema e que você precisa entrar para resolver isso. O seu time, inclusive, aí vai uma dica de algo que eu costumo fazer e que acho que é legal você pensar também. A gente não pode trabalhar o problema só quando ele acontece. Você tem que se preparar para o problema. Tem uma métrica que se chama MTTR, que é o Main Time to Repair. É o tempo que você demora para resolver um problema. Então, você como liderança, você precisa pensar um pouco nisso. O tempo que você demora para resolver um problema que está impactando o cliente ou que está dando algum prejuízo para a sua aplicação, ele é extremamente importante. Quanto menor esse tempo, mais elite é o seu grupo, mais elite é o seu time. Então você tem que olhar para isso e ver como é que você consegue fazer isso rápido. E a primeira coisa que pega no MTTR é o alarme. Eu preciso saber que tem um problema acontecendo. Não dá para o cliente ligar e falar que tem um problema acontecendo. Eu preciso saber, eu preciso ser proativo. E para você ser proativo, você tem que ter bons alarmes. Então, vamos lá. A gente vai dar uma gastada aqui no assunto alarme, porque a gente precisa entender quanto isso é importante. E outra, como a gente não vai ter rendizom na parte de CloudWatch, eu vou aprofundar um pouco mais nessa gestão de alarmes e de estratégias para a gente poder sair daqui com isso bastante claro na cabeça, de que é uma das partes mais importantes de quando a gente está falando de uma aplicação, tá bom? A gente olhar para uma aplicação que está rodando, a gente precisa ter alarmes para a gente poder garantir que ela continua rodando, que ela continua operando e assim por diante. Então aqui, quando a gente está falando de alarmes, a gente consegue fazer acionamento de várias situações com base nos alarmes que a gente está fazendo, beleza? E a gente está fazendo beleza ea gente pode pensar em tanto notificar quanto corrigir problemas com os próprios alarmes nem sempre um problema precisa que seu time entre às vezes ele consegue de forma automática já sai corrigindo dependendo do alarme que você gerou beleza vamos lá como é que a gente define um alarme a primeira coisa a gente tem que definir qual métrica que você vai monitorar então por exemplo utilização de cpu utilização de memória e assim por diante. Isso é o que eu vou monitorar, beleza? De uma instância EC2, por exemplo. Outra coisa é a gente definir depois quais são, aqui eu coloquei mais alguns exemplos, o tempo de resposta de uma aplicação, a contagem de erros de uma função lambda. Ou seja, você consegue olhar o que você quer analisar, beleza? A seleção da métrica que você vai olhar, o que você quer saber. Depois, você vai configurar o limite. Então, tá bom, qual que é o limite que precisa ser ultrapassado para eu ter um alarme? Tá bom, vou olhar a CPU, mas se tiver 20% de utilização, já acionou o alarme? Não. 50% ou assim por diante. Você vai decidir ali qual que é o limite que precisa ser ultrapassado por um alarme ser acionado. E você pode pensar que esse alarme vai disparar quando a métrica for maior, for menor ou for igual. Vou te dar um exemplo. Se você bater 80% do CPU, é um limite que faz sentido a gente parar para olhar. Mas, cara, se a sua aplicação, você sabe que no dia a dia ela está batendo 20, será que se ela bater 5 não é um alerta também? Pô, significa só que o cliente não entrou, que as coisas não estão funcionando. Todo dia é 20, um dia é 5. Às vezes faz sentido você colocar um alerta aqui também, quando for menor. E daí, depende, você pode falar, poxa, um é mais crítico, o outro é só para eu dar uma olhada. Sabe, pô, esse aqui eu preciso de ter uma ação, uma ação automática, assim por diante. Esse outro não, eu preciso dar uma olhada. Alguém precisa entrar lá e ver se está tudo bem. Preciso testar, pelo menos, para ver se está tudo no ar. E assim por diante. Você consegue, então, usar estratégias para maior, a menor ou igual, tá bom? Outra coisa também é o Bateu 80% de CPU por um segundo. Será que já faz sentido acionar alguém? Às vezes foi, sei lá, eu brinco que às vezes o sistema dá um soluço, aconteceu alguma coisa ali que a gente nem sabe o que foi. Alguém tropeçou no servidor, brincadeira. Mas às vezes a gente tem alguma coisinha ali que rapidinho já parou e vamos em frente, né? Nem sempre o time tem que entrar. Então aqui o período de avaliação também é muito importante determinar por quanto tempo aquilo tem que acontecer pra daí você alertar então o caso que eu dei aqui de exemplo quando tiver acima de 80% de CPU por cinco minutos consecutivos ai você dispara o alarme ah não pro meu pro meu business é mais ou por exemplo vou dar um exemplo diferente pode fazer alarmes combinados passou de 80% de CPU coloquei que tem que ficar 5% consecutivo mas se bater 90% 1 minuto já tira do ar já me chama aí porque vai dar problema então você consegue colocar alarmes mais mais definidos para cada escala que você precisa de atuação e é muito importante você olhar e revisar isso, principalmente quando você pega um problema, você olhar se os alarmes foram que conseguiram te ajudar a entender aquele problema rapidamente. Outra coisa é a configuração do alarme, tá? Então você vai ter que configurar aqui o limite, o período de avaliação, o número de períodos consecutivos, a condição que vai ter que ser satisfeita, ou seja, tudo que você precisa, que a gente discutiu até agora, tem que estar aqui. Vamos dar um exemplo? Uma que a gente discutiu até agora, tem que estar aqui. Vamos dar um exemplo? Uma métrica aqui. A utilização do CPU de uma instância EC2. É isso que a gente vai ver. O limite, 80%. Período de avaliação, 5 minutos. Então, é tudo o que a gente falou até agora, aqui exemplificado em um case de alarme que fica bom e que a gente consegue acompanhar. Foi o que eu falei. Quer colocar mais algum? Você pode colocar mudando para 90% e colocando depois o gatilho de ação diferente para cada tipo de alarme sendo gerado. Quando o alarme é acionado, ele pode fazer várias coisas. Você vai poder tomar várias ações em cima disso. Você pode notificar o problema, você pode corrigir o problema, você pode fazer alguma ação de mitigação, você pode fazer um graceful degradation, você pode fazer várias coisas. Isso você vai ter que definir ali conforme as coisas forem acontecendo. Você pode, por exemplo, uma ação aqui é você enviar uma notificação para um SNS e desse cara você disparar uma função lambda ali para mudar alguma coisa, para automatizar alguma resposta ao incidente que aconteceu. Pode ser uma estratégia. Vou te dar um exemplo aqui de envio de notificações via o Amazon SNS. Você pode enviar as notificações por e-mail, beleza? SMS ou para outros sistemas ali para eles resolverem e interagirem para resolver o problema. Então você pode usar qualquer outro tipo de coisa aqui só para avisar. Então quando, por exemplo, bater uma CPU ali que nem a gente colocou no EC2, ultrapassar 80% por 5 minutos, manda um e-mail para o administrador ou para o tech lead daquela squad, para o cara que lidera esse time. Pode ser também. Outra coisa que você pode fazer é executar uma função lambda, como eu falei. Então, vamos lá. Executar uma função lambda para responder automaticamente a um evento. Então a gente pode pensar, por exemplo, em tarefa de escalonamento automático. Reinício do serviço, por exemplo, aqui a gente falou bateu 80%. Reinicia, bateu 80% de novo. Aumenta até alguém entrar. Imagina, dá para você fazer isso também, para você não ficar ali sofrendo. Então vamos lá. Quando a memória disponível em um cluster SS está baixa, você executa uma função lambda para colocar mais instâncias ao cluster. Então você pode ter esse tipo de situação. Você está vendo que a memória está sendo consumida, você coloca mais instâncias ali para conseguir dar vazão. Você pode alterar o estado de um recurso AWS também. Então imagina lá que você tem um recurso AWS, você pode parar, iniciar, reiniciar instância EC2 e assim por diante. Então, quando a utilização, por exemplo, de um disco de instância EC2 bater 90, que nem eu falei, reinicia a instância para liberar recurso. E aqui você pode até colocar duas coisas casadas. Reinicia a instância e manda um SNS lá falando para o cara com e-mail para falar falar pro cara entrar porque, pô, bateu 90%, tem algum problema aqui. Possivelmente esse cara, depois de reiniciado, pode estar topando por outro motivo, sei lá. Enfileirou um monte de mensagem e está mandando uma porrada de coisa pro seu EC2 ali e ele não está aguentando. Pode acontecer. Ou você tem algum outro tipo de coisa que entrou em looping. Pode acontecer um monte de coisa que pode gerar esse tipo de comportamento. Mas, gente, se bateu 90% e não escalou, alguma coisa você tem que mexer. Possivelmente ele não vai resolver sozinho. É legal você reiniciar a instância para liberar recursos, mas já chama alguém para entrar aqui. Possivelmente é legal dar uma olhadinha nesse cara, tá?