"Identificar e reportar o status atual do dispositivo" soa como uma tarefa; num BIG-IP é um passeio por superfícies, cada uma com seu vocabulário. O administrador eficiente sabe qual delas responde a pergunta da vez.
A camada física: avisos do LCD
Nas plataformas de hardware, o Liquid Crystal Display (LCD) do painel frontal reporta condições de hardware - alarmes de ventoinha, energia, temperatura - antes de você sequer logar. Um alarme piscando no painel é o jeito de o dispositivo dizer que o problema antecede o sistema operacional. Os mesmos alertas caem nos logs do sistema, mas o painel é a visão sem login.
A camada de visão geral: dashboard
O dashboard grafa os sinais vitais - Central Processing Unit (CPU), memória, conexões, vazão - como séries temporais. Responde "o dispositivo está saudável em geral agora" e "algo mudou na última hora". É um medidor, não um microscópio: quando o dashboard mostra um penhasco, a próxima parada são as estatísticas e os logs para nomear a causa.
A camada de objetos: o Network Map
O Network Map desenha a árvore de entrega - virtual servers, pools, membros - em formas coloridas, e as formas são uma língua que vale aprender com precisão. Círculo verde é disponível; losango vermelho é offline porque um monitor disse; quadrado azul é desconhecido, tipicamente sem monitor atribuído; triângulo amarelo é indisponível, com frequência um limite de conexões atingido; preto é desabilitado por um administrador. Um olhar responde "o que o dispositivo acredita sobre a saúde da minha aplicação", e o detalhe no hover nomeia o monitor decisor. O mapa reflete crença, não verdade: um membro verde atrás de um monitor quebrado está verde porque o monitor está feliz - exatamente a armadilha que as provas de troubleshooting armam.
A camada de comando: TMSH
O Traffic Management Shell (TMSH) reporta tudo que as superfícies gráficas mostram, de forma automatizável. show sys hardware, show sys cpu e show sys memory cobrem a plataforma; show cm sync-status e show sys failover cobrem o retrato do cluster, incluindo o status de alta disponibilidade (HA) e de device trust; show ltm virtual e show ltm pool (com members) cobrem os objetos de tráfego, e as variantes de estatísticas somam os contadores. Interpretar estatísticas de objetos de tráfego - requisições distribuídas entre membros, conexões atuais versus máximas, bits de entrada e saída - é como você confirma funcionalidade com números em vez de cores: um pool cujos membros todos mostram tráfego está balanceando; um membro em zero enquanto os irmãos sobem é a anomalia que merece explicação.
A camada de socket: netstat e status de serviços
O objetivo de netstat do blueprint é um teste de alfabetização Linux com sotaque BIG-IP. netstat -pan (ou o equivalente moderno ss) lista sockets com seus processos; filtrar por LISTEN responde "quais serviços estão de pé e em quais portas". A direção da inferência importa: dado um listener na porta 443 do Transmission Control Protocol (TCP) pertencendo ao httpd, você conclui que o utilitário de configuração está no ar; um listener na 22 é o sshd; a 4353 é o canal de gerenciamento entre dispositivos. Inversamente, "o serviço está escutando nesta porta" se responde pela presença ou ausência da linha. Combine com tmsh show sys service para a visão de status dos daemons, e você distingue elementos ativos de inativos da pilha de entrega sem sair do shell - precisamente o que o cenário da prova pede.
Esta série, em ordem
Este artigo abre a série Troubleshooting e operação do BIG-IP. Ele nomeia as superfícies em que um equipamento informa a sua condição; as partes vão da leitura à captura e à entrega: as estatísticas e os logs, depois o tcpdump e os metadados que o TMM escreve numa captura, depois as evidências que você envia ao suporte ou guarda para si (o snapshot, os testes de hardware, o backup) e, por fim, o que vigia o equipamento quando você não está olhando.
- Como ler estatísticas do BIG-IP. Por que uma resposta de estatísticas chega em três envelopes, as metades alta e baixa de um contador, e por que uma amostra nunca é uma taxa.
- Os arquivos de log do BIG-IP: um mapa do /var/log. Qual log responde qual pergunta: objetos de tráfego, quem entrou, quem mudou o quê, e a escada de severidade.
- tcpdump no BIG-IP: como ele difere do tcpdump padrão. O mesmo binário do tcpdump, mas interfaces que não são placas de rede: a interface especial 0.0 e os sufixos exclusivos da F5.
- Como capturar com segurança em um BIG-IP de produção. Limitar a captura, vigiar o disco, escolher o detalhe: capturar num equipamento que está carregando tráfego real.
- O que o BIG-IP escreve dentro da sua captura. O que o TMM sabia sobre cada pacote, escrito depois dele: slot, TMM, virtual server, IDs de fluxo, a causa do reset, até segredos de TLS.
- Como ler uma captura do BIG-IP: o trailer da F5 no Wireshark. O dissector f5ethtrailer transformando esses bytes extras em campos legíveis no Wireshark.
- Níveis de detalhe da TMM e peer flows (:n, :nn, :nnn, :p). Os sufixos :n, :nn, :nnn e :p, quanto metadado cada um anexa, e capturar os dois lados de uma conexão.
- qkview e iHealth: o fluxo do retrato de suporte. O autorretrato de diagnóstico do equipamento, enviado ao iHealth e lido pelas suas heurísticas.
- EUD: diagnóstico de hardware do BIG-IP antes do RMA. A bateria de testes offline de memória, armazenamento, sensores e interfaces, rodada antes de abrir uma autorização de devolução de mercadoria ().
- Arquivos UCS: o backup do BIG-IP que contém tudo. O backup completo do equipamento, incluindo as chaves privadas que as pessoas esquecem, e como criá-lo e restaurá-lo.
- Alerting customizado no BIG-IP: traps SNMP, e-mail e syslog remoto. O pipeline de alertas que vigia o fluxo de logs, e alertas próprios por trap , e-mail ou syslog remoto.
- AVR: Application Visibility and Reporting no BIG-IP. A análise no próprio equipamento que transforma tráfego em latência por virtual server, member, URL e código de resposta.