Esta é uma pergunta canônica sobre o software de monitoramento.
Também relacionado: Qual ferramenta você usa para monitorar seus servidores?
Eu preciso monitorar meus servidores; o que preciso considerar ao decidir sobre uma solução de monitoramento?
Respostas:
Existem muitas soluções de monitoramento por aí. Todo mundo tem sua preferência e cada empresa tem suas próprias necessidades, portanto não há uma resposta correta. No entanto, eu posso ajudá-lo a descobrir o que você pode procurar na escolha de uma solução de monitoramento.
Em geral, os sistemas de monitoramento servem a dois propósitos principais. O primeiro é coletar e armazenar dados ao longo do tempo. Por exemplo, você pode querer coletar a utilização da CPU e fazer um gráfico com o tempo. O segundo objetivo é alertar quando as coisas não estão respondendo ou não estão dentro de certos limites. Por exemplo, você pode querer alertas se um determinado servidor não puder ser alcançado por pings ou se a utilização da CPU estiver acima de uma certa porcentagem. Existem também sistemas de monitoramento de log como o Splunk, mas estou tratando aqueles como separados por isso.
Essas duas funções principais às vezes vêm em um único produto, outras vezes e mais comum é ter um produto dedicado a cada finalidade.
Pesquisadores :
Todos os sistemas de monitoramento precisam de algum tipo de pesquisador para coletar os dados. Nem todos os dados são coletados da mesma maneira. Você deve examinar o seu ambiente e decidir quais dados você precisa e como eles podem ser coletados. Em seguida, verifique se o sistema de monitoramento que você escolhe suporta o que você precisa. Alguns métodos comuns incluem:
Se você possui principalmente um sistema operacional em seu ambiente ou um sistema operacional primário, determinados sistemas podem ter mais opções que outros.
Configuração :
nos sistemas de monitoramento, costuma haver muita reutilização de objetos. Por exemplo, você deseja monitorar um determinado aplicativo, como Apache ou IIS, em vários servidores. Ou você deseja que certos limites sejam aplicados a grupos de servidores. Você também pode ter certos grupos de pessoas para "estar de plantão". Portanto, um bom sistema de modelos é vital para um sistema de monitor.
A configuração geralmente é feita através de uma interface do usuário ou arquivos de texto. A opção da interface do usuário geralmente será mais fácil, mas os arquivos de texto tendem a ser melhores para reutilização e variáveis. Portanto, dependendo da sua equipe de TI, você pode preferir a simplicidade do que o poder.
Interface do usuário :
A interface mais comum para monitorar sistemas atualmente é uma interface da web. Algumas coisas a avaliar em relação à interface da web são:
Mecanismo de alerta :
O mecanismo de alerta deve ser flexível e confiável. Existem muitas maneiras diferentes de ser notificado, incluindo:
Outros recursos a serem procurados são:
É importante confiar que, quando algo der errado, você receberá o alerta. Isso se resume a duas coisas:
Armazenamento de dados :
se o sistema coleta e armazena dados (isto é, sistemas que incluem gráficos), o sistema armazena dados. Uma implementação muito comum para a loja e gráficos é RRD, por exemplo.
Alguns recursos para procurar no armazenamento de dados são:
Biblioteca de
gráficos : Os gráficos podem ser úteis para identificar rapidamente tendências e contextualizar o estado atual de algo com base em seu histórico. Algumas incluem tendências que podem ser úteis para prever coisas antes que elas aconteçam (por exemplo, ficar sem espaço em disco). Verifique se os gráficos fornecerão as informações que você acha que precisará de maneira clara.
Controles de acesso :
se você tem uma organização grande, pode precisar de controles de acesso, porque determinados administradores só podem ajustar determinadas coisas. Você também pode querer painéis voltados para o público. Se isso for importante, verifique se o sistema de monitoramento possui os controles necessários.
Relatórios :
um sistema que fornece bons relatórios pode ajudar a identificar o que precisa ser aprimorado por longos períodos de tempo. Por exemplo, pode dar uma boa resposta para coisas como "quais sistemas mais desistem?". Isso pode ser importante quando você está tentando convencer a gerência a gastar dinheiro em certas coisas - os negócios são uma prova concreta.
Recursos especializados :
Alguns sistemas de monitoramento são direcionados a produtos específicos ou têm mais suporte do que outros. Por exemplo, se a principal coisa que você precisa monitorar é o SQL Server, ou se você faz uso intenso dos produtos VMWare, deve ver como eles são suportados.
Modelos de monitoramento predefinidos :
um sistema que vem com muitos modelos predefinidos (ou possui uma base de usuários que criou muitos modelos) pode economizar muito tempo.
Descoberta :
se você tiver um ambiente grande ou em mudança. Alguns sistemas oferecem a capacidade de adicionar novos sistemas por meio de uma API ou executar varreduras para encontrar novos servidores ou componentes.
Monitoramento distribuído:
se você tiver vários locais para monitorar, pode ser útil monitorar os pollers em cada local, em vez de muitos sistemas independentes estarem monitorando via WAN.
Existem muitos sistemas de monitoramento por aí. Temos uma lista com um resumo sobre essa pergunta antiga . Para uma referência rápida, alguns dos quais eu mais ouço são:
O motivo pelo qual não posso lhe dizer o que usar é porque toda organização tem suas próprias necessidades. Se você quiser fazer a escolha certa, pense em todos os componentes acima e descubra quais recursos são importantes para sua organização. Em seguida, encontre um sistema ou sistemas que pretendam fornecer o que você precisa e experimente-os. Alguns deles custam um pouco, muito ou são gratuitos. Levando tudo isso em conta, você poderá fazer sua escolha. Pelo que usei, todos estão longe de serem perfeitos, mas pelo menos você pode tentar obter algo que se encaixe.
É útil distinguir entre monitoramento e alerta. Monitorar significa coletar dados e criar gráficos. Alertar significa enviar-me um SMS quando um servidor ficar inoperante no meio da noite.
Nagios é para alertar. Cacti e Munin são para monitoramento. Outros produtos combinam as duas funções. Zenoss e Zabbix são exemplos.
Eu começaria respondendo a algumas perguntas:
Você precisa monitorar servidores, dispositivos de rede, aplicativos ou todos os três?
Existem limitações sobre quais métodos você pode usar para monitorar? Você pode instalar clientes de monitoramento como o NRPE nos servidores ou usará o SNMP, ou talvez ambos?
Quem usará os gráficos e quem usará os alertas? Como você gostaria que fosse o resultado final? A aparência da interface é importante (as pessoas de negócios usarão isso ou apenas a equipe de tecnologia?)
Quais são seus recursos, tanto em termos de tempo, habilidades e hardware? Você tem pelo menos capacidade de script modesta? Você precisa de uma solução pronta para uso?
Na minha opinião, a primeira regra de alerta e monitoramento deve ser simples! Uma organização pode viver ou morrer de como alerta e coleta dados, e na maioria das vezes fica complicada por si mesma. Comece com o básico e construa a partir daí.
Pense nos serviços que o seu software fornece , envie alertas quando esses serviços falharem ou quando o risco de falha desses serviços aumentar.
A teoria por trás das estratégias de monitoramento é vincular o monitoramento e os alertas a algum tipo de contrato de nível de serviço . Afinal, você deseja ser alertado sobre o fato de estar perdendo dinheiro, não necessariamente que há um aumento no número de conexões TCP com o nji0019.myserver.com. Existem várias ferramentas que oferecem vários alertas, definem dependências entre alertas, mas muitas dessas verificações não são diretamente relevantes para o serviço que você fornece a alguém.
Identifique os serviços importantes que você fornece, como a capacidade de veicular um site e a capacidade de modificar esse site (por exemplo, um CMS de algum tipo). Esses devem ser verificados (por exemplo, monitorando se você pode obter a página da web e se pode). A falha desses dois serviços (usados aqui com S maiúsculo) deve acionar um alerta para notificá-lo.
Se é importante que o site responda dentro de um período de tempo razoável, isso também deve acionar alertas. Uma espécie de "violação do SLA", se desejar.
Geralmente, há um risco inerente de um Serviço falhar e, com frequência, esse risco é atenuado pelo fato de você apresentar redundância, por exemplo, um segundo servidor, um banco de dados escravo ou placas de rede extras ...
Quando essa redundância é perdida, o Serviço ainda está bom, mas o risco de falha do Serviço apenas aumentou.
Esse é o segundo principal motivo para acionar alertas; que a redundância se foi (por exemplo, que o segundo servidor tenha morrido) ou que existe um perigo iminente de que o risco aumente (por exemplo, o disco tem apenas 500 Mb restantes ou a tendência do disco indica que o disco ficará cheio em cerca de 5 horas).
Mas check_mk me fornece de 50 a 60 cheques por host, todos são inúteis?
Não. Tudo isso não significa que você deseja abandonar a infinidade de verificações automáticas que obtém com, por exemplo, check_mk, mas significa que você deve tentar categorizar cada uma das verificações em quais serviços podem ser afetados se algo falhar.
Qual serviço seria afetado se a partição / var / fosse preenchida? Qual serviço seria afetado se a interface eth0 estivesse inativa? ... se as conexões TCP de saída estiverem bloqueadas por algum firewall? ... se o número de threads exceder 800? ... se o banco de dados ficar inoperante?
Você possui 2 servidores da Web e um servidor de banco de dados que atende a um site atrás de um balanceador de carga que não possui (por exemplo, o ISP). O serviço que você fornece é a porta 80 nos dois servidores e eles têm caches enormes que podem sobreviver, por exemplo, tempo de inatividade do banco de dados (banco de dados em um terceiro servidor).
Nesse cenário, a falha completa de um servidor da Web não resultaria na inatividade do site. O que aconteceu é que a redundância se foi e, portanto, o risco de falha aumentou. Isso deve acionar um alerta.
A falha completa do banco de dados pode não afetar a capacidade de servir o site, devido aos caches bem ajustados; Isso não afeta o Serviço de veiculação do site, mas pode afetar um Serviço diferente, ou seja, atualizar o site ou aceitar pedidos ...
Cada serviço teria seu próprio nível de serviço, que designa a importância de restaurar o serviço ou evitar interrupções
Toda vez que você receber um alerta, siga um destes procedimentos: - altere o sistema que está sendo monitorado para corrigir o problema que causou o alerta (por exemplo, substitua a unidade ou reconfigure o logrotate ou algo assim) - altere o sistema de monitoramento para evitar que o alerta seja enviado na próxima vez que essa situação surgir. (por exemplo, altere os níveis de "sem disco" para que o disco possa preencher até 90% em vez de apenas 80%)
Eu estou familiarizado com Nagios e sua configuração detalhada e, desde então, fui viciado no multisite do Check-mk. Eu aprendi recentemente que o check_mk tem esse conceito de Business Intelligence (desde a versão 1.11), que parece corresponder bem a esse pensamento. Você pode definir que as verificações nos nagios fazem parte de um serviço maior e têm regras que definem o estado do "Serviço" como uma função do estado de muitas verificações, agregando ao pior ou ao melhor estado.
Um dos pontos mais críticos que as empresas esquecem ao escolher uma solução de monitoramento é que não se trata apenas de resolver problemas operacionais imediatos, mas de problemas imprevistos de amanhã! Quero dizer, é claro que resolver problemas imediatos é importante, mas confie em mim, em muitos casos essa estratégia míope não garante a sobrevivência de uma empresa.
Existem dezenas de excelentes soluções de monitoramento no mercado. A seleção de um pequeno conjunto de soluções que atenda às suas necessidades é uma tarefa difícil e longa; além disso, encontrar uma que atenda ao seu orçamento é ainda mais difícil. A parte interessante é encontrar uma que esteja alinhada com o seu presente e o seu futuro . E não há um processo de avaliação para detectar isso, é uma questão de experiência + intuição + um fator muito importante: Confiança , que não é algo fácil de invadir .
Como regra geral, pesquise e procure por histórias de sucesso do seu conjunto de soluções de monitoramento pré-selecionadas, especialmente se isso afetar uma empresa do seu setor. Peça ao fornecedor suas histórias de sucesso e até peça permissão para falar com um de seus clientes. As empresas que não têm medo disso mostram que têm um relacionamento real com seus clientes, e não escondem isso, e isso é uma coisa extremamente rara de se encontrar hoje em dia.
Zabbix, Icinga, Pandora FMS, op5, Datadog, New Relic ... todos eles têm seus altos e baixos, mas o verdadeiro problema é descobrir qual deles se adapta melhor ao seu futuro.
Se você estiver considerando o monitoramento remoto do sistema, pode ser uma boa ideia procurar os locais reais em que os testes são realizados. Problemas de conectividade não fazem parte do passado e, se o seu hardware estiver atendendo a um grupo em uma região específica, convém garantir que seus recursos estejam disponíveis nesse local específico.