Tecniche per monitorare le attività cron?

Esistono buone tecniche per monitorare le attività cron su un cluster?

Stiamo iniziando a utilizzare cron per avviare attività a intervalli giornalieri. Alcune idee per verificare le informazioni:

1. Aggiungi una gestione speciale delle applicazioni che registra le informazioni in un luogo "a conoscenza della rete", come un DB
2. Costruire un sistema di file di registro che trasferisca periodicamente il registro cron su un punto centrale per l'elaborazione / interrogazione (insieme ad altri possibili file di registro)

Mi chiedo se le persone abbiano avuto successo nel fare le cose separatamente per cron rispetto ad altre cose, o se i compiti fossero stati completamente integrati in un approccio diverso. Mi sto avvicinando al n. 2, ma mi piacerebbe sapere quali persone più esperte potrebbero provare.

Oltre alle altre risposte:

• lasciare che il lavoro scriva un timestamp in un file al termine insieme al valore restituito dal lavoro effettivo
• propagare il valore restituito al chiamante originale

Usiamo il primo per rendere più semplice il controllo di Nagios ( Icinga ), ad esempio se l'ultimo timestamp scritto è più vecchio di n ore (più qualunque logica abbiate bisogno) - sappiamo che qualcosa è andato storto.

Il mio approccio comune è quindi:

• Non produrre alcuno stdout quando l'applicazione cronizzata viene completata correttamente.
• Non reindirizzare alcun output a / dev / null.
• Produce un output stderr significativo quando qualcosa va storto.
• Impostare un indirizzo $ MAILTO nel crontab per inviare l'output dell'errore al team richiesto.

Oltre a quanto sopra:

• Chiama "logger" insieme a scrivere a stderr quando qualcosa va storto. Configurare syslog per inoltrare ulteriormente a un host centrale, noto anche come "loghost". (Logger utilizzerà la funzione "user.notice" per impostazione predefinita, ma è possibile modificarlo.)

Ci sono un paio di tecniche che potresti usare per monitorare cronjobs.

Per ricevere avvisi di errori cronjob:

• Usa la funzione MAILTO = cron standard. Se un cronjob produce output su STDERR, verrà inviato all'indirizzo che scegli.
• Per tenere traccia e gestire le mail cron, puoi indirizzarle in un sistema di ticket.

Il sistema che proponi di registrare le informazioni in un luogo "network aware" suona come syslog . syslog fornisce un metodo semplice per creare registri, normalmente gestisce file come / var / log / message. È possibile effettuare personalizzazioni di base, come scegliere quali file ricevono i messaggi di registro.

Syslog può essere avviato in modalità compatibile con la rete. Ad esempio, è possibile configurarlo in modo che uno slave possa accedere a un master:

[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

Per una distribuzione basata su Red Hat, una configurazione di esempio è la seguente:

[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

(La prima riga di configurazione reindirizza local1. * Gli avvisi di registro su @ 192.168.1.3 ("master"). La seconda flag SYSLOGD_OPIONS -r attiva il supporto di rete. Infine, la terza riga di configurazione dirige local1. * Messaggi ricevuti su "master" in un file).

L'approccio syslog è migliore solo per la registrazione di errori / informazioni. I file di registro hanno meno visibilità dell'e-mail, quindi probabilmente non guarderai i registri a meno che qualcosa non sia andato storto.

Se si sceglie di seguire il percorso in stile syslog, considerare anche syslog-ng: http://freshmeat.net/projects/syslog-ng/ .

Ovviamente, puoi ottenere il meglio da entrambe le tecniche usando entrambe. Ad esempio, syslog'ing sia i fallimenti che i successi, e solo la posta per i guasti.

Ho pubblicato una risposta simile a una domanda su StackOverflow ( /programming/21025495/system-for-monitoring-cron-jobs-and-automated-tasks )

Cronitor ( https://cronitor.io ) era uno strumento che ho creato esattamente per questo scopo. Fondamentalmente si riduce a essere un segnale di tracciamento che utilizza richieste HTTP come ping.

Tuttavia, una delle esigenze che il PO menziona nel suo commento deve essere informata quando un lavoro inizia a richiedere troppo tempo per essere eseguito.

Avevo la stessa necessità e ho scoperto che strumenti simili non supportavano facilmente questo tipo di monitoraggio. Cronitor risolve questo problema consentendo di attivare facoltativamente un evento di inizio e un evento di fine per tenere traccia della durata.

Il monitoraggio della durata è stato un must per me perché avevo un cronjob programmato ogni ora, ma nel tempo ho iniziato a impiegare più di un'ora per l'esecuzione. Spero che lo trovi utile!

È ancora in fase di sviluppo piuttosto pesante al momento in cui scrivo questo, ma incoraggerei a dare un'occhiata a https://github.com/jamesrwhite/minicron . È stato sviluppato per risolvere i problemi che descrivi. Con una leggera modifica al comando eseguito, è possibile registrare l'output e lo stato di uscita dei lavori e inviare tali dati a un server centrale in tempo reale e inviare avvisi via e-mail, SMS e PagerDuty quando un lavoro non riesce (stato di uscita> 0) o non viene eseguito quando dovrebbe.

Disclaimer: sono lo sviluppatore che ci sta lavorando.

Sembra un caso d'uso classico per AlertGrid .

Non richiede installazione, tutto ciò che devi fare per trarre vantaggio da questo strumento è:

1. invia Signal ad AlertGrid ogni volta che il tuo cron job ha finito di funzionare (questo può essere fatto da un'API estremamente semplice, il segnale è solo una richiesta HTTP). Puoi anche inviare alcuni parametri comeexecution_time !
2. impostare regole di notifica come folllowing:

se my_job non ha risposto in X minuti (ore nel tuo caso) -> invia SMS all'amministratore

o

se tempo_esecuzione> 60 secondi -> invia e-mail alle persone interessate

In realtà è tutto. Puoi gestire le regole di notifica usando un piacevole editor visivo. Non è necessario modificare il codice sorgente o alcuni file di configurazione se qualcosa è cambiato. È una soluzione centralizzata, quindi puoi trarre vantaggio dalla gestione delle regole da un unico posto.

Spero che questo aiuti qualcuno. È disponibile un account gratuito in modo da poter testare e utilizzare AlertGrid se sei interessato. Sono uno dei membri del team AlertGrid - non esitare a chiedere se hai qualche domanda.

I tuoi lavori cron sono già registrati tramite syslog. Tali dati possono essere inviati a un server centrale utilizzando syslogd, un altro servizio standard.

http://www.debuntu.org/how-to-remote-syslog-logging-on-debian-and-ubuntu/ ha dettagli su come impostare questo.

io uso http://cronrat.com basta aggiungere && curl "... il tuo cronrat url" ai tuoi lavori cron. La migliore caratteristica che mi piace è che non è necessario impostare nulla dopo aver creato l'account iniziale. Ogni avviso è attivo e attivo nel momento in cui lo si utilizza. quindi posso utilizzare qualsiasi strumento automatico per iniziare i miei lavori che non esiste ancora, a differenza di alcuni servizi in cui devo prima impostare un lavoro.

Ho creato Power Cron dopo queste precise esigenze. Avevo bisogno di una visione centralizzata dei miei lavori cron e di una nozione di dipendenza tra i lavori dei diversi membri del cluster.

Avevo anche bisogno di più informazioni di quelle che potevo trovare nei registri e ho aggiunto la profilazione del lavoro.

Per questo abbiamo creato PushMon, http://www.pushmon.com . Supponi che il tuo lavoro quotidiano venga eseguito alle 3 del mattino e termina normalmente alle 4 del mattino. È possibile impostare un programma PushMon di "entro le 4:00 tutti i giorni". O un programma un po 'più avanzato come "entro le 4:00 ogni giorno entro 1 ora". Tutto quello che devi fare è "pingare" l'URL PushMon ogni volta che il tuo lavoro viene eseguito e ti avviserà dei ping mancanti. Se si è certi che si sia verificato un errore, ad esempio quando si rileva un'eccezione che non è possibile gestire, è possibile utilizzare la funzione di avviso su richiesta.

Healthchecks ( https://github.com/healthchecks/healthchecks/ ) è un servizio e una dashboard creati esattamente per monitorare i lavori cron. Viene utilizzato in produzione, viene mantenuto e accetta contributi in codice.

Funziona in modo simile a Cronitor, Snitch di Dead Man e amici: hai impostato il tuo lavoro cron per fare una richiesta HTTP / HTTPS a un URL speciale e unico prima che finisca. Healthchecks riceve e registra questi ping. Controlla costantemente se i ping arrivano agli intervalli previsti. Quando rileva un problema, ti invia una notifica. I metodi di notifica supportati sono e-mail, webhook, Slack, Telegram, Discord, SMS, Pushover, Pusbullet, PagerDuty, PagerTree, HipChat, VictorOps, OpsGenie.

Puoi impostare tutto e ospitare te stesso, ma, come con qualsiasi servizio web, ci vuole un certo sforzo per impostare il nome di dominio, il certificato, configurare il proxy inverso HTTP, impostare i backup del database ecc. Un modo ragionevolmente semplice per ottenere correre è usare questa versione adattata per Heroku: https://github.com/iphoting/healthchecks . Conosco persone che gestiscono questo progetto e lo usano per monitorare centinaia di servizi.

Disclaimer: sono l'autore e gestisco anche Healthchecks come servizio ospitato su https://healthchecks.io