Um guia para os terminais da API de verificação de saúde da Fluent Bit

Quando as equipes começam a investir em observabilidade e monitoramento em geral, o esforço é necessário para verificar se seus aplicativos estão funcionando sem problemas. Freqüentemente, a ausência de um alerta é interpretada como um sinal de que tudo está bem. Mas e se o monitor parou? Nesse caso, a ausência de eventos é um problema. Por esse motivo, os microsserviços em um ambiente de Kubernetes devem implementar um terminal de saúde, tradicionalmente definido como /health. Isso leva à pergunta: faz Bit fluente Tem algo ao qual podemos conectar a verificação de saúde do contêiner?

Entendendo as sondas de saúde de contêineres e pods

Para permitir que os recipientes ou vagens de Kubernetes sejam efetivamente gerenciadas, devemos ser capazes de interrogar sua condição. Para esse fim, os dockerfiles incluem a capacidade de definir ações de verificação de saúde. (Para obter mais informações sobre a definição de verificações de saúde em Dockerfiles, consulte https://mng.bz/rn4a.) Para pods, podemos descrever várias verificações diferentes (também chamadas de sondas), incluindo LIVRE. (Para mais informações, consulte https://mng.bz/2gnw.) Se o pod não responder rápido o suficiente à verificação de saúde de Kubernetes, podemos assumir que o pod não é saudável e precisa ser substituído por uma nova instância.

Uma resposta saudável para Kubernetes é uma resposta normalmente contendo um código de resposta HTTP de 200que pode ser acompanhado por um corpo contendo ok. Qualquer código de resposta HTTP fora do 200-299 O alcance é considerado prejudicial. É prática comum para um aplicativo de contêiner para incluir algum tipo de implementação de terminais que pode responder às invocações em localhost:8080/v1/healthque fornece detalhes sobre a saúde do aplicativo.

Habilitando o servidor Web de bits fluente

Para permitir que o Bit Fluent se comunique e ouça eventos entregues na Web, precisamos incluir um servidor da Web, o que nos fornece os meios para se comunicar e interrogar o bit fluente. O primeiro passo é configurar o bit fluente para iniciar o servidor da web, o que fazemos com um atributo no (SERVICE) bloco chamado http_server. Também podemos configurar o IP e as portas que o servidor deve usar (http_listen e http_portrespectivamente).

Configurando verificações de saúde em bit fluente

Com o servidor ativo, também podemos configurar como o bit fluente responde às verificações de saúde. Precisamos ligar o recurso com o health_check atribuir com um valor de on; Caso contrário, a resposta padrão do servidor da Web é fornecida. Com a resposta da saúde ativada, podemos controlar o que o bit fluente considera saudável.

O que a parte fluente considera ‘saudável’

A saúde é caracterizada por uma contagem de erros de todos os plugins de saída medidos contra um limite definido por hc_error_count e o número de tentativas com falha para plugins de saída (hc_retry_failure_count). Não queremos que a contagem de erros e a contagem de erros de repetição sejam uma pontuação cumulativa desde o início do bit fluente, por isso precisamos definir um período expresso em segundos (hc_period) sobre o qual a contagem é aplicada.

Se tivéssemos uma saída tentando gravar em um arquivo que continuava falhando porque o sistema de arquivos estava cheio, devemos esperar que a contagem de erros ou a contagem de falhas de repetição para exceder um limite rapidamente. Como resultado, a resposta ao URL da verificação de saúde será ruim.

Quando usamos o recurso de verificação de saúde, devemos levar em consideração que bit fluente considera ser um erro e suas implicações. Qualquer saída falhada resultará em uma resposta prejudicial, mesmo que possamos conviver com a perda dessas saídas. Em outras palavras, não há como definir uma tolerância a perder algumas saídas temporariamente; É uma abordagem tudo ou nada.

Desafios com insumos e falhas parciais

O outro desafio é que a verificação de saúde não testa entradas para ver se eles estão trabalhando com sucesso. Se a entrada da entrada (rastreamento de arquivo) não puder ler o arquivo de entrada, um estado não saudável não será produzido com sucesso porque o plug -in é considerado ok, pois o plug -in existe e os valores dos parâmetros são pelo menos definidos.

Consultando a saúde fluente com Curl e Postman

A lista a seguir mostra a configuração do recurso de verificação de saúde; Consulte o capítulo2 fluentbit hello-world-erver.conf.

Tornando a saída mais legível com JQ

Com isso incluído em nossa configuração do Hello-World, podemos executar o bit fluente (fluentbit -c hello-world-server.conf) e, em seguida, use uma ferramenta como Curl ou Postman (ou mesmo um navegador) para acessar as informações sobre o bit fluente. O URL usar é 0.0.0.0:2020dando -nos uma carga útil JSON e detalhes sobre a instância de bits fluente. Se usarmos essa abordagem, podemos usar o JQ para tornar as coisas mais legíveis:

curl 0.0.0.0:2020 | jq

Além dos comandos CURL, criamos configurações do Postman que podem ser usadas para exercer os diferentes pontos de extremidade da API, incluindo o recarregamento a quente. Detalhes sobre a criação de Postman estão no Apêndice A.

Observação: Porque Bit fluente trata todos os seus dados como jsonpode ser útil ter uma ferramenta como JQ que pode formatar a saída para ser mais legível (às vezes chamada de “impressão bonita”). Para obter JQ ou entender como funciona, acesse https: // jqlang.github.io/jq. Informações adicionais estão incluídas no Apêndice B.

Comparando versões da API:/api/v1/vs./api/v2/

O bit fluente fornece APIs que vão além de simplesmente recuperar uma visão sumária. Algumas das APIs têm duas versões disponíveis: V1 é acessado através do caminho da URL /api/v1/e V2 é acessado através do caminho /api/v2/. As mudanças na versão representam melhorias de recursos; A versão URL mais antiga é retida para compatibilidade com versões anteriores. Um exemplo é o final do resumo 45 /métricas; V1 fornece uma carga útil JSON e V2 responde com dados formatados por Prometheus e mais dados do que /v1/metrics.

Usando verificações de saúde fluentes em sondas Kubernetes

Para um Kubernetes Health Verifique, uma resposta simples retornando ok indica que a instância do contêiner está funcionando sem problemas. Para obter essa resposta, precisamos acessar um dos pontos de extremidade operacionais mais significativos no caminho /api/v1/como /api/v1/ health. Se invocarmos o URL da verificação de saúde com um comando Curl, podemos esperar obter uma resposta de ok:

Curl 0.0.0.0:2020/api/v1/health

Perguntas frequentes

1. Como faço para ativar as verificações de saúde em bit fluente?

Você precisa definir três configurações principais em seu (SERVICE) bloquear:

• Definir http_server on Para ativar o servidor da web.
• Adicionar health_check on Para ativar as respostas de verificação de saúde.
• Configure http_listen e http_port Para especificar o IP e a porta do servidor (padrão: 0.0.0.0:2020).

2. Que endpoint devo usar para verificar se a bit fluente é saudável?

Use o /api/v1/health endpoint para obter um simples ok resposta indicando status saudável. O formato completo de URL é http://(host):(port)/api/v1/health (por exemplo, curl 0.0.0.0:2020/api/v1/health). Este terminal é projetado especificamente para as sondas de lutividade de Kubernetes e retorna códigos de status HTTP 200 para instâncias saudáveis.

3. Como o bit fluente determina se é saudável ou prejudicial?

O estado de saúde da Fluent Bit é baseado no desempenho do plug -in de saída em uma janela de tempo definida:

• Limite de erro: Definido via hc_error_count (Número de erros permitidos).
• Limite de falha da tentativa: Configurado com hc_retry_failure_count (Falha em tentativas de repetição).
• Período de tempo: Definido por hc_period (segundos) para impedir a pontuação cumulativa da startup.
• Abordagem tudo ou nada: Qualquer plug -in de saída com falha desencadeia uma resposta prejudicial, sem tolerância para falhas parciais

Observação: A verificação de saúde monitora apenas plugins de saída; As falhas do plug -in de entrada (como arquivos ilegíveis) não acionam o status não saudável.

Nos capítulos subsequentes no livro de Manning, “Bit fluente para Kubernetes”(Particularmente os capítulos 3 e 5), revisitaremos as APIs disponíveis. Faça o download do livro inteiro para ler sobre uma década de inovação e desenvolvimento em tecnologia fluente de bits, incluindo orientações sobre como enfrentar os desafios modernos na observabilidade, particularmente em sistemas distribuídos como Kubernetes.