Monitoração de Web Services e APIs
Monitoração com ambiente Zabbix e Web Services e APIs com ambiente WSO2
Por: Marcelo Godinho (Linkedin), Thiago Diniz (Linkedin) e Vinicius Bona (Linkedin)
Introdução
Não é de hoje que sabemos da importância e dependência que as aplicações possuem das APIs, serviços publicados para troca de informações. Em alguns casos a API é tão importante quanto a aplicação, como o Google Maps. Imaginem só se a API deixa de funcionar, aplicativos de trânsito, UBER e afins simplesmente parariam também.
Devido a esta importância é preciso ter um monitoramento efetivo e em tempo real. Conseguimos de forma fácil monitorar o sistema operacional, servidores de aplicação e etc. Mas um dos grandes desafios da TI quando falamos de web services é o de monitorar o seu status e funcionamento, recebendo alertas de erros ou indisponibilidades e conseguindo detalhes do que ocorreu.
Este artigo apresenta uma proposta de modelo para monitoração de web services baseada nas ferramentas Zabbix (monitoração) e WSO2 (web services / APIs). Está dividido em duas partes, sendo a primeira a configuração do Zabbix e em seguida a configuração de um proxy no WSO2 Enterprise Integrator.
Configuração do Zabbix
O primeiro passo na configuração do Zabbix é a criação de um Host. O Host não precisa obrigatoriamente existir, ou seja, não precisa referenciar um servidor físico ou máquina virtual. Neste exemplo o Host não existe, foi criado apenas para centralizar a configuração dos Items a serem monitorados e das Triggers que irão gerar os alertas.
Com o Host criado pode-se adicionar um novo Item:
Com o Item criado pode-se criar a Trigger.
Validação da Configuração do Zabbix
SLA de Integrações
O Zabbix possui funcionalidades de monitoração de serviços, fornecendo uma visão de alto nível da disponibilidade de itens monitorados. Configuramos um serviço para acompanhar o SLA da integração monitorada.
Para criar um novo serviço:
Sobre o WSO2 Enterprise Integrator
O WSO2 Enterprise Integrator é uma solução para integração entre sistemas que atua como um barramento de serviços e permite que as aplicações se comuniquem traduzindo protocolos, realizando transformação, aplicando segurança, fazendo roteamento de mensagens e etc. Como a comunicação entre as aplicações são centradas nesta solução, é possível gerenciar os fluxos de integração entre os sistemas.
A WSO2 fornece uma gama de conectores com os maiores players como Google, Twitter, SalesForce entre outros. A lista dos conectores pode ser vista neste link.
Ele implementa através de mediators os padrões de integração do famoso livro Enterprise Integration Patterns.
Configuração do WSO2 Enterprise Integrator
É possível desenvolver um conector e implementá-lo da mesma forma que os já disponibilizados pela WSO2. Desse modo é possível utilizá-lo como um mediator no fluxo dos web services/APIs para que este faça o envio das informações ao Zabbix. Este artigo não abordará a criação de um conector, mas sim como emitir um alerta quando algum problema ocorra. Para isso será feito o deploy do conector no WSO2, utilizando um mediator sempre que precisar enviar algum alerta ao Zabbix.
O código fonte bem como o arquivo .zip para fazer o deploy do conector pode ser baixado no github ou diretamente neste link.
Adicionando o conector no WSO2
No menu connectors do WSO2-EI clique em ADD e em seguida selecione o arquivo.zip que foi baixado do github.
Por padrão, quando o conector é adicionado, ele fica desabilitado. Para habilitá-lo basta clicar sob o status “Disabled”.
Usando o conector
Criaremos um cenário hipotético de um proxy para o web service GlobalWeather.
Em uma situação real o web service utilizado no proxy pode ficar indisponível, sendo necessário alertar esta indisponibilidade quando ocorrer. Para isso pode ser adicionado um mediator no proxy para que informe quando algo errado ocorrer.
O proxy de exemplo apenas expõe o GlobalWeather service sem nenhuma transformação. Neste caso configuramos um tempo de timeout de 30 segundos e, em caso de falha, uma exceção é lançada. É aí que o alerta ao Zabbix é disparado.
Um proxy no WSO2 possui 3 sequences: INSEQUENCE, OUTSEQUENCE e FAULTSEQUENCE. De uma forma simplista o INSEQUENCE trata da entrada da requisição até enviar a mensagem para algum lugar, o OUTSEQUENCE trata do retorno da mensagem de algum lugar e o FAULTSEQUENCE é usado quando algum problema ocorre no transporte da mensagem. Pode-se observar na figura do próximo slide as 3 sequences supracitadas.
Caso necessite saber como criar um proxy, este vídeo aborda de uma forma muito simples como fazer.
Utilizaremos o WSO2 Developer Studio para construir o nosso proxy.
Adicionando o conector no Developer Studio
Primeiramente é necessário adicionar o conector no eclipse para que se possa utilizar seus mediators.
Para adicionar, basta clicar com o botão direito sob o projeto (1) e então selecionar o Add or remove connector (2), marcar Add conector (3) e na tela seguinte selecionar o arquivo.zip do conector(4) e clicar em Finish(5).
Após importar ele está disponível para ser utilizado (6).
Usando o conector importado
Para se utilizar o conector no fluxo, é necessário iniciar colocando o endereço do servidor e a porta usada no socket. Para isso clicamos sob o mediator send e, nas suas properties, podemos adicionar a configuração bem como os dados do serviço que queremos alertar no Zabbix. Para isso adicione e mantenha selecionado o send mediator do Zabbix (1) depois nas suas properties clique em Create New Configuration (2) e adicione o endereço e a porta onde o socket do Zabbix está rodando (3). Isso irá configurar o init mediator que será comum para todo o projeto. Em outros proxys ele pode ser reutilizado mudando apenas os dados enviados. O send mediator possui os dados que são enviados (4) para o alerta conforme já realizado a configuração no Zabbix anteriormente. Ou seja, host = integracao, item = statusA, value=1.
O proxy foi configurado para quando um timeout na conexão com o serviço externo ocorrer, o fluxo seja direcionado para o FaultSequence. Para isso, na configuração do endpoint, deve-se setar o tempo de timeout como 30000, já que o tempo está em milissegundos.
A figura abaixo mostra como fazer esta configuração no endpoint.
O proxy está pronto para ser utilizado. Caso ocorra uma tentativa de envio com tempo maior de 30 segundos ocorrerá um Fault e será enviado um alerta ao Zabbix.
O código de exemplo do proxy mostrado aqui também está disponível no github neste link.
Conclusão
Neste artigo trouxemos uma solução para monitoração dos web services e APIs de modo que consigamos emitir alertas em tempo de execução de uma forma um tanto simples. Poderíamos ter feito uma simples classe JAVA e utilizá-la como um class mediator para utilizar no flow do WSO2, porém para seguirmos os princípios de autonomia, abstração, encapsulamento e reúso, desenvolvemos um conector que pode ser utilizado em todos os web services / APIs.
Originally published at medium.com on March 27, 2018.
