Monitorando recursos com o ASP.NET Core 3.0, Health Checks, Azure Logic Apps e o Slack
Em um post anterior demonstrei a implementação de uma aplicação Web voltada ao monitoramento de recursos de infraestrutura. Utilizei para isto o ASP.NET Core 2.2, Health Checks e diversos packages que integram o projeto open source Xabaril/AspNetCore.Diagnostics.HealthChecks. Dentre as tecnologias possíveis de serem acompanhadas e oferecidas por esta solução estão servidores do SQL Server, Oracle, PostgreSQL, MySQL, MongoDB e Elasticsearch, aplicações Web, projetos SignalR, brokers de mensageria baseados em RabbitMQ e Kafka, clusters do Kubernetes, diversos serviços do Microsoft Azure e AWS…
Aqueles interessados em conhecer mais a respeito deste exemplo podem fazê-lo acessando o link a seguir:
ASP.NET Core + Health Checks: implementando rapidamente uma solução de monitoramento
Neste novo artigo retomo esse projeto (SiteMonitoramento), fazendo agora uso de uma nova versão do mesmo criada com o ASP.NET Core 3.0 e já disponibilizada no GitHub:
ASP.NET Core 3.0 + Health Checks + Dashboard + Monitoramento de Recursos
A intenção desta vez é ir além, criando um Worker Service que consumirá um endpoint com os status dos diferentes Health Checks/dependências cadastrados em SiteMonitoramento. Worker Services são uma nova opção oferecida pelo .NET Core 3.0 e que contam com um template que simplifica a implementação de soluções como Windows Services e processos, valendo-se para isto de parte da infraestrutura e do runtime do ASP.NET Core.
Este Worker Service irá analisar periodicamente cada Health Check, enviando notificações de alerta para um canal em um grupo do Slack. Essa comunicação com o Slack ocorrerá por meio de uma Logic App criada no Azure. Logic Apps são um tipo de recurso baseado em workflows e disponibilizado na nuvem Microsoft, simplificando em muito a integração com diversos serviços corporativos: Microsoft Teams, SAP e Office 365 também constituem exemplos de tecnologias suportadas em uma Logic App.
E aproveito este espaço para um convite.
Dia 22/10/2019 (terça) a partir das 21:30 — horário de Brasília — teremos mais uma live no Canal .NET. Desta vez será abordado o uso da biblioteca Polly, solução esta que possibilita um melhor tratamento de falhas em projetos .NET e contribui assim para a obtenção de aplicações mais estáveis.
Para efetuar a sua inscrição acesse a página do evento no Meetup. A transmissão acontecerá via YouTube, em um link a ser divulgado em breve.
SiteMonitoramento: visão geral e o endpoint com os dados para monitoramento
Conforme indicado anteriormente, a aplicação SiteMonitoramento faz uso de packages que compõem o projeto Xabaril/AspNetCore.Diagnostics.HealthChecks no monitoramento de recursos através de Health Checks. Na imagem a seguir está o dashboard disponibilizado por esta aplicação, com a checagem dos status de instâncias do SQL Server, Redis e MongoDB, um site publicado no Microsoft Azure, além de uma conta de armazenamento do Azure e do DocumentDB/Cosmos DB:
Para facilitar o consumo de informações envolvendo o status de Health Checks defini o endpoint /status-monitoramento na classe Startup, através de uma chamada ao método UseHealthChecks em Configure (a partir da linha 65). Ajustes foram realizados de maneira a formatar o resultado deste endpoint, com o retorno gerado contendo a identificação do endpoint, seu status e a descrição de um eventual erro; o resultado em questão foi serializado por meio da classe JsonSerializer (namespace System.Text.Json):
O resultado do endpoint /status-monitoramento pode ser observado na próxima listagem, com nenhuma das dependências apresentando qualquer tipo de problema:
Criando a Logic App para comunicação com o Slack
Visando a integração com o Slack será criada uma nova Logic App no portal do Azure:
Informar um nome para a Logic App (AlertasMonitoramentoInfra-LogicApp neste exemplo), definindo ainda um Resource Group e uma Location. Confirmar este procedimento acionando o botão Create:
Concluído o processo de criação, a Logic App estará disponível para se configurar o workflow de integração com o Slack:
Para implementar o workflow acessar então a opção Logic app designer. Um vídeo estará disponível apresentando detalhes sobre este tipo de serviço:
Avançando com a barra de rolagem aparecerá a opção Start with a common trigger. Será necessário selecionar um trigger/gatilho. Para o tipo de solução que estamos implementando será escolhido When a HTTP request is received:
A primeira parte do workflow estará montada, conforme indicado na próxima imagem:
Acionar a opção Use sample payload to generate schema, a fim de definir um contrato com os campos contendo informações a serem recebidas pela Logic App (os dados em questão servirão de base para o envio de uma mensagem ao Slack):
Aparecerá agora o popup Enter or paste a sample JSON payload. Preencher o campo correspondente com o conteúdo JSON indicado na imagem a seguir, em que foram especificadas as propriedades dependency e message; concluir este processo clicando no botão Done:
Em Request Body JSON Schema constará a estrutura do objeto a ser recebido via solicitação HTTP do tipo POST pela Logic App. Um pouco abaixo deste trigger estará a opção + New step, a qual permitirá incluir a integração com o Slack como uma nova ação no workflow (através do assistente Choose an action):
O Azure oferece diversas ações e conectores pré-definidos (seção All) para a implementação de uma Logic App, como demonstrado na próxima imagem:
A pesquisa desta funcionalidade possibilitará encontrar as ações disponíveis para integração com o Slack. Selecionar para este exemplo o item Post message:
Na ação que possibilita a integração com o Slack aparecerá o botão Sign in, que deverá ser acionado para permitir a conexão com um grupo e um canal desta ferramenta de colaboração (o ideal para a realização deste procedimento é que já se tenha conectado anteriormente ao grupo do Slack):
Ao clicar em Sign in será exibida a tela a seguir, que solicitará a permissão de acesso da Logic App ao grupo do Slack; acionar então a opção Allow:
Um canal (Channel Name) e uma mensagem (Text Message) deverão ser especificados para o envio da notificação:
Preencher então o Channel Name:
E o campo Message Text, utilizando para isto os itens dependency e message disponíveis em Add dynamic content:
Concluir este procedimento acionando o botão Save. Neste momento um endereço terá sido gerado em HTTP POST URL; esta configuração servirá de base para o envio de mensagens ao Slack através do Worker Service de monitoramento:
Implementando o Worker Service de monitoramento
O Visual Studio 2019 é uma das alternativas para a criação de projetos baseados no template Worker Service:
Temos ainda a possibilidade de gerar um projeto deste tipo via linha de comando (dotnet new), fazendo uso para isto da opção worker:
Já abordei anteriormente o uso de Worker Services com o .NET Core 3.0 no seguinte artigo:
Novidades do .NET Core 3.0: Worker Services
Nesta seção será detalhada a implementação de uma aplicação do tipo Worker Service chamado MonitoramentoInfraProcess. Os fontes deste projeto já foram disponibilizados no GitHub:
No arquivo appsettings.json estão os itens:
- UrlBaseHealthChecks, que contém a URL-base para acesso aos dados com os status dos Health Checks do projeto SiteMonitoramento;
- UrlLogicAppSlack, com o endpoint para consumo da Logic App criada na seção anterior.
A classe StatusHealthCheck corresponde à representação dos dados com status dos Health Checks configurados em SiteMonitoramento:
Já na classe Worker (gerada quando da criação do projeto) está a implementação do processo de monitoramento:
- No construtor deste tipo estão sendo recebidas instâncias de ILogger (namespace Microsoft.Extensions.Logging) e IConfiguration (namespace Microsoft.Extensions.Configuration), além de gerado um objeto do tipo JsonSerializerOptions (namespace System.Text.Json) empregado na deserialização do resultado contendo os status dos Health Checks;
- Em ExecuteAsync acontecerá a checagem dos status dos Health Checks, através de um loop executado a cada 1 minuto (60 mil milissegundos, linha 99);
- Caso uma chamada ao endpoint com dados de Health Checks retorne o código 503 (Service Unavailable) teremos a confirmação de que uma ou mais dependências cadastradas em SiteMonitoramento apresentam indisponibilidade (linha 59). Requisições serão enviadas à Logic App (dentro do loop que se inicia na linha 76) para assim reportar no Slack os erros de cada Health Check com problemas.
Testando o Worker Service
Supondo que as instâncias do Redis e do MongoDB não estejam no ar, como indicado na imagem a seguir:
E também no endpoint a ser consumido pelo Worker Service:
Ao executar o Worker Service de monitoramento será possível visualizar que notificações foram enviadas ao Slack:
E dentro do canal monitoramento no Slack estarão as mensagens com os Health Checks e seus respectivos erros:
