CPRA - это высокопроизводительная система мониторинга инфраструктуры, предназначенная для платформенных команд, управляющих крупномасштабными микросервисными архитектурами. Построенная на принципах Entity-Component-System (ECS) и теории очередей, CPRA обрабатывает более 1 000 000 одновременных проверок работоспособности с автоматическим масштабированием пула рабочих процессов для достижения целей SLO.
Continuous Pulse and Recovery Agent
Проверяет сервисы, отправляет оповещения и выполняет настроенные вами действия по восстановлению.
CPRa — это самостоятельно размещаемый агент мониторинга и восстановления, написанный на Go. Он по расписанию выполняет проверки работоспособности ваших сервисов, открывает и закрывает инциденты по настраиваемым порогам, отправляет уведомления и выполняет действие по восстановлению — перезапуск контейнера, вызов webhook, перезапуск или масштабирование рабочей нагрузки Kubernetes, перезагрузку экземпляра EC2, перезапуск unit-а systemd — когда сервис отказывает. Он поставляется как единый серверный бинарник со встроенной панелью управления, доступной только для чтения, HTTP API и клиентом командной строки cpractl. Лицензия — MIT.
Документация: ziad-hsn.github.io/cpra — быстрый старт · конфигурация мониторов · драйверы · HTTP API · развёртывание · FAQ
Исходники документации включают актуальные справочные материалы по разработке и явно датированные руководства для более ранних ревизий. Опубликованный сайт обновляется отдельно. Версии и доступность определяют эти границы:
410fbfb и не являются квалификацией выпуска для этой ветки разработки.План выпуска регулирует публикацию. Доступность исходного кода не подтверждает завершённую проверку провайдеров или проверку на выносливость.
Требуются Go 1.25 или новее, Make и Python 3 для исходного рабочего пространства ниже. Репозиторий уже содержит собранные ресурсы панели управления.
Make создаёт игнорируемый bin/cpra-sdk.work для приложения и его локальных модулей SDK, чтобы неопубликованный кандидат 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 для одноразового запуска. Персистентность и восстановление описывают идентичности, неизвестные исходы и полные резервные копии.
Откройте http://localhost:8060, используя настроенные учётные данные API. Настройка управления включает текущие команды SDK, такие как ./bin/cpractl get monitors; эти команды используют стабильные идентификаторы ресурсов. Отсутствующая или некорректная конфигурация останавливает запуск. Пустые конфигурации требуют -allow-empty.
Пример проверяет HTTP-эндпоинт и записывает переходы инцидентов в alerts.jsonl. Каждый монитор может задавать интервал проверки, тайм-аут, порог отказов, порог восстановления, назначения уведомлений и действие по восстановлению. Окна обслуживания подавляют оповещения и восстановление, пока проверки продолжаются; они используют пятиполевые cron-выражения, длительность и часовой пояс IANA.
| Функция | Сборка по умолчанию | Опциональные теги сборки |
|---|---|---|
| Проверки | HTTP, TCP, ICMP, DNS, UDP, TLS, Docker, доступность gRPC-порта | redis postgres mysql mongo rabbitmq kafka |
| Восстановление | Docker, HTTP webhook | 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. Email использует SMTP-ретранслятор с STARTTLS; аутентификация по имени пользователя/паролю SMTP не реализована.
TLS warn_days создаёт жёлтое оповещение и статус монитора «degraded» без запуска восстановления; critical_days проваливает проверку и следует обычной политике восстановления. Приоритет экстренных сообщений Pushover принимает retry и expire в секундах, по умолчанию 60 и 1800. Восстановление Docker сохраняет grace-период остановки демона, когда его тайм-аут опущен.
Проверки MongoDB требуют прямого URI mongodb://. Выбранный драйвер не может ограничить начальное обнаружение mongodb+srv:// крайним сроком проверки, поэтому CPRa отклоняет этот режим. Восстановление Kubernetes поддерживает токен, сертификат и внутрикластерные учётные данные; плагины учётных данных exec в kubeconfig отклоняются, поскольку они могут пережить крайний срок восстановления.
Сервер по умолчанию слушает loopback. Другие адреса привязки требуют токена аутентификации. Храните токен в файле, доступном для чтения учётной записи службы: