CPRA ist ein Hochleistungs-Infrastrukturüberwachungssystem, das für Plattformteams entwickelt wurde, die groß angelegte Microservice-Architekturen verwalten. Basierend auf Entity-Component-System (ECS)-Architektur und Warteschlangentheorie-Prinzipien bewältigt CPRA über 1.000.000 gleichzeitige Health Checks mit automatischer Worker-Pool-Skalierung, um SLO-Ziele zu erreichen.
Continuous Pulse and Recovery Agent
Prüft Dienste, sendet Warnungen und führt die von Ihnen konfigurierten Wiederherstellungsaktionen aus.
CPRa ist ein selbst gehosteter Monitoring- und Wiederherstellungsagent, geschrieben in Go. Er führt in einem Zeitplan Gesundheitsprüfungen gegen Ihre Dienste aus, eröffnet und schließt Incidents anhand konfigurierbarer Schwellenwerte, versendet Benachrichtigungen und führt eine Wiederherstellungsaktion aus — einen Container neu starten, einen Webhook aufrufen, eine Kubernetes-Workload neu starten oder skalieren, eine EC2-Instanz neu booten, eine systemd-Unit neu starten — wenn ein Dienst ausfällt. Er wird als einzelne Server-Binary mit einem eingebetteten schreibgeschützten Dashboard, einer HTTP-API und dem Kommandozeilen-Client cpractl ausgeliefert. Er ist MIT-lizenziert.
Dokumentation: ziad-hsn.github.io/cpra — Quickstart · Monitor-Konfiguration · Treiber · HTTP-API · Bereitstellung · FAQ
Die Dokumentationsquelle enthält aktuelle Entwicklungsreferenzen und explizit datierte Anleitungen für frühere Revisionen. Die veröffentlichte Website wird separat aktualisiert. Versionen und Verfügbarkeit benennt diese Grenzen:
410fbfb
Revision und sind keine Release-Qualifizierung für diesen Entwicklungszweig.Der Shipping-Plan regelt die Veröffentlichung. Die Verfügbarkeit des Quellcodes belegt keine abgeschlossene Provider- oder Ausdauerverifizierung.
Erfordert Go 1.25 oder neuer, Make und Python 3 für den folgenden Source-Workspace. Das Repository enthält bereits die gebauten Dashboard-Assets.
Make erstellt ein ignoriertes bin/cpra-sdk.work für die Anwendung und ihre lokalen
SDK-Module, sodass der unveröffentlichte SDK-Kandidat aus diesem Checkout gebaut werden kann.
Das Integrations-Beispielmodul bleibt optional. Ein expliziter GOWORK-Pfad oder
GOWORK=off hat Vorrang; Make ändert niemals den ausgewählten externen Workspace.
make
cp examples/monitors.yaml monitors.yaml
# Set the service address in monitors.yaml.
./bin/cpra -yaml monitors.yaml
Für direkte Go-Befehle wählen Sie den Workspace nach make dev-workspace explizit aus:
GOWORK="$PWD/bin/cpra-sdk.work" go test ./internal/cpractl/cli
Offizielle Release-Builds behalten GOWORK=off bei und erfordern separat qualifizierte
Modulabhängigkeiten. Lokale Workspace-Builds belegen keine öffentliche Modulverfügbarkeit
oder Release-Bereitschaft.
Der Zustand ist standardmäßig dauerhaft im Benutzerzustandsverzeichnis der Plattform (cpractl local paths); Linux-Systemdienste verwenden explizit /var/lib/cpra. Behalten Sie dieses Verzeichnis über Neustarts hinweg bei. Ein explizites -data-dir überschreibt die Laufzeitkonfiguration und den Plattformstandard. Ein Legacy-./cpra-data erfordert einen expliziten Pfad oder eine gestoppte Migration. Verwenden Sie -runtime-config examples/runtime-memory.yaml für einen Wegwerf-Lauf. Persistenz und Wiederherstellung beschreibt Identitäten, unbekannte Ergebnisse und vollständige Backups.
Öffnen Sie http://localhost:8060 mit den konfigurierten API-Anmeldedaten. Das
Management-Setup aktiviert aktuelle SDK-Befehle wie
./bin/cpractl get monitors; diese Befehle verwenden stabile Ressourcen-IDs. Fehlende oder fehlerhafte Konfiguration stoppt den Start. Leere Konfigurationen erfordern -allow-empty.
Das Beispiel prüft einen HTTP-Endpunkt und schreibt Incident-Übergänge in alerts.jsonl. Jeder Monitor kann ein Prüfintervall, einen Timeout, einen Fehlerschwellenwert, einen Wiederherstellungsschwellenwert, Benachrichtigungsziele und eine Wiederherstellungsaktion angeben. Wartungsfenster unterdrücken Warnungen und Wiederherstellung, während Prüfungen weiterlaufen; sie verwenden Cron-Ausdrücke mit fünf Feldern, eine Dauer und eine IANA-Zeitzone.
| Funktion | Standard-Build | Optionale Build-Tags |
|---|---|---|
| Prüfungen | HTTP, TCP, ICMP, DNS, UDP, TLS, Docker, gRPC-Port-Erreichbarkeit | redis postgres mysql mongo rabbitmq kafka |
| Wiederherstellung | Docker, HTTP-Webhook | kubernetes aws systemd |
| Warnungen | Log, Slack, PagerDuty, E-Mail, Webhook, Telegram, Discord, Opsgenie, Mattermost, VictorOps, Pushover, Datadog | teams twilio |
make BUILD_TAGS='redis postgres kubernetes'
Die grpc-Prüfung testet den TCP-Port; sie ruft nicht den gRPC-Health-Service auf. UDP-Prüfungen erfordern eine Nutzlast und eine Antwort. PagerDuty erfordert einen Events-API-v2-Routing-Key. E-Mail verwendet einen SMTP-Relay mit STARTTLS; SMTP-Benutzername/Passwort-Authentifizierung ist nicht implementiert.
TLS warn_days erzeugt eine gelbe Warnung und einen degradierten Monitor-Status, ohne die Wiederherstellung zu starten; critical_days lässt die Prüfung fehlschlagen und folgt der normalen Wiederherstellungsrichtlinie. Pushover-Emergency-Priorität akzeptiert retry und expire in Sekunden, standardmäßig 60 und 1800. Die Docker-Wiederherstellung behält die Stop-Grace des Daemons bei, wenn ihr Timeout weggelassen wird.
MongoDB-Prüfungen erfordern eine direkte mongodb://-URI. Der ausgewählte Treiber kann die anfängliche mongodb+srv://-Erkennung nicht durch die Prüfungs-Deadline begrenzen, daher lehnt CPRa diesen Modus ab. Die Kubernetes-Wiederherstellung unterstützt Token-, Zertifikat- und In-Cluster-Anmeldedaten; kubeconfig-Exec-Credential-Plugins werden abgelehnt, da sie die Wiederherstellungs-Deadline überleben können.