Ferramentas de gerenciamento de crise no Linux

 (brendangregg.com)
2 pontos por GN⁺ 2024-03-25 | 1 comentários | Compartilhar no WhatsApp
  • Se você só começar a instalar ferramentas de diagnóstico depois que ocorrer uma falha de desempenho, perderá tempo com preparação em vez de recuperação; por isso, é melhor incluir previamente ferramentas de gerenciamento de crise na imagem do servidor Linux
  • A lista recomendada inclui procps, util-linux, sysstat, iproute2, tcpdump, perf, bcc/bpftrace, trace-cmd, ethtool etc., e representa o conjunto mínimo de pacotes para verificar imediatamente CPU, disco, rede e rastreamento do kernel
  • bcc e bpftrace têm muitas ferramentas sobrepostas, mas o bcc oferece opções de CLI mais ricas, enquanto o bpftrace é mais fácil de editar no local; na execução, ambos geram o mesmo bytecode BPF
  • Instalar durante uma falha pode resultar em dezenas de minutos perdidos por causa de variáveis como SSH lento, configuração quebrada do apt, bloqueio de repositórios, firewall, sistema de arquivos imutável e erros de permissão
  • O custo está principalmente no uso de disco e no tempo de distribuição da imagem, mas a maioria dos pacotes recomendados é pequena; incluí-los por padrão em distribuições Linux corporativas permite iniciar mais rápido a resposta a falhas de desempenho

Ferramentas mínimas para ter antes da falha

  • Quando ocorre uma falha de desempenho, o tempo gasto instalando as ferramentas necessárias para diagnosticar a causa já é uma perda; por isso, é mais seguro deixar ferramentas de gerenciamento de crise instaladas por padrão em servidores Linux
  • A lista é baseada na tabela “Linux Crisis Tools” do Systems Performance 2nd Edition
  • Com base nos pacotes do Ubuntu, as ferramentas recomendadas são as seguintes
    • procps: ps, vmstat, uptime, top
      • Verificação de estatísticas básicas
    • util-linux: dmesg, lsblk, lscpu
      • Verificação de logs do sistema e informações de dispositivos
    • sysstat: iostat, mpstat, pidstat, sar
      • Verificação de estatísticas do sistema e dos dispositivos
    • iproute2: ip, ss, nstat, tc
      • Ferramentas de rede preferidas
    • numactl: numastat
      • Verificação de estatísticas NUMA
    • tcpdump: tcpdump
      • Sniffing de rede
    • linux-tools-common, linux-tools-$(uname -r): perf, turbostat
      • Verificação de profiler e estatísticas de PMU
    • bpfcc-tools ou bcc: opensnoop, execsnoop, runqlat, softirqs, hardirqs, ext4slower, ext4dist, biotop, biosnoop, biolatency, tcptop, tcplife, trace, argdist, funccount, profile etc.
      • Ferramentas eBPF prontas
    • bpftrace: bpftrace, versões básicas de opensnoop, execsnoop, runqlat, biosnoop etc.
      • Scripting com eBPF
    • trace-cmd: trace-cmd
      • CLI do Ftrace
    • nicstat: nicstat
      • Estatísticas de dispositivos de rede
    • ethtool: ethtool
      • Informações de dispositivos de rede
    • tiptop: tiptop
      • PMU/PMC top
    • cpuid: cpuid
      • Detalhes da CPU
    • msr-tools: rdmsr, wrmsr
      • Investigação detalhada da CPU

Como encarar bcc e bpftrace juntos

  • bcc e bpftrace têm muitas ferramentas sobrepostas, mas cada um é mais conveniente em situações diferentes
  • As ferramentas do bcc têm mais recursos, como opções de CLI, e funcionam melhor como ferramentas prontas
  • As ferramentas do bpftrace podem ser editadas na hora, facilitando verificações adaptadas à situação
  • Isso não significa que um dos dois seja mais rápido
    • Os dois geram o mesmo bytecode BPF
    • Durante a execução, ambos são igualmente rápidos
  • O bcc está evoluindo na direção de migrar ferramentas baseadas em Python para C com libbpf
    • Usa CO-RE e BTF
    • Os pacotes ainda não foram retrabalhados
    • No futuro, bpfcc-tools deve ser substituído pelo pacote menor libbpf-tools, contendo apenas os binários das ferramentas

Ferramentas adicionais conforme o tipo de servidor

  • A lista acima é apenas uma lista mínima
  • Se o servidor tiver aceleradores, também devem estar incluídas ferramentas para analisar esse hardware
    • Servidor com GPU Intel: intel-gpu-tools
    • Servidor NVIDIA: nvidia-smi
  • Ferramentas de depuração como gdb também podem ser pré-instaladas se for desejável usá-las imediatamente em situações de crise
  • Como as ferramentas de análise essenciais não mudam com frequência, essa lista talvez só precise ser atualizada uma vez a cada alguns anos

O custo real da instalação padrão

  • A primeira desvantagem perceptível ao adicionar pacotes é o uso de disco
  • Em instâncias de nuvem, até mesmo alguns MB a mais na imagem padrão do servidor podem aumentar o tempo de implantação da instância em alguns segundos ou frações de segundo
  • A maioria dos pacotes recomendados é pequena, e o bcc deve ficar menor no futuro, então o custo em espaço e tempo não deve ser grande
  • O debuginfo tem um volume total de cerca de 1GB, o que de fato já gerou preocupação de tamanho e impediu sua inclusão padrão

Como a instalação pode travar durante uma falha

  • Se você tentar instalar ferramentas depois que a falha já aconteceu, o tempo pode ser consumido resolvendo problemas de instalação em vez de fazer o diagnóstico
  • Um fluxo de exemplo seria o seguinte
    • 4:00pm: o site da empresa sai do ar ou fica tão lento que não pode ser usado
    • 4:01pm: no dashboard de monitoramento, o grupo de servidores de backend parece anormal, e suspeita-se de alto I/O de disco
    • 4:02pm: tenta-se acessar o servidor via SSH, mas o login está muito lento
    • 4:03pm: tenta-se executar iostat -xz 1, mas iostat não está disponível, e aparece a instrução para instalar sysstat
    • 4:07pm: a instalação do pacote falha porque não consegue resolver o repositório, revelando um problema de configuração em /etc/apt
    • 4:10pm: é preciso executar apt-get update com a configuração corrigida, mas o processo está muito lento
    • 4:13pm: ocorre timeout de conexão, levantando suspeitas sobre conectividade com o repositório ou sobre o próprio problema de desempenho
    • 4:17pm: confirma-se que a equipe de segurança de rede bloqueou tráfego inesperado e requisições apt de saída via HTTP/HTTPS/FTP
    • 4:20pm: depois de desativar o firewall, apt-get update funciona, mas a instalação falha com erro de permissão
    • 4:24pm: a equipe de segurança da plataforma explica que se trata de um sistema imutável, com gravação bloqueada em partes do sistema de arquivos, incluindo áreas de binários executáveis
    • 4:27pm: a equipe de SRE anuncia uma grande falha, a direção exige atualizações de status e ETA de recuperação, mas o diagnóstico real quase não avançou
    • 4:30pm: tenta-se usar cat /proc/diskstats como substituto improvisado para iostat, mas é preciso ler a documentação do Linux e só se confirma o que já se sabia: o disco está ocupado
    • 4:55pm: sobe uma nova imagem de servidor com sistema de arquivos gravável e a instalação do sysstat se torna possível, mas o site voltou apenas por causa do reinício do servidor, sem que a causa tenha sido corrigida
    • 12:50am: como continuação hipotética do exemplo, o site é invadido porque firewall e proteções do sistema de arquivos ficaram desativados
  • O incidente das 12:50am não é uma experiência real, mas o restante do exemplo é baseado em experiência real
  • Em um emprego anterior, por volta da marca de 15 minutos, a “traffic team” às vezes começava o failover de uma região de nuvem, e quando a instalação do iostat terminava, o sistema-alvo já podia estar ocioso

Por que isso deve entrar na imagem padrão

  • O cenário acima mostra o quão frágil é depender da instalação posterior de ferramentas durante uma falha em produção
  • Algumas empresas já usam imagens de servidor personalizadas criadas pela equipe de OS com as ferramentas necessárias incluídas
  • Ainda assim, muitos sites continuam rodando a versão Linux padrão sem alterações, e nesses casos a necessidade só costuma ficar clara depois de uma falha
  • Se distribuições Linux corporativas incluírem essas ferramentas de gerenciamento de crise por padrão, empresas grandes e pequenas poderão iniciar o diagnóstico imediatamente quando ocorrer uma falha de desempenho

Leituras relacionadas

1 comentários

 
GN⁺ 2024-03-25
Opiniões no Hacker News

  • Esta lista é útil. Em situações em que o próprio servidor está bagunçado, como uma falha ao resolver repositórios do apt, a nuvem muitas vezes se encaixa bem.
    Em vez de ficar tentando consertar, você mata a máquina ou a remove do pool e sobe uma nova; a nova máquina e o app entram limpos e a indisponibilidade acaba. A máquina problemática pode ser investigada separadamente fora do caminho crítico.

    • Depois de “resolver” o problema, ninguém tem tempo ou permissão para investigar aquela máquina, então, com o tempo, a abordagem de reconstruir do zero faz a equipe perder capacidade real de resolver problemas e conhecimento acumulado.
      Vira a versão em software do “sujeito que só troca peças” no mundo físico.
    • “16h10: o mesmo problema de desempenho continua na máquina nova.”
    • Isso não é necessariamente uma vantagem exclusiva da nuvem; está mais para uma vantagem de operar servidores virtualizados e substituíveis (cattle).
    • Ao matar a máquina, você também pode fazer as evidências desaparecerem. Pode ser que todos os logs estejam em algum lugar externo, mas normalmente falta alguma coisa.

  • Nem todos os servidores são conteinerizados, mas muitos são contêineres, e isso traz suas próprias dificuldades.
    Ferramentas de depuração dentro de imagens Docker muitas vezes são apontadas por scanners automáticos de segurança como “ferramentas desnecessárias que ajudam um invasor a observar e modificar o comportamento do sistema”. Em alguns casos, como gdb, a preocupação faz sentido, mas em muitos outros não.
    Por isso, algumas ferramentas ficam em um volume separado, de preferência como binários estáticos, ou são compiladas e instaladas usando o caminho de montagem como prefixo de instalação. Quando é preciso depurar, pede-se ao time de operações para montá-las temporariamente como somente leitura.
    Além disso, quando alguma ferramenta de debug exige habilitar um recurso específico do kernel, frequentemente surgem perguntas e preocupações sobre o impacto nos outros contêineres no mesmo host.

    • Se um invasor consegue executar arquivos no filesystem e a única coisa que falta para a execução é o arquivo existir, parece que ele poderia simplesmente gravar o arquivo por conta própria.
      Não vejo muito cenário em que essa política faça sentido além de “a organização está usando mal o scanner de segurança”.
    • Uma forma melhor é criar uma segunda imagem com ferramentas de debug e o usuário root e executá-la anexada aos namespaces de PID e de rede do contêiner de produção.
      Para usar um depurador, você precisa de muitas coisas, como a permissão SYS_PTRACE, usuário 0 e flags como --privileged, então normalmente é melhor subir um segundo contêiner.
      Com esse método, não é preciso reiniciar o contêiner de produção, o que também reduz a chance de perder evidências para reprodução.
      Ainda assim, não é fácil lembrar desse procedimento durante uma pane, então é preciso testá-lo antes e registrar o passo a passo em um runbook.

  • Relacionado a isso, desde o FreeBSD 5.2, ou seja, desde 2004, todos os sistemas FreeBSD têm /rescue/*.
    Há um único binário linkado estaticamente que agrupa cerca de 150 ferramentas essenciais, com hardlinks usando os nomes comuns, e ele tem cerca de 17 MB.
    https://man.freebsd.org/cgi/man.cgi?rescue
    https://github.com/freebsd/freebsd-src/blob/main/rescue/resc...

    • Em 15 anos, nunca precisei usar isso. Nos últimos 4 ou 5 anos, venho portando o que dá para *BSD pela minha saúde mental.

  • Quando eu estava na Netflix, Brendan e sua equipe garantiram que ferramentas de depuração como bpftrace, bcc e um perf funcionando corretamente estivessem instaladas por toda parte.
    Foram ferramentas que salvaram minha pele várias vezes.

  • Fiquei surpreso por strace não estar nessa lista. Normalmente é uma das primeiras ferramentas que pego.
    Especialmente quando um programa retorna mensagens de erro inúteis ou erradas, strace é realmente útil.

  • Em entrevistas para cargos do tipo SRE, sempre abordamos ferramentas como essas.
    O ponto principal não é o quanto o candidato decorou comandos específicos; é impressionante quando ele apresenta uma ferramenta nova, mas observamos o que ele sabe que é possível fazer, quais ferramentas existem e como usá-las.
    O importante é ter noção de que é possível capturar e analisar tráfego de rede, chamadas de sistema e perfis de execução, além de examinar o estado do sistema operacional e do hardware.

  • Se, em uma crise dessas, não for possível instalar ferramentas, dá para executar vários utilitários com Docker.
    Por exemplo, criar um contêiner em uma linha, conectá-lo à rede do host para rodar ferramentas do tipo netstat, ou montar /proc e executar ferramentas de sistema como iostat, sar, vmstat, mpstat e pidstat com --privileged, --net host e --pid host.
    Claro que yum install é melhor, mas, se você puder usar Docker e lidar com os mapeamentos necessários, é uma alternativa. Em configurações rootless ou com Podman, provavelmente não funcionaria muito bem.

    • Existe alguma situação em que o apt não consegue baixar e instalar pacotes, mas o Docker consegue puxar um contêiner novo?
      Seria algo como as bibliotecas do apt estarem quebradas?
    • Em casos de rede segregada, é exceção. Boa sorte tentando puxar uma imagem “Ubuntu”.
    • Nesse contexto, eu gostaria que o busybox incluísse mais dessas ferramentas.
      Ter um arquivo de cerca de 1 MB que você possa enviar para o servidor e executar na hora ajudaria muito.

  • Todo mundo recebe acesso root? Eu preciso abrir um ticket para o administrador de sistemas para qualquer coisa que eu faça.

    • Hoje sou consultor e vou para uma empresa nova a cada poucos meses. Sempre há pessoas com quem é preciso manter uma boa relação.
      Vale decorar os nomes do pessoal de segurança e das pessoas de jaqueta esquisita que liberam sua entrada no prédio, e levar cartões da Starbucks.
      Também vale tratar bem a equipe de limpeza e decorar seus nomes; sua mesa fica mais limpa. Às vezes, ficar até mais tarde e conhecer essas pessoas compensa.
      Também é bom fazer amigos no financeiro. Se você toma café, almoça e conversa sobre coisas além de trabalho, demonstrando interesse, as pessoas certas avisam quando há demissões chegando ou quando o dinheiro da empresa vai ser liberado.
      Também é preciso tratar bem o pessoal de TI, ou seja, quem entrega notebooks e administra e-mail. Você vai ver com que rapidez eles removem ferramentas de segurança inúteis do seu computador e o quanto você sobe na fila de upgrades.
      O mais importante são os administradores de sistemas. Não só por causa do root, mas porque um bom administrador de sistemas sabe programar, embora nunca diga isso em voz alta. Um bom administrador sabe em quais cantos escuros há cadáveres e se aquilo é só um armário ou um cemitério inteiro. Se você aprender a construir para a plataforma deles, ganhará muito mais margem de manobra. Quando eles pedirem algo, atenda.
    • Antigamente eu cuidava de operações de TI; aqui isso significa sistemas, SRE e segurança.
      Este texto é voltado a pessoas que operam apps na infraestrutura fornecida pela TI. Se for preciso interagir como no exemplo, isso não é um problema técnico, é uma falha organizacional.
      Tínhamos linhas de comunicação muito claras e confiáveis, e as pessoas agiam junto com desenvolvimento, operações, segurança e compliance por telefone, não por chat — hoje talvez em algo como Teams.
      Na prática, havia ao menos um ponto de contato em todas as equipes, e normalmente o desenvolvedor rodava o app em recursos fornecidos pela equipe de operações. Compliance aprovava a configuração, e a confiabilidade do serviço era uma tarefa de desenvolvimento. Quando DevOps é feito nesse sentido, muitos problemas desaparecem.

  • Não vejo nmap, netstat e nc. Essas ferramentas também me salvaram várias vezes.

  • Se eu fosse acrescentar apenas uma, seria nmap.
    Problemas de conectividade de rede nem sempre aparecem claramente em alguns apps.

    • screen, tmux, byobu, pv, rsync e, claro, vim também são necessários.