У нас был клиент, который за месяц получил 340 алертов. Из них 312 оказались ложными. К концу третьей недели его on-call инженер просто перестал реагировать — ставил телефон на беззвучный перед сном. А на четвёртой неделе случился реальный outage платёжного шлюза. Алерт пришёл в 2:17. Заметили в 7:40, когда проснулся менеджер и увидел 60 тикетов от клиентов.
Это alert fatigue. Не баг в софте, не проблема инфраструктуры — сломанное доверие к мониторингу. Когда 90% алертов — мусор, оставшиеся 10% тоже становятся мусором в восприятии команды. И вот что важно: retry count и увеличение таймаутов эту проблему не решают. Они только маскируют её ценой более медленного обнаружения реальных проблем.
Почему single-probe мониторинг врёт
Большинство мониторинговых систем проверяют ваш сайт из одной точки. Если проверка не прошла — алерт. Проблема в том, что между вашим сервером и мониторинговым probe миллионы возможных точек отказа: DNS-резолверы, BGP-маршруты, промежуточные роутеры, CDN edge nodes, ISP peering точки. Любой сбой на этом пути выглядит как "сайт лежит", хотя сайт прекрасно работает для всех остальных.
Сценарий 1: Сетевой jitter. Один UDP-пакет потерялся на маршруте. Мониторинг отправил HTTP-запрос, таймаут 10 секунд, TCP handshake не завершился. Результат: "DOWN". Реальность: 99.99% пользователей не заметили ничего.
Сценарий 2: DNS-кэш. DNS-резолвер мониторинга получил stale ответ или временно не может резолвить ваш домен. Результат: "DNS resolution failed". Реальность: все CDN-ноды работают, пользователи заходят без проблем.
Сценарий 3: Probe maintenance. Хостинг-провайдер мониторингового probe проводит maintenance. Latency вырос в 10 раз. Все проверки таймаутятся. Результат: 47 алертов за 15 минут. Реальность: все ваши сервисы работают идеально.
Сценарий 4: Rate limiting. Ваш WAF или Cloudflare заблокировал IP мониторинга как подозрительный трафик. Результат: "403 Forbidden". Реальность: сайт доступен для всех, кроме конкретного IP мониторинга.
Каждый из этих сценариев — реальная причина ложных алертов, и они происходят постоянно. При single-probe мониторинге ваша система не может отличить "сервер упал" от "у probe проблемы с сетью". И единственный "фикс" — добавить retry count (проверить 3 раза перед алертом). Но это лишь увеличивает задержку обнаружения реальных проблем.
Quorum confirmation: как работает консенсус в мониторинге
Идея проста: не доверяй одному источнику. Если один агент говорит "DOWN", спроси остальных. Если большинство подтверждает — это реальный инцидент. Если большинство говорит "UP" — значит, у первого агента локальная проблема.
Это тот же принцип, что используют распределённые базы данных для достижения consensus (Raft, Paxos, ZAB). Система инцидентов AtomPing применяет его к мониторингу:
Шаг 1: Обнаружение перехода. Агент фиксирует изменение состояния: UP → DOWN или DOWN → UP. Это state transition, не просто "проверка упала".
Шаг 2: Голосование. Система собирает результаты от всех агентов, проверявших этот target в текущем цикле. Каждый агент — независимый голос.
Шаг 3: Кворум. Для подтверждения перехода нужно ⅔ голосов (majority). Если 8 из 11 агентов говорят DOWN — инцидент открывается немедленно. Если 2 из 11 говорят DOWN — их результат подавляется.
Шаг 4: Steady state bypass. Если состояние не меняется (UP → UP), результат проходит без голосования. Overhead quorum'а — только на переходах, что составляет менее 1% всех проверок.
Результат: false positive rate падает с типичных 5-15% до менее 0.1%. При этом скорость обнаружения не страдает — кворум собирается в рамках одного цикла проверки (30 секунд), а не через несколько retry.
Batch anomaly detection: когда проблема в probe, а не в target
Quorum ловит случай "один probe ошибся". Но есть другой паттерн: probe теряет сеть полностью и все его проверки возвращают DOWN. Если этот probe проверяет 50 ваших targets, вы получаете 50 алертов одновременно.
Batch anomaly detection работает как предварительный фильтр перед оценкой инцидентов:
Детекция паттерна. Система анализирует: если Agent-X за последние N минут сообщил DOWN для более чем 50% своих targets, и при этом другие агенты в тех же регионах сообщают UP — значит, проблема в Agent-X.
Подавление. Все DOWN-результаты от Agent-X маркируются как "batch anomaly" и не учитываются при оценке инцидентов. Они логируются для анализа, но не генерируют алерты.
Автоматическое восстановление. Когда Agent-X начинает сообщать нормальные результаты, подавление снимается автоматически. Вся логика — stateless, без ручного вмешательства.
Threshold tuning: мягкие и жёсткие инциденты
Даже с quorum и batch anomaly detection вам нужна правильная настройка порогов. Не каждый DOWN — инцидент. Одна неудачная проверка может быть транзиентной ошибкой. Три подряд — уже паттерн.
Incident detection в AtomPing использует двухуровневую систему:
Soft incident — одна или несколько регионов сообщают DOWN в одном цикле. Это предупреждение, не алерт. Система начинает наблюдать пристальнее, но не будит вас в 3 ночи.
Hard incident — N регионов сообщают DOWN в течение M последовательных циклов (по умолчанию: 3 цикла). Это подтверждённый инцидент. Алерт отправляется в Slack, Telegram, email — куда настроено.
Recovery — для закрытия инцидента требуется R успешных циклов подряд (по умолчанию: 2). Это hysteresis — защита от flapping, когда сервис дёргается между UP и DOWN.
Каждый из этих параметров настраивается через AlertPolicy для каждого target отдельно. Критичный API — hard_cycles=1, мгновенный алерт. Некритичный staging — hard_cycles=5, алерт только при устойчивой проблеме.
Практический чек-лист: снизить false positives до нуля
1. Используйте multi-region мониторинг. Минимум 3 региона для quorum. Чем больше — тем точнее. 11 агентов дают tolerance 4 одновременных probe failures.
2. Включите quorum confirmation. Требуйте majority consensus на state transitions. Это единственный способ отличить probe failure от target failure за один цикл.
3. Настройте hard incident thresholds. Для некритичных сервисов — 3-5 циклов. Для критичных — 1-2 цикла с quorum.
4. Используйте recovery cycles. Минимум 2, чтобы избежать flapping-алертов при нестабильном восстановлении.
5. Whitelist мониторинг в WAF/CDN. Добавьте IP-адреса мониторинга в whitelist Cloudflare, AWS WAF, nginx. Это устраняет целый класс ложных "403 Forbidden".
6. Настройте таймауты адекватно. Таймаут 5с для API, который отвечает за 200ms — это нормально. Таймаут 5с для heavy-страницы, которая грузится 4с — это рецепт для ложных алертов.
7. Мониторьте мониторинг. Если ваши probe начали массово фейлить — вы хотите знать об этом раньше, чем получите 100 ложных алертов. Batch anomaly detection делает это автоматически.
8. Используйте mute для плановых работ. Перед деплоем — мьютьте target на время maintenance window. Это не маскировка проблем, это гигиена алертинга.
Alert fatigue: почему это критическая проблема
Исследования показывают: если более 30% алертов — ложные, команда начинает игнорировать все алерты. Это называется alert fatigue, и это документированная причина затянувшихся инцидентов в крупных компаниях. Amazon, Google, Microsoft — все публиковали post-mortems, где root cause был "алерт пришёл, но его проигнорировали".
Решение не в том, чтобы "быть внимательнее". Решение — в архитектуре мониторинга, которая генерирует алерты только когда что-то действительно сломано. Это означает: multi-region checks, quorum confirmation, batch anomaly detection, правильные thresholds, и hysteresis. Всё это доступно в AtomPing на всех планах, включая бесплатный.
Сравнение подходов к снижению false positives
| Метод | False Positive Rate | Скорость обнаружения | Сложность |
|---|---|---|---|
| Single probe, no retry | 10-15% | Мгновенно | Нет |
| Single probe + 3 retries | 3-5% | +3 цикла задержки | Низкая |
| Multi-region, simple majority | 1-2% | В рамках цикла | Средняя |
| Multi-region + quorum + batch anomaly | <0.1% | В рамках цикла | Встроена в AtomPing |
False positives — решаемая проблема. Не нужно терпеть 3 ночных звонка в неделю из-за плохо спроектированного мониторинга. Настройте multi-region мониторинг с quorum confirmation, правильно выставьте пороги инцидентов, и ваши алерты станут сигналом к действию, а не причиной для раздражения. Проверьте, как работает quorum detection на бесплатном плане с 50 мониторами.
FAQ
What is a false positive in uptime monitoring?
A false positive is an alert that says your service is down when it's actually working fine. Common causes: a single monitoring probe having a network issue, transient DNS failures, or brief packet loss between the monitoring server and your infrastructure. False positives erode trust in your alerting — teams start ignoring alerts, and when a real incident happens, they react too slowly.
How does quorum-based incident detection work?
Instead of trusting a single monitoring probe, quorum confirmation collects results from multiple independent agents and requires a majority (e.g., 2 out of 3) to agree that the target is down before opening an incident. If one agent reports DOWN but others report UP, the single failure is suppressed as a false alarm. This mirrors how distributed systems achieve consensus — the same principle that powers Raft and Paxos.
What is batch anomaly detection in monitoring?
Batch anomaly detection identifies when a monitoring agent itself is having problems — for example, if one agent suddenly reports all targets as DOWN simultaneously. This pattern (mass failures from a single source) indicates a probe-side issue, not a target-side issue. The system suppresses these results and relies on healthy agents for accurate reporting.
How many monitoring regions do I need to eliminate false alarms?
At minimum 3 independent monitoring locations. With 3 agents, you can form a 2-of-3 quorum — tolerating 1 agent failure while still accurately detecting real outages. More regions increase accuracy: with 5 agents, you tolerate 2 simultaneous probe failures. AtomPing uses 11 independent agents across Europe with quorum confirmation on every state transition.
Can I reduce false alarms without multi-region monitoring?
Partially. You can increase retry counts (check 3 times before alerting), increase check intervals, and add confirmation delays. But these approaches trade detection speed for accuracy — you'll get fewer false alarms but also slower detection of real outages. Multi-region quorum is the only approach that reduces false alarms without sacrificing speed.
What's a good false positive rate for monitoring?
Industry best practice is less than 1% false positive rate — meaning fewer than 1 in 100 alerts should be false alarms. Single-probe monitoring systems typically see 5-15% false positive rates. Multi-region monitoring with quorum confirmation can achieve less than 0.1%. The real metric that matters is trust: if your team ignores alerts because they're usually wrong, your false positive rate is too high.