Disaster nível de proteção de recuperação de auto-avaliação
Opinião Por enquanto me lembro que eu trabalhei em um ambiente onde há uma tela na parede mostrando o estado dos sistemas da empresa. Ou, na verdade, num caso, que mostra a situação dos sistemas da empresa, a menos que houvesse um teste em combinar.
De tempos em tempos que a informação tem sido útil. Infelizmente, na maioria das vezes nós sabemos que há um problema, porque meia dúzia de usuários pediram para levantar bilhetes - as telas não têm necessariamente atualizados em tempo, e quando eles têm que eu tive para correlacionar na minha cabeça o impacto do fato de que eu fui apenas disse que a porta 12 na chave 3 tem ido para baixo.
Eu vi dezenas de pacotes de monitoramento, e todos eles foram terrivelmente inadequada. Alguns foram horrivelmente caro ao lado de sua inadequação hediondo. Então, por que é isso? Por que ninguém escrever pacotes de monitoramento que realmente monitoram coisas e dizer o que você precisa saber quando você precisa saber isso?
Protocolos desonestos
Para ser justo com os fornecedores de software de monitoramento, eles estão fora de um mau começo porque as ferramentas disponíveis para eles é simplesmente terrível.
SNMP (Simple Network Protocol o Management - embora francamente, não há nada de simples nisso) é pesado e desajeitado para usar, mas está preso com ele, porque a sua longevidade tornou onipresente. Vamos enfrentá-lo, ninguém com bom senso está prestes a tentar produzir uma alternativa porque as barreiras à entrada no mercado são insuperáveis.
WMI (Windows Management Instrumentation) é realmente muito bom, mas é claro que é um conceito Microsoft somente então você está preso com a usá-lo apenas em sua propriedade do Windows. Finalmente, você tem Syslog ... bem, você pode dar uma prioridade simples para cada tipo de alerta, mas o conteúdo é em grande parte não-estruturados e assim a utilidade é limitada.
Software Protocol-driven
O próximo problema é que muitos mecanismos de monitoramento são escritos por pessoas que entendem os protocolos, mas nunca tive realmente para monitorar qualquer coisa na vida real. Então, é tudo orientado em torno de comparar o uso da CPU com limites, alertando quando uma interface do switch tem ido para baixo, e assim por diante.
Eu ainda tenho que usar uma ferramenta de monitoramento que se parece com o primeiro passo no seu desenvolvimento foi enviar um grupo de analistas para os gerentes da rede de entrevista e dizer: "OK, o que você quer ser capaz de fazer"
Ou se eles têm, eles voltaram para os desenvolvedores que já disse: "Sorry guys, SNMP não pode fazer isso, nós vamos ter que fazer o painel mais bonito e espero que as pessoas não vão notar é o mesmo que antes ".
Então, o que os analistas de encontrar? Vamos imaginar, então, que eu sou um gerente de infra-estrutura e um dos analistas referidos desce em mim por um par de horas. O que eu estaria dizendo que eu quero? Bem, aqui está o meu top 10.
1. Recurso de câmera Wildlife
As equipes de filmagem que seguem Sir David Attenborough volta são esses dias abençoados com câmeras que estão constantemente a gravação - os últimos segundos / minutos de filmagens são retidas e substituído em um loop. Quando acontece algo interessante que apertar o botão "Record" e os últimos segundos / minutos estão comprometidos com o armazenamento. Isto significa que eles não têm de ter o dedo no gatilho de John Wayne em velocidade. Eu quero isso para os meus principais portas de rede: quando eu tenho um problema, o tráfego que me interessa é que correu nos últimos cinco, 10, 15 minutos, eu quero mantê-lo por uma quantidade razoável de tempo.
2. Filtrar por dispositivo
Se um interruptor acende a luz vermelha na tela de monitoramento, eu quero clicar sobre ele e aparecer os alertas e as entradas do syslog que se relacionam com ele. Se um luzes da porta até eu quero ver que os dados filtrados para essa porta.
3. Detector Muppet
Eu quero o pacote de monitoramento de rede para me dizer que a conexão end-to-end entre um servidor virtual e servidor de backup é ineficiente porque uma das oito ou 10 portas LAN o tráfego está atravessando não tem Jumbo Frames ligado.
4. Qual o caminho?
Eu quero ver (visualmente e de forma legível), o caminho usado pelo tráfego entre dois pontos. Isso significa entender o que o balanceador de carga está fazendo, descobrir qual dos nós físicos em um grupo Router Redundancy Protocol Virtual está realizando o tráfego, e assim por diante. E quando você fez isso, me mostre o funcionamento passo-a-passo do tráfego de aplicações para que eu possa ver onde os atrasos são (e fazê-lo em nível de aplicação, por favor, para que eu possa ver que, por exemplo, a rede é rápido, mas o aplicativo está sendo morto por limite de tempo de DNS).
Nenhum comentário:
Postar um comentário