CPRA es un sistema de monitoreo de infraestructura de alto rendimiento diseñado para equipos de plataforma que gestionan arquitecturas de microservicios a gran escala. Construido sobre la arquitectura Entity-Component-System (ECS) y principios de teoría de colas, CPRA maneja más de 1,000,000 de verificaciones de salud concurrentes con escalado automático del grupo de trabajadores para cumplir los objetivos de SLO.
Agente de Pulso y Recuperación Continuos
Verifica servicios, envía alertas y ejecuta las acciones de recuperación que configures.
CPRa es un agente de monitoreo y recuperación autoalojado escrito en Go. Ejecuta
verificaciones de estado contra tus servicios según una programación, abre y cierra incidentes
según umbrales configurables, envía notificaciones y ejecuta una acción de recuperación — reiniciar un contenedor, llamar a un webhook, reiniciar o escalar una carga de trabajo de Kubernetes, reiniciar una instancia de EC2, reiniciar una unidad de systemd — cuando un servicio
falla. Se distribuye como un único binario de servidor con un panel de control integrado de solo lectura,
una API HTTP y el cliente de línea de comandos cpractl. Tiene licencia MIT.
Documentación: ziad-hsn.github.io/cpra — inicio rápido · configuración de monitores · controladores · API HTTP · despliegue · Preguntas frecuentes
La fuente de documentación incluye referencias de desarrollo actuales y guías con fechas explícitas para revisiones anteriores. El sitio publicado se actualiza por separado. Versiones y disponibilidad identifica esos límites:
410fbfb y no constituyen una cualificación de publicación para esta rama de desarrollo.El plan de publicación rige la publicación. La disponibilidad del código fuente no establece la verificación completa del proveedor ni de resistencia.
Requiere Go 1.25 o posterior, Make y Python 3 para el espacio de trabajo de origen a continuación. El repositorio ya contiene los recursos del panel de control compilados.
Make crea un bin/cpra-sdk.work ignorado para la aplicación y sus módulos
SDK locales, de modo que el candidato del SDK no publicado se puede compilar desde este checkout.
El módulo de ejemplo de integraciones sigue siendo opcional. Una ruta GOWORK explícita o
GOWORK=off tiene prioridad; Make nunca cambia el espacio de trabajo externo seleccionado.
make
cp examples/monitors.yaml monitors.yaml
# Set the service address in monitors.yaml.
./bin/cpra -yaml monitors.yaml
Para comandos Go directos, selecciona el espacio de trabajo explícitamente después de make dev-workspace:
GOWORK="$PWD/bin/cpra-sdk.work" go test ./internal/cpractl/cli
Las compilaciones de publicación oficiales mantienen GOWORK=off y requieren dependencias
de módulos cualificadas por separado. Las compilaciones del espacio de trabajo local no establecen la
disponibilidad pública del módulo ni la preparación para la publicación.
El estado es duradero por defecto en el directorio de estado de usuario de la plataforma (cpractl local paths); los servicios de sistema Linux usan explícitamente /var/lib/cpra. Mantén ese directorio entre reinicios. Un -data-dir explícito anula la configuración en tiempo de ejecución y el valor predeterminado de la plataforma. Un ./cpra-data heredado requiere una ruta explícita o una migración detenida. Usa -runtime-config examples/runtime-memory.yaml para una ejecución desechable. Persistencia y recuperación describe identidades, resultados desconocidos y copias de seguridad completas.
Abre http://localhost:8060 usando las credenciales de API configuradas. La
configuración de gestión habilita comandos actuales del SDK como
./bin/cpractl get monitors; esos comandos usan IDs de recursos estables. Una configuración ausente o mal formada detiene el inicio. Las configuraciones vacías requieren -allow-empty.
El ejemplo verifica un endpoint HTTP y escribe las transiciones de incidentes en alerts.jsonl. Cada monitor puede especificar un intervalo de verificación, tiempo de espera, umbral de fallo, umbral de recuperación, destinos de notificación y una acción de recuperación. Las ventanas de mantenimiento suprimen las alertas y la recuperación mientras las verificaciones continúan; usan expresiones cron de cinco campos, una duración y una zona horaria IANA.
| Función | Compilación predeterminada | Etiquetas de compilación opcionales |
|---|---|---|
| Verificaciones | HTTP, TCP, ICMP, DNS, UDP, TLS, Docker, alcanzabilidad de puerto gRPC | redis postgres mysql mongo rabbitmq kafka |
| Recuperación | Docker, webhook HTTP | kubernetes aws systemd |
| Alertas | Log, Slack, PagerDuty, correo electrónico, webhook, Telegram, Discord, Opsgenie, Mattermost, VictorOps, Pushover, Datadog | teams twilio |
make BUILD_TAGS='redis postgres kubernetes'
La verificación grpc prueba el puerto TCP; no llama al servicio de estado de gRPC. Las verificaciones UDP requieren una carga útil y una respuesta. PagerDuty requiere una clave de enrutamiento de Events API v2. El correo electrónico usa un relé SMTP con STARTTLS; la autenticación con nombre de usuario/contraseña SMTP no está implementada.
El warn_days de TLS produce una alerta amarilla y un estado de monitor degradado sin iniciar la recuperación; critical_days hace fallar la verificación y sigue la política de recuperación normal. La prioridad de emergencia de Pushover acepta retry y expire en segundos, con valores predeterminados de 60 y 1800. La recuperación de Docker conserva la gracia de detención del daemon cuando se omite su tiempo de espera.