# Ложные срабатывания

Механизм проверки при недоступности сервиса и обработка ложных срабатываний

> Индекс всей документации в markdown: https://statuser.cloud/llms.txt — там перечислены остальные статьи. Всё одним файлом: https://statuser.cloud/llms-full.txt. Документация API: https://statuser.cloud/api-reference.md

## Доступность по тарифам

Доступно на всех тарифах

| Функция | Free | Pro | Team |
| --- | --- | --- | --- |
| Создание инцидентов | да | да | да |
| Количество регионов проверок | 2 региона | 5 регионов | 5 регионов |
| Выбор конкретных регионов | нет | да | да |
| Задержка подтверждения сбоя | нет | нет | да |
| Учащённый мониторинг после сбоя | нет | да | да |

Подтверждение сбоя по нескольким регионам работает на всех тарифах, но количество доступных регионов зависит от тарифа: на Free их два.

Сравнение тарифов: https://statuser.cloud/pricing

---

При мониторинге серверов и сервисов могут возникать ложные срабатывания — ситуации, когда система сообщает о проблеме, хотя на самом деле всё работает корректно. Statuser использует различные механизмы для минимизации таких ситуаций в зависимости от типа мониторинга.

## Проверки доступности (HTTP/HTTPS, Ping, TCP)

При проверке сервиса на доступность могут возникать ложные срабатывания. Например, сервис может быть недоступен из-за проблем с сетью или сервер единоразово ответил с ошибкой.

Чтобы минимизировать такие ошибки, Statuser выполняет проверки из нескольких регионов — из **Москвы**, **Санкт-Петербурга**, **Алматы**, **Амстердама** и **Нью-Йорка**. При добавлении сервера вы можете выбрать, из каких регионов выполнять мониторинг.

> Не рекомендуется выполнять проверки только из одного региона — это может
> привести к ложным срабатываниям при кратковременных проблемах в конкретной
> локации. Для надёжности рекомендуется выбрать хотя бы два региона.

Кроме географического распределения, для повышения надёжности используется механизм повторных попыток. Если первая проверка завершилась с ошибкой, Statuser выполнит ещё две повторные попытки с увеличивающимся интервалом:

- После 1-й неудачной попытки — повтор через 700 мс
- После 2-й — ещё одна попытка через 1500 мс

Сервис будет считаться недоступным, только если все 3 попытки в каждом из выбранных регионов завершились неудачно.

#### Пример поведения

```plaintext
Москва →
1.	Первая проверка → ✅ Успешно → [Доступен]
    ↘ ❌ Неудачно → Через 700 мс →
2.	Вторая проверка → ✅ Успешно → [Доступен]
    ↘ ❌ Неудачно → Через 1500 мс →
3.	Третья проверка → ✅ Успешно → [Доступен]
    ↘ ❌ Неудачно → [Недоступен]

Алматы →
...

Амстердам →
...
```

Общее время проверки складывается из времени выполнения трёх попыток и интервалов между ними.

## Мониторинг DNS-записей

При мониторинге DNS-записей важно учитывать, что изменения в DNS могут быть временными или связаны с переносом записей между серверами. Чтобы избежать ложных уведомлений о таких изменениях, Statuser использует систему отложенных уведомлений.

**Как это работает:**

1. При обнаружении изменения в DNS-записях (добавление, удаление или модификация) система не отправляет уведомление сразу
2. Вместо этого запускается таймер ожидания на **15 минут**
3. По истечении этого времени система сравнивает текущее состояние DNS-записей с тем, что было зафиксировано в начале
4. Уведомление отправляется только в том случае, если изменения сохранились

Этот механизм позволяет отфильтровать временные изменения, которые могут возникать:

- При обновлении DNS-записей с коротким TTL
- Во время миграции между DNS-серверами
- При балансировке нагрузки с динамическими записями
- При временных сбоях в DNS-инфраструктуре

> Если за 15-минутный период DNS-записи вернулись к исходному состоянию,
> уведомление не будет отправлено. Это помогает избежать ложных тревог при
> кратковременных флуктуациях DNS.

Благодаря этому подходу вы получаете уведомления только о действительно важных и устойчивых изменениях в DNS-конфигурации вашего домена.

---

Источник: https://statuser.cloud/docs/false-positives