FerrisPulse

Cos'è FerrisPulse?

FerrisPulse è un servizio di monitoraggio heartbeat per job in background e automazioni programmate. Invece di verificare se un'app risponde alle richieste HTTP, si aspetta un “ping” di successo dai tuoi cron job, queue worker, backup e altri script.

Se il prossimo heartbeat atteso non arriva entro il cadence configurato, FerrisPulse invia un alert down e poi automaticamente un'email di ripristino quando i ping riprendono. L'obiettivo è trasformare il “silent failure” (un job che smette di funzionare mentre il resto del sistema sembra sano) in un incidente visibile con una timeline degli incidenti.

Caratteristiche Principali

• Monitoraggio heartbeat per cadence di job attesi: FerrisPulse controlla un ping di successo in arrivo su un programma (es. orario o notturno) e tratta i ping mancanti come condizione down.
• URL ping di successo per monitor: copi un URL ping specifico del monitor e lo chiami via HTTP POST solo dopo che il job termina con successo, così l'“heartbeat” riflette il lavoro completato.
• Alert down più email di ripristino: quando manca un heartbeat, FerrisPulse invia un alert down; quando arriva il ping successivo, invia un'email di ripristino e chiude l'incidente.
• Timeline incidenti e storico heartbeat: il dashboard mostra stato, storico heartbeat e finestre di incidente invece di richiedere la ricostruzione dei fallimenti dai log.
• Supporto cadence configurabile e grace period: i monitor includono un intervallo atteso e possono includere un grace period per variabilità di runtime.

Come Usare FerrisPulse

1. Crea un monitor per il job da tracciare, imposta l'intervallo atteso (cadence) e aggiungi un grace period se necessario.
2. Copia l'URL ping del monitor.
3. Nella tua automazione, invia un HTTP POST all'URL ping solo dopo che il job completa con successo.
4. Lascia FerrisPulse in esecuzione; rileverà heartbeat mancanti, invierà alert down e poi email di ripristino quando i ping riprendono.

Casi d'Uso

• Cron job che dovrebbe girare ogni ora: Imposta un monitor orario e pinga l'URL dopo che lo script termina. Se lo script smette di girare silenziosamente per diverse ore, FerrisPulse invia un alert down con il cadence atteso e un link al dashboard.
• Verifica snapshot backup: Per backup notturni, configura un monitor giornaliero ed emetti il ping solo dopo che il backup completa con successo. Questo aiuta a catturare casi in cui il pipeline di backup si blocca senza attivare allarmi di uptime dell'applicazione più ampi.
• Salute queue worker (lavoro completato, non solo salute server): Con queue worker, invia il ping di successo dopo il completamento dell'elaborazione. FerrisPulse può allertare quando il cadence atteso di lavoro riuscito si ferma.
• Pipeline ETL/reporting programmata: Per sync di fatturazione orarie/giornaliere o report, pinga alla fine del workflow. FerrisPulse mantiene una timeline degli incidenti così le esecuzioni perse diventano un evento tracciabile.
• Script di automazione attivati da infrastruttura programmata: Che lo schedule sia interno o esterno, il workflow è lo stesso—invia un ping dopo che lo script completa con successo e lascia che FerrisPulse rilevi il silenzio.

FAQ

Come notifico a FerrisPulse che un job è girato?

Chiami un URL ping HTTP POST specifico del monitor dopo che il job termina con successo. FerrisPulse si aspetta ping sul cadence configurato.

Cosa scatena un alert?

Un alert si scatena quando il prossimo heartbeat/ping atteso non arriva entro il cadence monitorato (con supporto per grace period).

FerrisPulse allerta ripetutamente durante un incidente?

La pagina descrive un alert down per incidente e un'email di ripristino separata quando il ping torna, evitando una tempesta di alert duplicati.

Dove vedo cosa è successo?

FerrisPulse fornisce una vista dashboard che include stato, storico heartbeat, finestre di incidente e comportamento degli alert in un unico posto.

Quali sistemi di job supporta?

Il sito indica che può essere usato con cron, systemd timers e ecosistemi worker/scheduler come BullMQ, Sidekiq, Celery, GitHub Actions, più linguaggi/ambienti come Bash, Node.js, Python e Ruby.

Alternative

• Monitoraggio uptime/controlli di integrità (verifica endpoint HTTP): Utile per la disponibilità dell'app, ma potrebbe non rilevare i “guasti silenziosi” in cui il server web è sano mentre i job in background (cron/codici di coda/backup) non sono in esecuzione.
• Allarmi basati su log: Gli avvisi possono essere attivati da messaggi di errore ex post, ma potrebbe comunque richiedere il controllo attivo dei log e non rilevare le esecuzioni mancanti in modo diretto come un heartbeat.
• Notifiche del programmatore di job (avvisi cron/systemd/GitHub Actions integrati): Alcuni ambienti possono notificare i guasti, ma il flusso di lavoro differisce perché FerrisPulse si basa su un ping di successo esplicito e monitora la cadenza prevista.
• Strumenti di monitoraggio code focalizzati su arretrati/throughput: Questi tracciano il comportamento dei worker e delle code, ma FerrisPulse monitora specificamente la presenza di heartbeat di successo al completamento del lavoro.