quando se trata de operacionalizar os seus dados de log, HAProxy fornece uma riqueza de informação. Neste post do blog, nós demonstramos como configurar o registro de HAProxy, direcionar um servidor de Syslog, entender os campos de log, e sugerir algumas ferramentas úteis para processar arquivos de log.
mergulho profundo no HAProxy Logging
HAProxy situa-se no caminho crítico da sua infra-estrutura. Se usado como um balancer de carga de arestas, um sidecar, ou como um controlador de entrada Kubernetes, Obter logs significativos de HAProxy é um must-have.
O registo dá-lhe informações sobre cada ligação e pedido. Ele permite a observabilidade necessária para a solução de problemas e pode até ser usado para detectar problemas precoces. É uma das muitas maneiras de obter informações de HAProxy. Outras formas incluem obter métricas usando a página Stats ou API de tempo de execução, configurar alertas de E-mail, e fazer uso das várias integrações de código aberto para armazenar log ou dados estatísticos ao longo do tempo. HAProxy fornece logs muito detalhados com precisão de milissegundo e gera uma riqueza de informações sobre o tráfego que flui em sua infra-estrutura. Isto inclui:
- métricas sobre o tráfego: dados de tempo, contadores de conexões, Tamanho do tráfego, etc.
- informação sobre as decisões HAProxy: mudança de conteúdo, filtragem, persistência, etc.
- informação sobre pedidos e Respostas: cabeçalhos, códigos de Estado, cargas, etc. estado de terminação de uma sessão e a capacidade de detectar onde estão a ocorrer falhas (lado cliente, lado servidor?)
neste post, você vai aprender como configurar o registro de HAProxy e como ler as mensagens de log que ele gera. Vamos então listar algumas ferramentas que você vai achar úteis ao operacionalizar seus dados de log.
Servidor Syslog
HAProxy pode emitir mensagem de log para processamento por um servidor syslog. Isto é compatível com ferramentas de syslog familiares como o Rsyslog, bem como com o serviço mais recente do systemd journald. Você também pode utilizar vários log forwarders como Logstash e Fluentd para receber mensagens Syslog de HAProxy e enviá-los para um aggregator Central de log.
Se estiver a trabalhar num ambiente de contentores, o HAProxy suporta o registo nativo da nuvem, o que lhe permite enviar as mensagens de registo para o stdout e o stderr. Nesse caso, salta para a próxima secção onde vais ver como.
Antes de ver como activar o registo através do ficheiro de configuração do HAProxy, deve primeiro certificar-se de que tem um servidor de Syslog, como o rsyslog, configurado para receber os registos. No Ubuntu, iria instalar o rsyslog usando o Gestor de pacotes apt, como por exemplo:
Uma vez instalado o rsyslog, edite a sua configuração para lidar com a ingestão de mensagens de log HAProxy. Adicione o seguinte ao /etc / rsyslog.conf ou para um novo ficheiro dentro do rsyslog.directório d, como o /etc / rsyslog.d / haproxy.conf:
então, reinicie o serviço rsyslog. No exemplo acima, o rsyslog escuta o endereço IP loopback, 127.0.0.1, no Porto UDP padrão 514. Esta configuração em particular escreve para dois ficheiros de Registo. O arquivo escolhido é baseado no nível de gravidade com que a mensagem foi registrada. Para entender isso, dê uma olhada mais de perto nas duas últimas linhas do arquivo. Começam assim.:
O padrão Syslog prescreve que a cada mensagem registrada deve ser atribuído um código de instalação e um nível de gravidade. Dado o exemplo de configuração do rsyslog acima, você pode assumir que estaremos configurando o HAProxy para enviar todas as suas mensagens de log com um código de instalação de local0.
o nível de gravidade é especificado após o código da instalação, separado por um ponto. Aqui, a primeira linha Captura mensagens em todos os níveis de gravidade e as escreve para um arquivo chamado haproxy-traffic.log. A segunda linha Captura apenas mensagens de nível de aviso e acima, registrando-os para um arquivo chamado haproxy-admin.log.
HAProxy é difícil de usar certos níveis de gravidade ao enviar certas mensagens. Por exemplo, ele categoriza mensagens de log relacionadas com conexões e solicitações HTTP com o nível de gravidade info. Outros eventos são categorizados usando um dos outros níveis, menos descritivos. Da mais para a menos importante, os níveis de severidade são:
| Nível de Gravidade | HAProxy Logs | |
| emerg | de Erros, tais como a execução de sistema operacional descritores de arquivo. | |
| alerta | alguns casos raros onde algo inesperado aconteceu, como ser incapaz de cache uma resposta. | |
| crit | não utilizado. | |
| err | erros como ser incapaz de processar um arquivo de mapa, ser incapaz de processar o arquivo de configuração HAProxy, e quando uma operação em uma tabela de paus falha. | |
| warning | certos erros importantes, mas não críticos, tais como não definir um cabeçalho pedido ou não se conectar a um servidor de nomes DNS. | |
| notice | muda para o estado de um servidor, como estar para cima ou para baixo ou quando um servidor está desativado. Outros eventos na inicialização, como proxies iniciais e módulos de carregamento também estão incluídos. O exame de saúde, se ativado, também usa este nível. | |
| info | ||
| debug | Você pode escrever personalizado Lua código que registra mensagens de depuração |
Moderna distribuições Linux vêm com o gerenciador de serviço de systemd, que introduz journald para a coleta e o armazenamento de logs. O serviço journald não é uma implementação Syslog, mas é compatível com Syslog, uma vez que ele vai ouvir no mesmo socket /dev/log. Ele irá coletar os logs recebidos e permitir que o usuário os filtre por código de instalação e/ou nível de gravidade usando os campos journald equivalentes (SYSLOG_FACILITY, prioridade).
HAProxy Configuração de Log
O HAProxy o manual de configuração explica que o registo pode ser ativado com duas etapas: A primeira é a de especificar um servidor Syslog global seção usando um log directiva:
log directiva instrui o HAProxy para enviar logs para o Syslog server escuta em 127.0.0.1:514. As mensagens são enviadas com facilidade local0,que é uma das instalações padrão, definidas pelo Usuário Syslog. É também a instalação que nossa configuração do rsyslog está esperando. Você pode adicionar mais de uma declaração log para enviar a saída para vários servidores de Syslog.
Você pode controlar a quantidade de informação que é registrada pela adição de um Syslog nível até o fim da linha:
A segunda etapa para configurar o registo é atualizar os diferentes proxies (frontendbackend e listen seções) para enviar mensagens para o servidor Syslog(s) configurado global seção. Isto é feito adicionando uma diretivalog global
. Você pode adicionar aodefaultsseção, conforme mostrado abaixo:
log global directiva basicamente diz, use o log linha que foi definido no global seção. Colocar umalog global directiva nodefaults secção é equivalente a colocá-la em todas as secções proxy subsequentes. Então, isso vai permitir o registro em todos os proxies. Você pode ler mais sobre as seções de um arquivo de configuração HAProxy em nosso post no blog As quatro seções essenciais de uma configuração HAProxy.
Por padrão, a saída do HAProxy é mínima. Adicionando a linha option httplog ao seu defaults a secção irá permitir um registo HTTP mais descritivo, que explicaremos mais detalhadamente mais tarde.
uma configuração HAProxy típica parece-se com esta:
usar as regras globais de registo é a configuração HAProxy mais comum, mas você pode colocá-las diretamente em uma seção frontend. Pode ser útil ter uma configuração de registro diferente como uma única opção. Por exemplo, você pode querer apontar para um servidor Syslog de destino diferente, usar uma instalação de registro diferente, ou capturar diferentes níveis de gravidade, dependendo do caso de uso da aplicação de infra-estrutura. Considere o seguinte exemplo em que o frontend seções, fe_site1 e fe_site2, conjunto de endereços IP diferentes e níveis de gravidade:
Quando o log para um Syslog local de serviço, escrita para um socket pode ser mais rápido do que a segmentação TCP endereço de loopback. Geralmente, em sistemas Linux, um soquete UNIX está disponível em /dev / log porque é aqui que a função syslog() da biblioteca GNU C está enviando mensagens por padrão. Destino o socket UNIX como este:
no Entanto, você deve ter em mente que, se você estiver indo para usar um socket UNIX, para registro e, ao mesmo tempo, você está executando o HAProxy dentro de um ambiente chroot—ou você deixe o HAProxy criar uma chroot diretório para você usando o chroot diretiva de configuração—em seguida, o UNIX socket deve ser feita dentro do chroot directory. Isto pode ser feito de duas maneiras.
primeiro, quando o rsyslog começa, ele pode criar um novo soquete de escuta dentro do sistema de arquivos chroot. Adicione o seguinte ao seu ficheiro de configuração HAProxy rsyslog:
a segunda forma é adicionar manualmente o ‘socket’ ao sistema de ficheiros chroot, usando a opção mount com o comando --bind.
certifique-se de adicionar um item ao seu ficheiro /etc/fstab ou a um ficheiro de unidade systemd para que a montagem persista após a reinicialização. Assim que tiver configurado o registo, irá querer compreender como as mensagens são estruturadas. Na próxima seção, você verá os campos que compõem os registros de nível TCP e HTTP.
Se você precisa limitar a quantidade de dados armazenados, uma maneira é amostrar apenas uma porção de mensagens de log. Defina o nível de registo como silencioso para um número aleatório de pedidos, como por exemplo:
Note que, se possível, é melhor capturar o máximo de dados possível. Assim, não se tem informação em falta quando mais se precisa. Você também pode modificar a expressão ACL para que certas condições sobreponham a regra.
Outra forma de limitar o número de mensagens registradas para definir option dontlog-normal o defaults ou frontend. Dessa forma, apenas os tempos-limite, repetições e erros são capturados. É provável que não queira permitir isso o tempo todo, mas apenas durante determinados momentos, como por exemplo, quando se realizam testes de benchmarking.
Se estiver a correr o HAProxy dentro de um contentor do Docker e estiver a usar a versão 1.9 do HAProxy, então em vez de enviar o resultado do registo para um servidor de Syslog, poderá enviá-lo para o stdout e/ou stderr. Definir o endereço para stdout ou stderr, respectivamente. Nesse caso, também é preferível definir o formato da mensagem para raw, assim como:
HAProxy Log Format
o tipo de registo que irá ver é determinado pelo Modo proxy que definir dentro do HAProxy. HAProxy can operate either as a Layer 4 (TCP) proxy or as Layer 7 (HTTP) proxy. O modo TCP é o padrão. Neste modo, uma conexão full-duplex é estabelecida entre clientes e servidores, e nenhum exame da camada 7 será realizado. Se tiver definido a sua configuração do rsyslog com base na nossa discussão na primeira secção, irá encontrar o ficheiro de registo no /var/log/haproxy-traffic.log.
Quando no modo TCP, que é definido adicionando mode tcp, Você também deve adicionar a opção tcplog. Com esta opção, o formato log é por omissão uma estrutura que fornece informações úteis como detalhes de conexão da camada 4, cronómetros, Contagem de bytes, etc. Se você fosse recriar este formato usando log-format, que é usado para definir um formato personalizado, ele ficaria assim:
Descrições destes campos podem ser encontradas na documentação do formato de log TCP, embora possamos descrever vários na próxima seção.
TCP formato de registo em HAProxy
Quando HAProxy é executado como uma Camada 7 proxy através de mode http, você deve adicionar a opção httplog directiva. Ele garante que os pedidos e respostas HTTP são analisados em profundidade e que nenhum conteúdo compatível com RFC vai ficar por capturar. Este é o modo que realmente destaca o valor de diagnóstico de HAProxy. O formato de log HTTP fornece o mesmo nível de informação que o formato TCP, mas com dados adicionais específicos ao protocolo HTTP. Se você recriar este formato usando log-format, ele se pareceria com o seguinte:
descrições detalhadas dos diferentes campos podem ser encontradas na documentação do formato de log HTTP.
HTTP log format in HAProxy
Pode também definir um formato de registo personalizado, capturando apenas o que necessita. Use the log-format (or log-format-sd for structured-data syslog) directive in your defaults or frontend. Leia nossa personalização post HAProxy Log para saber mais e ver alguns exemplos.
nas próximas secções, irá familiarizar-se com os campos incluídos quando utilizar option tcplog ou option httplog.
Proxies
dentro do arquivo de log que é produzido, cada linha começa com a interface, infra-estrutura e servidor para o qual a solicitação foi enviada. Por exemplo, se você tivesse a seguinte configuração HAProxy, você veria linhas que descrevem pedidos como sendo encaminhados através da interface http-in para a infra-estrutura estática e, em seguida, para o servidor srv1.
isso se torna uma informação vital quando você precisa saber para onde uma solicitação foi enviada, como quando vê erros que só afetam alguns de seus servidores.
Timers
Timers são fornecidos em milisegundos e cobrem os eventos que ocorrem durante uma sessão. Os temporizadores capturados pelo formato padrão de Registo TCP são Tw / Tc / Tt. Aqueles fornecidos pelo formato padrão de log HTTP são TR / Tw / Tc / Tr / Ta. Estas traduzem-se como:
| Timer | Significa |
| TR | O tempo total para obter a solicitação do cliente (HTTP modo apenas). |
| Tw | o tempo total gasto nas filas à espera de um espaço de ligação. |
| Tc | o tempo total para estabelecer a ligação TCP ao servidor. |
| Tr | o tempo de resposta do servidor (apenas modo HTTP). |
| Ta | o tempo activo total para o pedido HTTP (apenas modo HTTP). |
| Tt | o tempo total de duração da sessão TCP, entre o momento em que o proxy a aceitou e o momento em que ambas as extremidades foram fechadas. |
Você vai encontrar uma descrição detalhada de todos os temporizadores disponíveis no HAProxy documentação. O diagrama seguinte também demonstra onde é registado o tempo durante uma única transacção final-a-final. Note que as linhas roxas nas bordas indicam Temporizadores.
Hora de gravação durante um único fim-a-fim transação
o Estado da Sessão no Desconexão
TCP e HTTP logs incluem uma rescisão código de estado que indica a forma em que o TCP ou HTTP sessão terminou. É um código de dois caracteres. O primeiro caractere relata o primeiro evento que fez com que a sessão terminasse, enquanto o segundo relata o estado de sessão TCP ou HTTP quando foi fechada.
Aqui estão alguns exemplos de código de terminação:
| Duas-código de caracteres | Significa |
| — | terminação Normal em ambos os lados. |
| cD | o cliente não Enviou nem reconheceu quaisquer dados e, eventualmente, expirou. |
| SC | o servidor recusou explicitamente a ligação TCP. |
| PC | o proxy recusou-se a estabelecer uma ligação ao servidor porque o limite do’ socket ‘ do processo foi atingido ao tentar ligar-se. |
Há uma grande variedade de razões, uma conexão pode ter sido fechada. Informações detalhadas sobre todos os possíveis códigos de terminação podem ser encontradas na documentação HAProxy.
os contadores
os contadores indicam a saúde do sistema quando um pedido foi aprovado. O HAProxy regista cinco contadores para cada ligação ou pedido. Podem ser inestimáveis para determinar a carga que está a ser colocada no sistema, onde o sistema está a ficar para trás e se os limites foram atingidos. Ao olhar para uma linha dentro do log, você verá os contadores listados como cinco números separados por cortes: 0/0/0/0/0/0.
no modo TCP ou HTTP, estes decompõem-se como:
- o número total de ligações simultâneas no processo HAProxy quando a sessão foi registada.
- o número total de ligações simultâneas encaminhadas através deste
frontendquando a sessão foi registrada. - o número total de ligações simultâneas encaminhadas para este
backendquando a sessão foi registrada. - o número total de ligações concomitantes ainda activas neste
serverquando a sessão foi registada. - o número de tentativas ao tentar se conectar ao servidor de infra-estrutura.
outros campos
HAProxy não grava tudo fora da caixa, mas você pode ajustá-lo para capturar o que você precisa. Um cabeçalho de pedido HTTP pode ser logado adicionando o http-request capture diretiva:
O log irá mostrar os cabeçalhos entre chavetas e separados por símbolos de pipe. Aqui você pode ver os cabeçalhos Host e User-Agent para um pedido:
Um cabeçalho de resposta podem ser registrados pela adição de uma http-response capture directiva:
neste caso, você também deve adicionar um declare capture response directiva, que atribui uma captura de slot, onde o cabeçalho de resposta, uma vez que ele chega, pode ser armazenado. Cada espaço que você adicionar é atribuído automaticamente um ID a partir de zero. Referencie este ID ao chamar http-response capture. Os cabeçalhos de resposta são registrados após os cabeçalhos de pedido, dentro de um conjunto separado de chavetas.
os valores dos cookies podem ser registados de forma semelhante com a Directiva http-request capture.
qualquer coisa capturada com http-request capture, incluindo cabeçalhos HTTP e cookies, irá aparecer dentro do mesmo conjunto de chavetas. O mesmo vale para qualquer coisa capturada com http-response capture.
Pode também utilizar http-request capture para registar dados recolhidos a partir de tabelas de stick. Se você era usuário o controle de taxas de solicitação com um stick-table, você poderia fazer assim:
Então, fazer um pedido para uma página da web que contém o documento HTML e duas imagens mostra o usuário simultâneas de taxa de solicitação de incrementar a três:
Pode também registar os valores dos métodos de obtenção, como por exemplo gravar a versão de SSL/TLS que foi usada (lembre-se que existe uma variável de Registo incorporada para obter esta chamada %sslv):
variáveis definidas com também pode ser registada.
As expressões ACL avaliam para Verdadeiro ou falso. Você não pode registá-los diretamente, mas você pode definir uma variável com base em se a expressão é verdadeira. Por exemplo, se o usuário visita /api, você poderia definir uma variável chamada req.is_api para um valor de Is API e então capturar isso nos logs.
habilitando HAProxy Profiling
com a libertação de HAProxy 1.9, você pode gravar o tempo de CPU gasto no processamento de um pedido dentro de HAProxy. Adicione o profiling.tasks directiva para o global seção:
Existem novas buscar métodos que expõem o perfil métricas:
| método de Busca | Descrição |
date_us |
microssegundos parte da data. |
cpu_calls |
o número de chamadas para a tarefa que processa o fluxo ou o pedido actual desde que foi atribuído. É reiniciado para cada novo pedido na mesma conexão. |
cpu_ns_avg |
o número médio de nanossegundos gastos em cada chamada para a tarefa que processa o fluxo ou o pedido atual. |
cpu_ns_tot |
o número total de nanossegundos gastos em cada chamada para a tarefa de processamento do fluxo ou pedido atual. |
lat_ns_avg |
o número médio de nanossegundos gastos entre o momento em que a tarefa que trata o fluxo é acordado e o momento em que é efetivamente chamado. |
lat_ns_tot |
O número total de nanossegundos entre o momento em que a tarefa de manipulação de fluxo é de acordar e o momento em que efetivamente é chamado. |
adicione estas às suas mensagens de registo como esta:
esta é uma ótima maneira de medir que os pedidos custam mais a processar.
Parsing HAProxy Logs
como você aprendeu, HAProxy tem um monte de campos que fornecem uma enorme quantidade de insight sobre conexões e solicitações. No entanto, lê-los diretamente pode levar a sobrecarga de informação. Muitas vezes, é mais fácil analisá-los e agregá-los com ferramentas externas. Nesta seção, você verá algumas dessas ferramentas e como elas podem alavancar a informação de registro fornecida por HAProxy.
HALog
HALog é uma pequena mas poderosa ferramenta de análise de log que é enviado com HAProxy. Ele foi projetado para ser implantado em servidores de produção onde ele pode ajudar com a solução manual de problemas, como quando enfrentar problemas ao vivo. É extremamente rápido e capaz de processar registros TCP e HTTP de 1 a 2 GB por segundo. Ao passar-lhe uma combinação de bandeiras, você pode extrair informações estatísticas dos logs, incluindo pedidos por URL e pedidos por IP fonte. Então, você pode ordenar pelo tempo de resposta, taxa de erro e código de terminação.por exemplo, se quiser extrair as estatísticas por servidor dos registos, poderá usar o seguinte comando:
isto é útil quando é necessário analisar as linhas de registo por código de estado e descobrir rapidamente se um dado servidor não é saudável (por exemplo, devolver demasiadas respostas 5xx). Ou, um servidor pode estar negando muitas solicitações (respostas 4xx), que é um sinal de um ataque de Força bruta. Você também pode obter o tempo de resposta médio por servidor com a coluna avg_rt, o que é útil para a solução de problemas.com o HALog, poderá obter estatísticas por URL usando o seguinte comando:
a saída mostra o número de Pedidos, o número de erros, o tempo total de computação, o tempo médio de computação, o tempo total de computação de pedidos bem sucedidos, o tempo médio de computação de pedidos bem sucedidos, o número médio de bytes enviados, e o número total de bytes enviados. Além de processar o servidor e estatísticas de URL, você pode aplicar vários filtros para combinar logs com um determinado tempo de resposta, código de estado HTTP, código de terminação de sessão, etc.
HAProxy Stats Page
analisar os logs com HALog não é a única maneira de obter métricas de HAProxy. A página HAProxy Stats pode ser ativada adicionando o stats enable diretiva a uma seçãofrontend oulisten. Ele exibe estatísticas ao vivo de seus servidores. A seguinte seçãolisten inicia a página Stats escutando na porta 8404:
a página Stats é muito útil para obter informações instantâneas sobre o tráfego que flui através de HAProxy. Ele não armazena esses dados, porém, e exibe dados apenas para um único balancer de carga.
HAProxy Enterprise Real-Time Dashboard
Se estiver a utilizar HAProxy Enterprise, então tem acesso ao Painel de instrumentos em tempo Real. Enquanto a página Stats mostra estatísticas para uma única instância de HAProxy, o painel em tempo Real agrega e exibe informações através de um conjunto de Balanceiros de carga. Isso torna fácil observar a saúde de todos os seus servidores a partir de uma única tela. Os dados podem ser visualizados por até 30 minutos.
O painel de instrumentos armazena e exibe informações sobre saúde de Serviço, taxas de solicitação e carga. Além disso, facilita a execução de tarefas administrativas, tais como a habilitação, a desactivação e a drenagem de infra-estruturas. Em um relance, você pode ver quais servidores estão ligados e por quanto tempo. Você também pode ver os dados da tabela stick, que, dependendo do que a tabela stick está rastreando, pode mostrar-lhe as taxas de erro, as taxas de solicitação, e outras informações em tempo real sobre seus usuários. Os dados da tabela de Stick também podem ser agregados.
The Real-Time Dashboard in HAProxy Enterprise
o painel de instrumentos em tempo Real é um dos muitos add-ons disponíveis com HAProxy Enterprise.
conclusão
neste post no blog, você aprendeu como configurar o HAProxy logging para obter a observabilidade sobre o seu balancer de carga, que é um componente crítico dentro da sua infra-estrutura. O HAProxy emite mensagens detalhadas do Syslog ao operar em qualquer modo TCP e HTTP. Estes podem ser enviados para uma série de ferramentas de registro, como o rsyslog.
HAProxy ships with the HALog command-line utility, which simplifies parsing log data when you need information about the types of responses users are getting and the load on your servers. Você também pode ter uma visão da saúde de seus servidores usando a Página de estatísticas de HAProxy ou o Painel De Controle de tempo Real da HAProxy Enterprise.
deseja saber quando um conteúdo como este é publicado? Subscreva este blog ou siga-nos no Twitter. Você também pode participar da conversa em Slack! HAProxy Enterprise combina HAProxy com características da classe enterprise, como o painel de instrumentos em tempo Real, e suporte premium. Contacte-nos para saber mais ou inscreva-se para um teste gratuito hoje!