Спасибо за отличный вопрос. Да, можно. nxs-anomaly умеет при инциденте сам отправлять запрос в ваш сервис. Для этого в цепочку эскалации (escalation chain) добавляется шаг TRIGGER_WEBHOOK. Он описан, просто не на видном месте: в CONFIGURATION.md, раздел 4, таблица шагов и абзацы про TRIGGER_WEBHOOK ниже.
Как это работает:
Когда эскалация доходит до этого шага, nxs-anomaly шлёт POST на webhook_url. Если сервис не ответил, запрос повторяется.
Тело запроса - JSON в формате вебхука Alertmanager (version: “4”), а не текст по шаблону. В нём status, alerts[].labels (там alertname, severity), annotations.summary с заголовком инцидента и groupKey, где лежит ID группы алертов (delivery_adapters.go:1179). Свой шаблон тела задать нельзя. Если ваш сервис уже умеет принимать вебхуки Alertmanager, он примет и этот.
Для авторизации есть headers. Секрет лучше передавать ссылкой на переменную окружения, в production-профиле так обязательно: {“kind”: “TRIGGER_WEBHOOK”, “webhook_url”: “https://my-service/hook”, “headers”: {“Authorization”: “env:NXS_ANOMALY_MYSVC_AUTH”}}
В production-профиле включена защита от SSRF, и внутренние адреса (частные сети, localhost) запрещены. Внутренний сервис нужно разрешить через NXS_ANOMALY_BLOCK_PRIVATE_WEBHOOKS_EXCEPT (подробнее в SECURITY_PROFILE.md).
В UI шаг выглядит как «Вызвать исходящий вебхук» в редакторе цепочки. Через API или Terraform он задаётся как шаг цепочки.
ACK из вашего сервиса: да, это работает. ID группы сервис берёт из groupKey в полученном вебхуке. Затем вызывает POST /api/v1/alert-groups/{id}/acknowledge (или /resolve) с API-ключом, у которого роль не ниже responder.
Спасибо за отличный вопрос. С версии 1.3.0 предусмотрен внешний heartbeat и отдельный набор алертов «процесс отсутствует». Мы рекомендуем три независимых уровня контроля:
Heartbeat прямо от воркера, без Prometheus: задаётся переменная NXS_ANOMALY_WORKER_HEARTBEAT_URL, туда подходит адрес проверки во внешнем сервисе, например healthchecks.io. После каждого успешного цикла, воркер делает GET на этот адрес, но не чаще раза в минуту. Если цикл упал из-за базы, пинга не будет. Поэтому одна такая проверка ловит падение воркера, недоступность PostgreSQL и обрыв сети между ними.
Prometheus-алерты на отсутствие процесса, а не на его деградацию. Правила лежат в prometheus-rules.yaml. В Helm они включаются через prometheusRule.enabled и serviceMonitor.enabled.
Отдельная маршрутизация в Alertmanager: эти алерты отправляются отдельным ресивером напрямую, в Telegram, почту или SMS, а не в nxs-anomaly.
Также у API и воркера есть эндпоинты /live и /ready. На воркерае это порт NXS_ANOMALY_WORKER_ADDR, по умолчанию :8081. /ready воркера отвечает 503, если пропал доступ к БД или цикл не завершался дольше допустимого окна. Эти адреса можно проверять через blackbox_exporter или внешний uptime-монитор.
Под капотом Kubespray уже есть Kubeadm, но помимо этого накатываются еще и другие элементы + производятся предварительные проверки системы, поэтому и решили использовать его
Вы правы: в стандартном репозитории Астры есть старая версия Питона и в рамках этой статьи Python ставился их исходников. Однако эта процедура достаточно простая, и я не стал описывать процесс установки, чтобы не перегружать статью
Это было одним из основных условий первой подобной задачи: решение должно было быть максимально опенсорсным, не привязанным к какой-то платформе. Из основных минусов - это построение большого количества велосипедов для достижения удобства. Из плюсов - гибкость инфраструктуры, открытость системы, которая позволяет спокойно ставить специфичное ПО, патчить элементы и т.д, а также бесплатная основа (тот же Nodus стоит 2 100 000 рублей в год).
Вы правы, по дефолту этот параметр всегда отключен. Но ряд облачных ДЦ при создании ВМ выставляют этот параметр в 1 по дефолту. Иногда мы сталкивались с тем, что люди, которые последние годы работали только с облаками, забывают про базовое значение net.ipv4.ip_forward, поэтому я указал этот как пример
Возможно, вы имели ввиду AMD? В этом случае, для базового сравнения процессоров в облаках использование количества ядер вполне релевантно. В противном случае полноценное сравнение могло бы занять отдельную большую статью.
Спасибо за отличный вопрос. Да, можно. nxs-anomaly умеет при инциденте сам отправлять запрос в ваш сервис. Для этого в цепочку эскалации (escalation chain) добавляется шаг TRIGGER_WEBHOOK. Он описан, просто не на видном месте: в CONFIGURATION.md, раздел 4, таблица шагов и абзацы про TRIGGER_WEBHOOK ниже.
Как это работает:
Когда эскалация доходит до этого шага, nxs-anomaly шлёт POST на webhook_url. Если сервис не ответил, запрос повторяется.
Тело запроса - JSON в формате вебхука Alertmanager (version: “4”), а не текст по шаблону. В нём status, alerts[].labels (там alertname, severity), annotations.summary с заголовком инцидента и groupKey, где лежит ID группы алертов (delivery_adapters.go:1179). Свой шаблон тела задать нельзя. Если ваш сервис уже умеет принимать вебхуки Alertmanager, он примет и этот.
Для авторизации есть headers. Секрет лучше передавать ссылкой на переменную окружения, в production-профиле так обязательно: {“kind”: “TRIGGER_WEBHOOK”, “webhook_url”: “https://my-service/hook”, “headers”: {“Authorization”: “env:NXS_ANOMALY_MYSVC_AUTH”}}
В production-профиле включена защита от SSRF, и внутренние адреса (частные сети, localhost) запрещены. Внутренний сервис нужно разрешить через NXS_ANOMALY_BLOCK_PRIVATE_WEBHOOKS_EXCEPT (подробнее в SECURITY_PROFILE.md).
В UI шаг выглядит как «Вызвать исходящий вебхук» в редакторе цепочки. Через API или Terraform он задаётся как шаг цепочки.
ACK из вашего сервиса: да, это работает. ID группы сервис берёт из groupKey в полученном вебхуке. Затем вызывает POST /api/v1/alert-groups/{id}/acknowledge (или /resolve) с API-ключом, у которого роль не ниже responder.
Спасибо за отличный вопрос. С версии 1.3.0 предусмотрен внешний heartbeat и отдельный набор алертов «процесс отсутствует». Мы рекомендуем три независимых уровня контроля:
Heartbeat прямо от воркера, без Prometheus: задаётся переменная NXS_ANOMALY_WORKER_HEARTBEAT_URL, туда подходит адрес проверки во внешнем сервисе, например healthchecks.io. После каждого успешного цикла, воркер делает GET на этот адрес, но не чаще раза в минуту. Если цикл упал из-за базы, пинга не будет. Поэтому одна такая проверка ловит падение воркера, недоступность PostgreSQL и обрыв сети между ними.
Prometheus-алерты на отсутствие процесса, а не на его деградацию. Правила лежат в prometheus-rules.yaml. В Helm они включаются через prometheusRule.enabled и serviceMonitor.enabled.
Отдельная маршрутизация в Alertmanager: эти алерты отправляются отдельным ресивером напрямую, в Telegram, почту или SMS, а не в nxs-anomaly.
Также у API и воркера есть эндпоинты /live и /ready. На воркерае это порт NXS_ANOMALY_WORKER_ADDR, по умолчанию :8081. /ready воркера отвечает 503, если пропал доступ к БД или цикл не завершался дольше допустимого окна. Эти адреса можно проверять через blackbox_exporter или внешний uptime-монитор.
Под капотом Kubespray уже есть Kubeadm, но помимо этого накатываются еще и другие элементы + производятся предварительные проверки системы, поэтому и решили использовать его
Вы правы: в стандартном репозитории Астры есть старая версия Питона и в рамках этой статьи Python ставился их исходников. Однако эта процедура достаточно простая, и я не стал описывать процесс установки, чтобы не перегружать статью
Это было одним из основных условий первой подобной задачи: решение должно было быть максимально опенсорсным, не привязанным к какой-то платформе. Из основных минусов - это построение большого количества велосипедов для достижения удобства. Из плюсов - гибкость инфраструктуры, открытость системы, которая позволяет спокойно ставить специфичное ПО, патчить элементы и т.д, а также бесплатная основа (тот же Nodus стоит 2 100 000 рублей в год).
Вы правы, по дефолту этот параметр всегда отключен. Но ряд облачных ДЦ при создании ВМ выставляют этот параметр в 1 по дефолту. Иногда мы сталкивались с тем, что люди, которые последние годы работали только с облаками, забывают про базовое значение net.ipv4.ip_forward, поэтому я указал этот как пример
Добрый день. Да, все верно, тут, несомненно произошла опечатка. Исправил, спасибо за уточнение
Благодарю, поправлю
Возможно, вы имели ввиду AMD? В этом случае, для базового сравнения процессоров в облаках использование количества ядер вполне релевантно. В противном случае полноценное сравнение могло бы занять отдельную большую статью.