Аптайм и инциденты

Monitor накапливает историю проверок доступности и формирует локальные инциденты, чтобы видеть не только текущее состояние, но и повторяющиеся проблемы.

[Скриншот 1: страница Аптайм]

Сводка

На странице показывается статистика за период, включая последние проверки и зафиксированные инциденты. Это помогает отличить единичный сбой от систематических падений.

Что считать инцидентом

Инцидент создаётся логикой мониторинга при проблемном результате проверки. Конкретная причина может быть связана с недоступностью сайта, HTTP-ошибкой или другим контролируемым состоянием. Для окончательного разбора сопоставляйте время с серверными логами и событиями хостинга.

[Скриншот 2: история проверок]

Как пользоваться

1. Посмотрите частоту проблем за последние 30 дней.
2. Откройте ближайший по времени инцидент.
3. Сверьте его с метриками, базой, диском и журналами.
4. Если сайт контролируется Aggregator, сравните центральные события и локальную историю.
5. После устранения причины продолжайте наблюдение, чтобы убедиться, что проблема не повторяется.

Ограничение локальной проверки

Monitor находится внутри самого сайта. Если сервер полностью недоступен, локальный агент тоже не сможет сообщить о проблеме в момент сбоя. Для внешнего контроля полной недоступности нужен Aggregator/внешний Hub, который независимо проверяет состояние клиента.

Важно: Для полноценного SLA-контроля внутреннюю историю Monitor лучше сочетать с внешней проверкой доступности.

Почему нужен внешний контроль

Внутренний агент хорошо фиксирует работу приложения, но не может отправить сообщение, когда весь сервер выключен или потерял сеть. Поэтому в будущей Hub-схеме желательно иметь независимую внешнюю HTTP-проверку домена и сопоставлять её с heartbeat Monitor.

Ложные краткие сбои

Единичный timeout может быть вызван сетью, перезапуском PHP или кратким обслуживанием. Для SLA важны продолжительность, частота и повторяемость. Не создавайте эскалацию одинакового уровня для одного секундного сбоя и длительного падения.

После аварии

Зафиксируйте начало/окончание, причину и выполненное действие в рабочем регламенте. История Monitor помогает восстановить временную линию, но причина аварии обычно подтверждается серверными логами и журналом изменений.

[Скриншот 3: список инцидентов]