CPRA est un système de surveillance d'infrastructure haute performance conçu pour les équipes de plateforme gérant des architectures de microservices à grande échelle. Basé sur l'architecture Entity-Component-System (ECS) et les principes de la théorie des files d'attente, CPRA gère plus de 1 000 000 de contrôles de santé simultanés avec une mise à l'échelle automatique du pool de travailleurs pour atteindre les objectifs SLO.
Continuous Pulse and Recovery Agent
Vérifie les services, envoie des alertes et exécute les actions de rétablissement que vous configurez.
CPRa est un agent de surveillance et de rétablissement auto-hébergé écrit en Go. Il exécute
des contrôles de santé sur vos services selon un calendrier, ouvre et ferme des incidents
selon des seuils configurables, envoie des notifications et exécute une action de rétablissement — redémarrer un conteneur, appeler un webhook, redémarrer ou mettre à l'échelle une charge de travail Kubernetes, redémarrer une instance EC2, redémarrer une unité systemd — lorsqu'un service
échoue. Il est livré sous forme d'un binaire serveur unique avec un tableau de bord en lecture seule intégré,
une API HTTP et le client en ligne de commande cpractl. Il est sous licence MIT.
Documentation : ziad-hsn.github.io/cpra — démarrage rapide · configuration des moniteurs · pilotes · API HTTP · déploiement · FAQ
La source de la documentation inclut les références de développement actuelles et des guides explicitement datés pour les révisions antérieures. Le site publié est mis à jour séparément. Versions et disponibilité identifie ces frontières :
410fbfb
et ne constituent pas une qualification de publication pour cette branche de développement.Le plan de livraison régit la publication. La disponibilité de la source n'établit pas une vérification complète des fournisseurs ou d'endurance.
Nécessite Go 1.25 ou ultérieur, Make et Python 3 pour l'espace de travail source ci-dessous. Le dépôt contient déjà les ressources du tableau de bord compilées.
Make crée un bin/cpra-sdk.work ignoré pour l'application et ses modules
SDK locaux, afin que le candidat SDK non publié puisse être compilé depuis ce checkout.
Le module d'exemple d'intégrations reste optionnel. Un chemin GOWORK explicite ou
GOWORK=off est prioritaire ; Make ne modifie jamais l'espace de travail externe sélectionné.
make
cp examples/monitors.yaml monitors.yaml
# Set the service address in monitors.yaml.
./bin/cpra -yaml monitors.yaml
Pour les commandes Go directes, sélectionnez explicitement l'espace de travail après make dev-workspace :
GOWORK="$PWD/bin/cpra-sdk.work" go test ./internal/cpractl/cli
Les builds de publication officiels conservent GOWORK=off et nécessitent des
dépendances de module qualifiées séparément. Les builds d'espace de travail locaux n'établissent pas la disponibilité publique des modules ni l'état de préparation à la publication.
L'état est durable par défaut dans le répertoire d'état utilisateur de la plateforme (cpractl local paths) ; les services système Linux utilisent explicitement /var/lib/cpra. Conservez ce répertoire entre les redémarrages. Un -data-dir explicite remplace la configuration d'exécution et la valeur par défaut de la plateforme. Un ./cpra-data hérité nécessite un chemin explicite ou une migration à l'arrêt. Utilisez -runtime-config examples/runtime-memory.yaml pour une exécution jetable. Persistance et récupération décrit les identités, les résultats inconnus et les sauvegardes complètes.
Ouvrez http://localhost:8060 en utilisant les identifiants API configurés. La
configuration de la gestion active les commandes SDK actuelles telles
que ./bin/cpractl get monitors ; ces commandes utilisent des identifiants de ressources stables. Une configuration manquante ou mal formée arrête le démarrage. Les configurations vides nécessitent -allow-empty.
L'exemple vérifie un point de terminaison HTTP et écrit les transitions d'incident dans alerts.jsonl. Chaque moniteur peut spécifier un intervalle de vérification, un délai d'attente, un seuil d'échec, un seuil de rétablissement, des destinations de notification et une action de rétablissement. Les fenêtres de maintenance suppriment les alertes et le rétablissement pendant que les vérifications continuent ; elles utilisent des expressions cron à cinq champs, une durée et un fuseau horaire IANA.
| Fonction | Build par défaut | Tags de build optionnels |
|---|---|---|
| Vérifications | HTTP, TCP, ICMP, DNS, UDP, TLS, Docker, accessibilité du port gRPC | redis postgres mysql mongo rabbitmq kafka |
| Rétablissement | Docker, webhook HTTP | kubernetes aws systemd |
| Alertes | Log, Slack, PagerDuty, email, webhook, Telegram, Discord, Opsgenie, Mattermost, VictorOps, Pushover, Datadog | teams twilio |
make BUILD_TAGS='redis postgres kubernetes'
La vérification grpc teste le port TCP ; elle n'appelle pas le service de santé gRPC. Les vérifications UDP nécessitent une charge utile et une réponse. PagerDuty nécessite une clé de routage Events API v2. L'email utilise un relais SMTP avec STARTTLS ; l'authentification par nom d'utilisateur/mot de passe SMTP n'est pas implémentée.
Le warn_days de TLS produit une alerte jaune et un statut de moniteur dégradé sans déclencher de rétablissement ; critical_days fait échouer la vérification et suit la politique de rétablissement normale. La priorité d'urgence de Pushover accepte retry et expire en secondes, avec des valeurs par défaut de 60 et 1800. Le rétablissement Docker préserve le délai de grâce d'arrêt du démon lorsque son délai d'attente est omis.