Verifique a integridade do serviço no Mule 4

Verifique a integridade do serviço no Mule 4

Verifique a integridade do serviço no Mule 4
cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


É importante monitorar seu serviço e verificar se ele está disponível e / ou está executando conforme o esperado. Para fazer isso, precisamos entender o que significa saúde de serviço. Neste artigo, apresentarei duas definições diferentes. No entanto, lembre-se de que seu projeto também pode ter sua própria definição específica.

Todos os exemplos são preparados no tempo de execução do Mule 4.2. Se você estiver familiarizado com Spring Boot Actuator, você deve ver algumas semelhanças de interface. Decidi usar a abordagem Spring, pois é clara e fácil de ler.

Saúde do serviço

Para monitorar seus serviços com eficiência, um conjunto de condições de saúde do serviço deve ser escolhido. Pode ser uma lista universal, mas pode ser adaptada às especificações do seu projeto. Aqui estão algumas idéias que você pode usar:

  • O serviço foi iniciado?
  • Tem um ponto de extremidade alcançável de serviço?
  • O tempo de execução criou o arquivo âncora?
  • O serviço estabeleceu com êxito uma conexão com outro sistema via HTTP ou qualquer outro protocolo?
  • O serviço estabeleceu uma conexão dentro do limite com outro sistema?

Este é apenas o começo e pode ser estendido conforme necessário. Lembre-se de que as verificações de saúde devem ser rápidas e simples e não muito complexas, pois podem levar a dificuldades de manutenção. Decidi apresentar duas abordagens. O primeiro será totalmente focado na questão de saber se meu serviço foi iniciado. O segundo será mais sofisticado, pois eu esperaria ver se meu serviço estabeleceu uma conexão dentro de um limite aceitável.

Arquivo âncora

Condição de verificação de saúde: nosso serviço foi implantado?

Temos algumas maneiras de verificar se o serviço está sendo executado no tempo de execução do Mule. Primeiro de tudo, podemos olhar para mule-ee.log. Depois que o serviço Mule for iniciado, no arquivo de log, você deverá ver a tabela com status de inicialização do aplicativo. Como na imagem abaixo. Nós podemos dizer isso exame de saúde aplicativo do domínio padrão foi IMPLANTADO. Mule irá configurá-lo para FALHOU em caso de erro.

status de implementação no mule-ee.log
Status de implementação no mule-ee.log

Tempo de execução do mule cria arquivo [application name]-anchor.txt quando o serviço é implantado corretamente. Observe que a extensão txt existirá para os sistemas Windows e Linux. Nesse cenário, precisamos procurar a existência de arquivos no diretório de aplicativos. Usando o exemplo anterior, eu procuraria health-check-anchor.txt. Se minha ferramenta de monitoramento não encontrar esse arquivo, eu recebo um alerta de que algo deu errado.

Saúde do ponto final

Atuador de inicialização por mola

Enquanto eu estava implementando microsserviços usando Spring BootEu tenho encontro Atuador de inicialização por mola biblioteca. Essa biblioteca ativou alguns pontos de extremidade simples. O mais importante para mim foi /saúde e / info. O primeiro, mostrado abaixo, permitiu-me verificar facilmente o status do meu aplicativo. Como você pode ver, embora configService e hystrix são marcados como o status geral PARA CIMA é PARA BAIXO. Isso significa que algumas outras condições não foram avaliadas corretamente.

Saúde do serviço Spring Boot Actuator
Funcionamento do serviço Spring Boot Actuator

Exame de saúde simples

Condição de verificação de integridade: Nosso serviço foi implantado? O serviço é executado?

Como podemos alcançar esse cenário? O Mule não possui algo como um endpoint de integridade, permitindo verificar se o serviço está sendo executado ou não. Eu acho que a maneira mais fácil seria habilitar Ouvinte HTTP em URL específico como / saúde. Sob esse endereço, devemos receber informações claras sobre o status. Como no diagrama abaixo, isso pode ser tão simples como sempre retornando o status UP por serviço com 200 códigos de status HTTP.

Status simples do serviço
Status simples do serviço

Se eu não conseguir alcançar /saúde ponto final Eu sei, prontamente, que algo está errado com o meu serviço. Por outro lado, se eu receber alguma resposta, fico feliz em marcar meu serviço como funcionando e funcionando conforme o esperado. Vamos ver algo mais complexo.

Exame de saúde complexo

Condição de verificação de saúde: Nosso serviço foi implantado? O serviço é executado? O serviço estabeleceu uma conexão com o sistema externo dentro de um limite de tempo limite definido?

Em comparação com a verificação de saúde simples anterior, aqui temos maiores expectativas em relação ao nosso serviço. Esperamos que o serviço possa se conectar a um sistema externo por meio do protocolo HTTP ou consultar o banco de dados usando uma instrução select simples. Além disso, podemos exigir que algum limite de tempo limite seja atingido. O diagrama abaixo mostra um processo simples.

Verificação de integridade complexa do serviço
Verificação de integridade complexa do serviço

No exemplo apresentado, estamos executando paralelamente três verificações diferentes. Duas chamadas HTTP externas e uma chamada de banco de dados. Para cada chamada, realizamos a verificação de status personalizada. Para chamadas HTTP, pode ser verificado se o código de status HTTP 200 ou 201 foi retornado. Afinal, as etapas foram executadas, calculamos o status geral do serviço. Geralmente, se uma das chamadas estiver marcada como status do serviço DOWN também será refletida como DOWN. A parte mais complexa aqui é “Verificar status” e “Computar status”. Nessas duas ações, você pode colocar o login personalizado conforme necessário.

Código de status HTTP

Se você decidir expor o status do serviço usando o ponto de extremidade restante, considere também alterar as devoluções retornadas. Status HTTP. É uma boa prática retornar 200 código para um status ACIMA e 503 em caso de status BAIXA. Por quê? 200 está bom, enquanto o status DOWN definitivamente não está bom. Acima de tudo, o código do cliente notará que o código 5xx ocorreu e essa é uma situação excepcional que requer alguma ação.

Serviço indisponível (http.cat de origem)
Serviço indisponível (http.cat de origem)

Implementação

Após esta breve introdução ao status de integridade do serviço, é hora de ver a implementação no tempo de execução do Mule. Eu preparei um aplicativo que possui /saúde ponto final exposto. Este ponto final acentua apenas OBTER solicitações e devolver conteúdo em JSON.

Cenário simples

O primeiro e mais fácil é sempre retornar o status UP. Como você pode ver, realizamos isso em três etapas. Poderíamos fazer isso em apenas uma etapa, no entanto, decidi ter um fluxo mais genérico. Em conseqüência, apenas o processador da primeira mensagem será alterado. Mais sobre isso na próxima seção.

Padrão, sempre UP, status
Padrão, sempre UP, status.

O que esse fluxo realmente faz é definir o status como bem-sucedido. Depois de ligar GET / saúde devemos sempre receber:

Esta solução é bastante simples, mas pode atender às suas necessidades. Se você tiver requisitos mais sofisticados, como verificar se há uma conexão ou obtermos uma resposta dentro dos prazos especificados, consulte a próxima seção.

Verificando conexão

O fluxo de status de integridade do fluxo é muito mais complexo. Primeiro, obtemos uma dispersão que chama dois fluxos privados simultaneamente. Os próximos dois passos são semelhantes ao que você já viu. Esse é o status da computação e a preparação de uma resposta final.

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
Verificação paralela
Verificação paralela

Estou esperando estrutura como no exemplo abaixo:

Em comparação com o exemplo anterior, agora eu tenho detalhes matrizes. Cada item é uma verificação de saúde específica. Para este exemplo em particular:

  • obter resposta demorou mais que o esperado.
  • a conexão com o banco de dados não funcionou devido a problemas de conectividade.

Como resultado, o status geral é DOWN.

Conectando ao Terminal HTTP

Fluxos de status de integridade HTTP
Fluxos de status de integridade HTTP

O fluxo que verifica a integridade está executando solicita o status de computação. A lógica é bastante simples. Se o código de status da resposta HTTP for 200, então o status do serviço é ACIMA. O tempo de execução do mule, por padrão, geraria uma exceção para códigos maiores ou iguais a 400. Precisamos suprimir esse comportamento. Para tratar qualquer código de status como um sucesso, precisamos configurar o validador de resposta da solicitação HTTP, como abaixo:

<http:response-validator > <http:success-status-code-validator values="100...599" /> </http:response-validator>

Por que eu decidi variar de 100 a 599? Porque esse é um padrão e não devo receber nada fora desse intervalo.

Se você não estiver atualizado com as novidades Combine e E se Sintaxe do DataWeave, você pode achar útil ler o artigo DataWeave – Dica 1. Para mantê-lo curto após a transformação, defina o status da variável. O mecanismo DataWeave adiciona propriedades errorCode e statusCode quando o status é igual a “DOWN”.

12345678910111213141516171819 %dw 2.0output application/java---{serviceHealth: {serviceType: "http",(using (status = if (vars.service.statusCode == 200) "UP" else "DOWN") {status: status,(status match {case "DOWN" -> {errorCode: vars.service.reasonPhrase,statusCode: vars.service.statusCode}else -> {}}) })}}

Limite de tempo limite

Também podemos estender as condições e esperar receber uma resposta dentro de um intervalo de tempo especificado. Ambas as condições devem ser atendidas para considerar o status como em execução:

  • O código de status da resposta HTTP é 200.
  • Tempo de conexão, limite inferior ao definido (se o limite for especificado).

No caso de um limite violado, gostaria de fornecer um código de erro. Aqui está o trecho da transformação:

Conectando ao DB

Como podemos verificar a integridade do banco de dados? No tempo de execução do Mule, precisamos usar Experimentar bloco para manipular todas as exceções que podem ocorrer durante a chamada ao banco de dados. Podemos usar Em Erro Continuar para continuar nosso fluxo. Em seguida, em Transform Message, verificamos se recebemos um erro durante a chamada e configuramos o status adequadamente.

Verificação de integridade do banco de dados
Verificação de integridade do banco de dados

Código fonte

O código fonte está disponível no meu GitHub conta aqui. Se você tiver algum comentário ou pergunta sobre o código, não hesite em me escrever.

Sumário

Para verificar se o serviço de tempo de execução do Mule foi implantado corretamente, podemos usar arquivos âncora. Em cenários avançados em que as condições são muito mais complexas, vale a pena expor /saúde ponto final que informaria sobre o status do serviço. Podemos definir um limite, realizar chamadas simples para o banco de dados, etc. Depende totalmente de você e de seus requisitos. Lembre-se de que as verificações não devem ser muito complexas, pois podem se tornar muito complicadas.


cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br
Luiz Presso
Luiz Presso