Existem boas técnicas para monitorar as tarefas do cron em um cluster?
Estamos começando a usar o cron para iniciar tarefas em intervalos diários. Algumas ideias para verificar informações:
Eu estou querendo saber se as pessoas tiveram sucesso em fazer as coisas separadamente para o cron versus outras coisas, ou se as tarefas foram completamente integradas em uma abordagem diferente. Estou inclinado para o segundo lugar, mas gostaria de saber o que pessoas mais experientes poderiam experimentar.
Além das outras respostas:
Usamos o primeiro para facilitar o Nagios ( Icinga ) para verificar, por exemplo, se o último registro de data e hora escrito é mais antigo do que n horas (mais qualquer lógica que você precise) - sabemos que algo deu errado.
Minha abordagem comum é assim:
Além do acima:
Existem algumas técnicas que você pode usar para monitorar cronjobs.
Para receber alertas de falhas do cronjob:
O sistema que você propõe para registrar as informações em um local "ciente da rede" soa como syslog . O syslog fornece um método simples para criar logs, normalmente gerencia arquivos como / var / log / messages. Você pode fazer personalizações básicas, como escolher quais arquivos recebem as mensagens de log.
O syslog pode ser iniciado em um modo de reconhecimento de rede. Por exemplo, você pode configurá-lo para que um escravo possa se conectar a um mestre:
[root@slave ~]# echo "hello world from slave" | logger -p local1.info
[root@master ~]# tail /var/log/myapp
Jun 29 13:07:01 192.168.1.2 logger: hello world from slave
Para uma distribuição baseada no Red Hat, uma configuração de exemplo é a seguinte:
[root@slave ~]# cat /etc/syslog.conf | grep local1
local1.* @192.168.1.3
[root@master ~]# cat /etc/sysconfig/syslog | grep SYSLOGD_OPTIONS
SYSLOGD_OPTIONS="-m 0 -r"
[root@master ~]# cat /etc/syslog.conf | grep local
local1.* /var/log/myapp
(A primeira linha de configuração redireciona os avisos de log local1. * para @ 192.168.1.3 ("master"). O segundo sinalizador -r da linha SYSLOGD_OPIONS ativa o suporte de rede. Por fim, a terceira linha de configuração direciona as mensagens local1. * recebidas no "mestre" em um arquivo).
A abordagem do syslog é melhor apenas para registrar erros / informações. Os arquivos de log têm menos visibilidade do que o e-mail, então você provavelmente não verá os logs, a menos que algo dê errado.
Se você optar por seguir a rota de estilo syslog, considere também syslog-ng: link .
Claro, você pode obter o melhor das duas técnicas usando os dois. Por exemplo, syslog'ing falhas e sucessos, e apenas mail para falhas.
Eu postei uma resposta semelhante a uma pergunta no StackOverflow ( link )
O Cronitor ( link ) foi uma ferramenta que criei exatamente para essa finalidade. Basicamente, resume-se a ser um farol de rastreamento que usa solicitações http como pings.
No entanto, uma das necessidades que o OP menciona em seu comentário é a necessidade de ser informado quando um trabalho começa a demorar muito para ser executado.
Eu tive essa mesma necessidade e descobri que ferramentas semelhantes não eram compatíveis com esse tipo de monitoramento. O Cronitor resolve isso permitindo que você, opcionalmente, acione um evento inicial e um evento final para acompanhar a duração.
O rastreamento de duração foi essencial para mim porque eu tinha um cronjob que estava programado a cada hora, mas com o passar do tempo comecei a levar mais de uma hora para ser executado. Espero que você ache útil!
Ainda está em desenvolvimento muito pesado no momento em que escrevo isso, mas gostaria de incentivar a análise do link . Foi desenvolvido para resolver os problemas que você descreve. Com uma pequena modificação no comando executado, ele pode registrar a saída e o status de saída dos trabalhos e enviar esses dados de volta a um servidor central em tempo real e enviar alertas via e-mail, SMS e PagerDuty quando um trabalho falhar (status de saída > ) ou não executa quando deveria.
Aviso: Eu sou o desenvolvedor trabalhando nisso.
Isso parece um caso de uso clássico para o AlertGrid .
Não requer instalação, tudo o que você precisa fazer para aproveitar os benefícios dessa ferramenta é:
execution_time ! se my_job não respondeu em X minutos (horas no seu caso) - > enviar SMS para admin
ou
se execution_time > 60 segundos - > enviar e-mail para pessoas interessadas
Na verdade, é tudo. Você pode gerenciar regras de notificação usando um bom editor visual. Você não precisa modificar o código-fonte ou alguns arquivos de configuração se algo mudou. É uma solução centralizada, para que você possa se beneficiar do gerenciamento de regras de um único lugar.
Espero que isso ajude alguém. Há uma conta gratuita fornecida para que você possa testar e usar o AlertGrid se estiver interessado. Eu sou um dos membros da equipe do AlertGrid - sinta-se à vontade para perguntar se você tem algumas perguntas.
Suas tarefas cron já estão registradas via syslog. Esses dados podem ser enviados para um servidor central usando syslogd, outro serviço padrão.
link tem detalhes sobre como definir isso para cima.
eu uso o link apenas adicione & & Enrolar "... seu url cronrat" para seus trabalhos cron. A melhor característica que eu gosto é que você não precisa configurar nada depois de criar uma conta inicial. Cada alerta é ativado e executado no minuto em que você o utiliza. portanto, posso usar qualquer ferramenta automatizada para iniciar meus trabalhos que ainda não existem, diferentemente de alguns serviços em que preciso configurar o trabalho primeiro.
Eu criei o Power Cron depois dessas necessidades específicas. Eu precisava de uma visão centralizada sobre meus jobs do cron e uma noção de dependência entre os jobs de diferentes membros do cluster.
Também precisava de mais informações do que as que encontrei nos registros e adicionei perfil de trabalho.
Nós criamos o PushMon, link , para isso. Digamos que o seu trabalho diário seja executado às 3 da manhã e normalmente termine às 4 da manhã. Você pode configurar uma agenda PushMon de "até às 4:00 todos os dias". Ou um cronograma um pouco mais avançado como "às 4:00 da manhã todos os dias dentro de 1 hora". Tudo o que você precisa fazer é "pingar" o URL do PushMon toda vez que o seu trabalho for executado, e ele irá alertá-lo sobre os pings que estão faltando. Se você tiver certeza de que ocorreu um erro, como quando você pega uma exceção que você não pode manipular, você pode usar o recurso de alerta sob demanda.
Verificações de integridade ( link ) é um serviço & painel construído exatamente para monitorar tarefas agendadas. Está sendo usado na produção, é mantido e aceita contribuições de código.
Funciona da mesma forma que o Cronitor, o Pomo do Inimigo e os amigos: você configura seu cron job para fazer uma solicitação HTTP / HTTPS para um URL especial e exclusivo antes de terminar. O Healthchecks recebe e registra esses pings. Ele verifica constantemente se os pings chegam nos intervalos esperados. Quando detecta um problema, ele envia uma notificação. Os métodos de notificação suportados são email, webhooks, Slack, Telegram, Discord, SMS, Pushover, Pusbullet, PagerDuty, PagerTree, HipChat, VictorOps, OpsGenie.
Você pode configurar tudo isso e hospedar-se, mas, como em qualquer serviço da Web, é necessário configurar o nome de domínio, o certificado, configurar o proxy reverso HTTP, configurar backups de banco de dados, etc. A maneira de começar a correr é usar esta versão adaptada ao Heroku: link . Eu conheço pessoas que executam este projeto e o usam para monitorar centenas de serviços.
Aviso de isenção de responsabilidade: sou o autor e também executo Healthchecks como um serviço hospedado no link
Tags cron monitoring