Isso tudo depende do que você quer dizer com "desce", os detalhes do que você está executando e fazendo do tendem a ser importantes ao monitorar também ...
A forma mais completa de monitoramento para o seu "serviço" é ter um sistema automatizado externo, fazer o que seus clientes fazem e relatar quando qualquer coisa inesperada ocorrer.
A partir da breve descrição do seu serviço de e-mail, meu primeiro teste de ponta a ponta seria:
- Envie um email
#id via SMTP para uma conta monitor local
- Aguarde o tempo máximo que você deseja tirar.
- Verifique se há email
#id @ monitor no servidor POP.
Essa verificação de um host de monitoramento externo vai captar cerca de 99% dos problemas que podem ocorrer em um sistema de email simples.
Esses monitores de serviços ou transações tendem a ser scripts personalizados escritos em algo como Ruby , Python ou Perl que possuem módulos para implementar facilmente coisas como SMTP ou POP programaticamente. Os scripts, em seguida, geralmente se conectam a uma solução de monitoramento, mas mesmo acionando um simples e-mail ou SMS através de um gateway de um trabalho cron seria suficiente se você quiser algo simples. Se você pagar por uma solução de monitoramento, você geralmente tentará um designer de GUI para o mesmo tipo de monitor.
Claro que no mundo real isso rapidamente se torna mais complicado. Você pode oferecer portas seguras para POP e SMTP que exigem outra verificação. Talvez o IMAP seja adicionado com um pouco de Carddav e Caldav, você pode ter serviços em vários hosts.
O que uma checagem de serviço como a acima não vai te dizer, é onde o problema está, apenas que existe um problema em algum lugar .
Monitoramento de nível inferior
Ao monitorar os componentes individuais do serviço, você basicamente facilita a identificação (ou previsão) de onde está o problema de monitorar antes de fazer qualquer trabalho de perna. Esse tipo de monitoramento de componentes é o que sistemas como Nagios , Zabbix ou grandes, como o Tivoli Monitoring , são bons em.
Esta pode ser uma árvore de coisas em constante expansão, dependendo de quão detalhado você é e de quão complexo é o sistema que suporta seu "serviço"
"Seu serviço de e-mail" depende de
Services: POP:110 SMTP:25
Application: devmail
OS: linux Z
Host: server Y
Components: diskA diskB cpu1 cpu2 memory
Ntwork: ethernetA, Switch B, Router C, Firewall X
Cada componente tem métricas ou um estado sobre o qual você pode relatar.
Externamente
Service:
POP service - Are we accepting connections on 110,995
SMTP service - Are we accepting connections on 25,587
Localmente
Application:
devmail process(es) (is it running, memory, cpu, handles, io)
JMX parameters of the java process (memory, threads, performance, garbage collection)
OS:
Disk, Memory, Cpu, IO
etc...
E se o host de monitoramento cair? Ou é apenas a rede entre o serviço e o monitor.
Geralmente é bom executar as verificações de serviço a partir de dois (ou mais) hosts externos, que são o mais próximo de onde os clientes estão vindo (sem afetar seu monitoramento). Em seguida, execute as verificações localmente no host ou pelo menos na rede local. Dessa forma, você terá uma ideia melhor da maioria dos problemas com base na rede.
- Se um cliente externo falhar, provavelmente uma rede externa.
- Se o cliente local estiver funcionando, mas todos os clientes externos estiverem falhando, provavelmente a rede local.
- Se todos os clientes estiverem falhando, provavelmente um problema local.
Eu vejo muitas pessoas tendendo a construir suas soluções de monitoramento de maneira errada. Eles vêm com um monte de métricas de sistema de nível inferior e 1000 de monitores e níveis que eles acham apropriados para o alarme, quando nenhum, se isso realmente importa. Quero dizer, eles são bons para análise e gerenciamento de capacidade, você pode fazer alguns gráficos de todos esses valores e eles podem ser extremamente úteis, mas não significam muito quando você perdeu x métrica no nível y que significa que ninguém pode receber e-mails.