CPRA è un sistema di monitoraggio dell'infrastruttura ad alte prestazioni progettato per team di piattaforma che gestiscono architetture di microservizi su larga scala. Basato su architettura Entity-Component-System (ECS) e principi di teoria delle code, CPRA gestisce oltre 1.000.000 di controlli di salute simultanei con scalabilità automatica del pool di worker per raggiungere gli obiettivi SLO.
Continuous Pulse and Recovery Agent
Controlla i servizi, invia avvisi ed esegue le azioni di ripristino che configuri.
CPRa è un agente di monitoraggio e ripristino self-hosted scritto in Go. Esegue
controlli di integrità sui tuoi servizi secondo una pianificazione, apre e chiude
incidenti in base a soglie configurabili, invia notifiche ed esegue un'azione di
ripristino — riavvia un container, chiama un webhook, riavvia o scala un workload
Kubernetes, riavvia un'istanza EC2, riavvia un'unità systemd — quando un servizio
fallisce. Viene distribuito come un singolo binario server con una dashboard
read-only incorporata, un'API HTTP e il client da riga di comando cpractl. È
rilasciato con licenza MIT.
Documentazione: ziad-hsn.github.io/cpra — quickstart · configurazione dei monitor · driver · API HTTP · deployment · FAQ
La sorgente della documentazione include riferimenti allo sviluppo attuale e guide esplicitamente datate per revisioni precedenti. Il sito pubblicato viene aggiornato separatamente. Versioni e disponibilità identifica tali confini:
410fbfb e non costituiscono una qualificazione di rilascio per questo
ramo di sviluppo.Il piano di distribuzione governa la pubblicazione. La disponibilità della sorgente non stabilisce il completamento della verifica dei provider o dell'endurance.
Richiede Go 1.25 o successivo, Make e Python 3 per lo workspace sorgente sottostante. Il repository contiene già gli asset della dashboard compilati.
Make crea un bin/cpra-sdk.work ignorato per l'applicazione e i suoi moduli SDK
locali, così il candidato SDK non pubblicato può essere compilato da questo
checkout. Il modulo di esempio delle integrazioni resta opt-in. Un percorso
GOWORK esplicito o GOWORK=off ha la precedenza; Make non modifica mai il
workspace esterno selezionato.
make
cp examples/monitors.yaml monitors.yaml
# Set the service address in monitors.yaml.
./bin/cpra -yaml monitors.yaml
Per i comandi Go diretti, seleziona esplicitamente il workspace dopo make dev-workspace:
GOWORK="$PWD/bin/cpra-sdk.work" go test ./internal/cpractl/cli
Le build di rilascio ufficiali mantengono GOWORK=off e richiedono dipendenze
dei moduli qualificate separatamente. Le build del workspace locale non
stabiliscono la disponibilità pubblica dei moduli né la prontezza al rilascio.
Lo stato è durevole per impostazione predefinita nella directory di stato utente
della piattaforma (cpractl local paths); i servizi di sistema Linux usano
esplicitamente /var/lib/cpra. Mantieni quella directory tra i riavvii. Un
-data-dir esplicito sovrascrive la configurazione di runtime e il default della
piattaforma. Un ./cpra-data legacy richiede un percorso esplicito o una
migrazione a servizio fermo. Usa -runtime-config examples/runtime-memory.yaml
per un'esecuzione usa e getta. Persistenza e ripristino
descrive le identità, gli esiti sconosciuti e i backup completi.
Apri http://localhost:8060 usando le credenziali API configurate. La
configurazione della gestione abilita i comandi SDK
attuali come ./bin/cpractl get monitors; tali comandi usano ID di risorsa
stabili. Una configurazione mancante o malformata interrompe l'avvio. Le
configurazioni vuote richiedono -allow-empty.
L'esempio controlla un endpoint HTTP e scrive le transizioni degli incidenti su
alerts.jsonl. Ogni monitor può specificare un intervallo di controllo, un
timeout, una soglia di fallimento, una soglia di ripristino, destinazioni di
notifica e un'azione di ripristino. Le finestre di manutenzione sopprimono avvisi
e ripristino mentre i controlli continuano; usano espressioni cron a cinque
campi, una durata e un fuso orario IANA.
| Funzione | Build predefinita | Tag di build opzionali |
|---|---|---|
| Controlli | HTTP, TCP, ICMP, DNS, UDP, TLS, Docker, raggiungibilità porta gRPC | redis postgres mysql mongo rabbitmq kafka |
| Ripristino | Docker, webhook HTTP | kubernetes aws systemd |
| Avvisi | Log, Slack, PagerDuty, email, webhook, Telegram, Discord, Opsgenie, Mattermost, VictorOps, Pushover, Datadog | teams twilio |
make BUILD_TAGS='redis postgres kubernetes'
Il controllo grpc verifica la porta TCP; non chiama il servizio di health gRPC.
I controlli UDP richiedono un payload e una risposta. PagerDuty richiede una
routing key di Events API v2. L'email usa un relay SMTP con STARTTLS;
l'autenticazione SMTP con username/password non è implementata.
Il warn_days di TLS produce un avviso giallo e uno stato del monitor degradato
senza avviare il ripristino; critical_days fa fallire il controllo e segue la
normale policy di ripristino. La priorità emergency di Pushover accetta retry ed
expire in secondi, con default 60 e 1800. Il ripristino Docker preserva lo stop
grace del daemon quando il suo timeout è omesso.
I controlli MongoDB richiedono un URI mongodb:// diretto. Il driver selezionato
non può limitare la discovery iniziale di mongodb+srv:// entro la scadenza del
controllo, quindi CPRa rifiuta quella modalità. Il ripristino Kubernetes supporta
credenziali token, certificato e in-cluster; i plugin di credenziali exec del
kubeconfig vengono rifiutati perché possono sopravvivere alla scadenza del
ripristino.
Il server ascolta su loopback per impostazione predefinita. Altri indirizzi di bind richiedono un token di autenticazione. Mantieni il token in un file leggibile dall'account del servizio: