
CPRA는 대규모 마이크로서비스 아키텍처를 관리하는 플랫폼 팀을 위해 설계된 고성능 인프라 모니터링 시스템입니다. ECS(Entity-Component-System) 아키텍처와 대기열 이론(Queueing Theory) 원리를 기반으로 구축된 CPRA는 SLO 목표를 충족하기 위해 자동 워커 풀 확장을 통해 1,000,000개 이상의 동시 상태 점검(health check)을 처리합니다.
Continuous Pulse and Recovery Agent
서비스를 점검하고, 알림을 보내며, 설정한 복구 작업을 실행합니다.
CPRa는 Go로 작성된 자체 호스팅 모니터링 및 복구 에이전트입니다. 일정에 따라
서비스에 대한 상태 점검을 실행하고, 설정 가능한 임계값에 따라 인시던트를
열고 닫으며, 알림을 보내고, 서비스 장애 시 복구 작업 — 컨테이너 재시작,
웹훅 호출, Kubernetes 워크로드 재시작 또는 스케일링, EC2 인스턴스 재부팅,
systemd 유닛 재시작 — 을 실행합니다. 임베디드 읽기 전용 대시보드, HTTP API,
그리고 cpractl 명령줄 클라이언트를 갖춘 단일 서버 바이너리로 제공됩니다.
MIT 라이선스입니다.
문서: ziad-hsn.github.io/cpra — 빠른 시작 · 모니터 구성 · 드라이버 · HTTP API · 배포 · FAQ
문서 소스에는 현재 개발 참조와 이전 리비전에 대한 명시적으로 날짜가 표기된 가이드가 포함되어 있습니다. 게시된 사이트는 별도로 업데이트됩니다. 버전 및 가용성에서 그 경계를 확인할 수 있습니다:
410fbfb
리비전을 설명하며, 이 개발 브랜치의 릴리스 자격 검증은 아닙니다.출시 계획이 게시를 관리합니다. 소스 가용성이 완료된 공급자 또는 내구성 검증을 입증하지는 않습니다.
아래 소스 워크스페이스에는 Go 1.25 이상, Make, Python 3가 필요합니다. 저장소에는 이미 빌드된 대시보드 자산이 포함되어 있습니다.
Make는 애플리케이션과 로컬 SDK 모듈을 위해 무시되는 bin/cpra-sdk.work를
생성하므로, 이 체크아웃에서 미게시 SDK 후보를 빌드할 수 있습니다.
통합 예제 모듈은 여전히 옵트인 방식입니다. 명시적인 GOWORK 경로 또는
GOWORK=off가 우선하며, Make는 선택된 외부 워크스페이스를 절대 변경하지
않습니다.
make
cp examples/monitors.yaml monitors.yaml
# Set the service address in monitors.yaml.
./bin/cpra -yaml monitors.yaml
직접 Go 명령을 사용하려면 make dev-workspace 후 워크스페이스를 명시적으로
선택하세요:
GOWORK="$PWD/bin/cpra-sdk.work" go test ./internal/cpractl/cli
공식 릴리스 빌드는 GOWORK=off를 유지하며 별도로 자격을 갖춘 모듈
의존성이 필요합니다. 로컬 워크스페이스 빌드는 공개 모듈 가용성이나 릴리스
준비 상태를 입증하지 않습니다.
상태는 기본적으로 플랫폼의 사용자 상태 디렉터리(cpractl local paths)에
영속 저장되며, Linux 시스템 서비스는 명시적으로 /var/lib/cpra를 사용합니다.
재시작 간에도 해당 디렉터리를 유지하세요. 명시적인 -data-dir는 런타임
구성과 플랫폼 기본값을 재정의합니다. 레거시 ./cpra-data는 명시적 경로
또는 중지된 마이그레이션이 필요합니다. 일회성 실행에는
-runtime-config examples/runtime-memory.yaml을 사용하세요.
영속성 및 복구에서 ID, 알 수 없는 결과, 전체 백업을
설명합니다.
구성된 API 자격 증명을 사용하여 http://localhost:8060을 여세요.
관리 설정은 ./bin/cpractl get monitors와 같은
현재 SDK 명령을 활성화하며, 해당 명령은 안정적인 리소스 ID를 사용합니다.
구성이 없거나 잘못된 경우 시작이 중단됩니다. 빈 구성에는 -allow-empty가
필요합니다.
예제는 HTTP 엔드포인트를 점검하고 인시던트 전환을 alerts.jsonl에
기록합니다. 각 모니터는 점검 간격, 타임아웃, 실패 임계값, 복구 임계값,
알림 대상, 복구 작업을 지정할 수 있습니다. 유지보수 기간은 점검이 계속되는
동안 알림과 복구를 억제하며, 5필드 cron 표현식, 기간, IANA 시간대를
사용합니다.
| 기능 | 기본 빌드 | 선택적 빌드 태그 |
|---|---|---|
| 점검 | HTTP, TCP, ICMP, DNS, UDP, TLS, Docker, gRPC 포트 도달 가능성 | redis postgres mysql mongo rabbitmq kafka |
| 복구 | Docker, HTTP 웹훅 | kubernetes aws systemd |
| 알림 | Log, Slack, PagerDuty, email, webhook, Telegram, Discord, Opsgenie, Mattermost, VictorOps, Pushover, Datadog | teams twilio |
make BUILD_TAGS='redis postgres kubernetes'
grpc 점검은 TCP 포트를 테스트하며 gRPC 상태 서비스를 호출하지 않습니다.
UDP 점검에는 페이로드와 응답이 필요합니다. PagerDuty에는 Events API v2
라우팅 키가 필요합니다. 이메일은 STARTTLS를 사용하는 SMTP 릴레이를
사용하며, SMTP 사용자 이름/비밀번호 인증은 구현되어 있지 않습니다.
TLS warn_days는 복구를 시작하지 않고 노란색 알림과 저하된 모니터 상태를
생성하며, critical_days는 점검을 실패시키고 일반 복구 정책을 따릅니다.
Pushover 긴급 우선순위는 retry와 expire를 초 단위로 받으며, 기본값은
60과 1800입니다. Docker 복구는 타임아웃이 생략된 경우 데몬의 중지 유예
시간을 유지합니다.
MongoDB 점검에는 직접 mongodb:// URI가 필요합니다. 선택된 드라이버는
초기 mongodb+srv:// 검색을 점검 기한으로 제한할 수 없으므로 CPRa는 해당
모드를 거부합니다. Kubernetes 복구는 토큰, 인증서, 인클러스터 자격 증명을
지원하며, kubeconfig exec 자격 증명 플러그인은 복구 기한을 초과할 수 있어
거부됩니다.
서버는 기본적으로 루프백에서 수신 대기합니다. 다른 바인드 주소에는 인증 토큰이 필요합니다. 토큰은 서비스 계정이 읽을 수 있는 파일에 보관하세요:
./bin/cpra -yaml monitors.yaml -web.addr 0.0.0.0:8060 -web.auth-file /run/secrets/cpra-token
./bin/cpractl --server https://monitor.example.com --token-file /run/secrets/cpra-token get monitors
브라우저 로그인은 사용자 이름 cpra와 토큰을 비밀번호로 사용합니다.
API는 Bearer 토큰을 허용합니다. 서버와 CLI는 CPRA_AUTH_TOKEN과
CPRA_AUTH_TOKEN_FILE도 읽습니다. 원격 접근에는 HTTPS 리버스 프록시가
필요하며, 내장 리스너는 HTTP를 제공합니다.
매니페스트는 프로세스 계정의 권한으로 점검, 알림 대상, 복구 작업을
승인합니다. 신뢰할 수 있는 구성만 사용하세요. -ssrf-protect는 연결 시점에
비공개 HTTP 대상을 차단하며, 다른 프로토콜이나 로컬 작업을 제한하지는
않습니다. 프로파일링은 옵트인 방식입니다. 자격 증명이 포함된 토큰 파일과
매니페스트는 버전 관리 외부에 보관하세요.
/api/v2/healthz는 라이브니스를 보고합니다. /api/v2/readyz는 초기화된
승인, 컨트롤러 진행, 사용 가능한 스토리지를 요구하며, 명시적으로 빈
구성은 준비 상태가 될 수 있습니다. 대시보드 프로젝션 최신성은 별도로
보고됩니다. 공급자 장애가 프로세스를 죽은 상태로 만들지는 않습니다.monitor_id 값을 추가합니다. 페이지는 제한됩니다. /api/v1/history는
인시던트 및 작업 이벤트를 30일간 보관하며, /api/v1/state는 영속성과
알 수 없는 작업을 노출하고, /api/v1/slo는 측정된 지연 분포를
노출합니다. 모두 읽기 전용이며 기존 인증을 사용합니다.make check
make test-all-drivers
대시보드를 재빌드하려면 Node.js 24.21.0, pnpm 11.22.0, Python 3가 필요합니다:
make dashboard-build dashboard-check
make release VERSION=v0.1.0
기록된 릴리스 레시피는 체크섬으로 고정된 Go 1.27.1 컴파일러와 명시적 소스 아이덴티티를 사용합니다. Linux, macOS, Windows의 amd64/arm64용 스트립되지 않은 최적화된 서버/클라이언트 아카이브, Linux 패키지, 소스 아카이브, 증거 인벤토리를 생성합니다. Go 1.25 호환성은 별도의 테스트입니다. 네이티브 실행 게이트가 각 플랫폼의 자격을 검증하며, 성공적인 크로스 빌드만으로는 지원이 입증되지 않습니다.
버전이 지정된 설치는 Go와 커밋된 임베디드 자산만 필요합니다: