Мониторинг и восстановление
Мониторинг сообщает о проблеме. После алерта mttrly помогает разобраться и безопасно выполнить следующий шаг.
Grafana, Datadog, Sentry, PagerDuty и Prometheus показывают метрики, трассировки и логи, фиксируют ошибки и отправляют алерты. После такого сигнала mttrly получает актуальные данные с сервера и помогает провести исправление по контролируемому сценарию.
Direct answer
Мониторинг обнаруживает; mttrly помогает действовать после алерта
Оставьте Grafana, Datadog, Sentry, PagerDuty, Prometheus или другой инструмент наблюдения для обнаружения и объяснения инцидента. После алерта используйте mttrly, чтобы получить актуальные данные с сервера, запустить ограниченную диагностику и выбрать подготовленный сценарий. Правила определят, нужно ли решение человека. После выполнения mttrly сохранит результат, а поддерживаемый сценарий дополнительно перепроверит состояние сервиса.
Что делает мониторинг, а что делает mttrly
| Возможность | Инструменты мониторинга | mttrly |
|---|---|---|
| Основная задача | Обнаружить проблему, показать её развитие и доставить алерт нужному человеку. | Проверить состояние сервера и провести контролируемое действие после алерта. |
| Лучше всего показывает | Метрики, дашборды, трассировки, логи, ошибки и историю изменений. | Текущее состояние сервера, диагностику, подготовленные сценарии, ожидающие решения и результаты действий. |
| Типичный вопрос | "Что сломалось, когда это началось и кого нужно позвать?" | "Что сейчас происходит на сервере и какой следующий шаг безопасен?" |
| Модель действий | Собрать данные, отправить алерт, открыть инцидент и сохранить общий контекст. | Проверить сервер, выбрать подготовленный сценарий, применить правила доступа, выполнить действие и перепроверить результат там, где это поддерживается. |
| Контроль риска | Зависит от процесса реагирования команды. | Действия класса approval-required обычно ждут решения человека. Узкое предварительное разрешение или bounded Investigation на mttrly_execute_command одобряются отдельно и записываются. |
| Выполнение команд | Не является основной задачей инструментов наблюдения. | Доступно только когда функция включена и ограничена правилами. Обычный путь требует решения для каждой команды; отдельно одобренная bounded Investigation действует только для mttrly_execute_command. |
Что происходит после алерта
Проверки без изменения состояния могут выполняться сразу. В обычном интерактивном сценарии действие класса approval-required ждёт решения человека.
- 01
Приходит алерт
Grafana, Datadog, Sentry, PagerDuty или Prometheus сообщает о проблеме через уже настроенный канал инцидентов.
- 02
Оператор открывает mttrly
Человек или AI-ассистент проверяет затронутый сервер после алерта. При этом mttrly дополняет мониторинг, а не заменяет его.
- 03
Сначала собираются данные
До предложения изменений mttrly проверяет здоровье сервера, состояние сервисов и свежие логи, затем запускает подходящую диагностику.
- 04
Выбирается подготовленное действие
Предпочтение отдаётся готовому playbook. Выполнение отдельной команды можно включить для более узких случаев, но этот путь также ограничен правилами.
- 05
Правила определяют, нужно ли подтверждение
Действие класса approval-required обычно создаётся в статусе pending и ждёт человека. Узкое предварительное разрешение и bounded Investigation для mttrly_execute_command одобряются отдельно; AI не может включить их самостоятельно.
- 06
Результат сохраняется и проверяется
В истории остаются статус действия, его вывод и время выполнения. Поддерживаемые сценарии добавляют явную проверку после действия; общий тренд системы по-прежнему подтверждает мониторинг.
Две разные задачи
Мониторинг обнаруживает и объясняет сигналы
- +Метрики и дашборды о состоянии сервисов и инфраструктуры
- +Трассировки, логи и ошибки приложения для поиска причины
- +Алерты, маршрутизация и эскалация
- +Тренды, базовые уровни и регрессии
- +Общий контекст для команды, которая разбирает инцидент
Мониторинг отвечает: "Что происходит, где это происходит и как ситуация менялась со временем?"
Как mttrly помогает разобраться и действовать после алерта
- +Проверка актуального состояния затронутого сервера или сервиса
- +Диагностика с данными, собранными после алерта
- +Подготовленные playbook до произвольных команд
- +Ожидающие решения действия для рискованных изменений
- +Повторная проверка в поддерживаемых сценариях и история инцидента
Вопрос для mttrly: "Что можно безопасно проверить, запросить, подтвердить и перепроверить дальше?"
Используйте мониторинг для видимости. Добавьте mttrly как контролируемый слой действий после сигнала.
Как знакомые инструменты работают вместе с mttrly
Grafana
Дашборды, исследование метрик и контекст алерта
Grafana остаётся местом, где команда видит поведение системы во времени. После алерта или анализа дашборда mttrly подключается к серверу, которому требуется внимание.
Prometheus
Сбор метрик, правила алертов и временные ряды
Prometheus хорошо измеряет нагрузку на ресурсы и сигналы сервисов. Для mttrly такой алерт становится отправной точкой для актуальной диагностики сервера и контролируемого исправления.
Datadog
APM, телеметрия инфраструктуры, логи и алерты
Datadog помогает связать поведение инфраструктуры и приложения. Здесь mttrly добавляет контролируемый путь от расследования к действию и повторной проверке, если выбранный сценарий её поддерживает.
Sentry
Ошибки приложения, исключения и контекст релиза
Sentry показывает сбой приложения и затронутый участок кода. После такого сигнала mttrly помогает проверить сервер, выбрать ограниченное операционное действие и сохранить его результат.
PagerDuty
Маршрутизация алертов, эскалация и координация
PagerDuty привлекает нужного человека. Затем mttrly даёт ему ограниченный интерфейс для диагностики, подготовленных действий и просмотра истории результата.
Как mttrly ограничивает риск
Система mttrly рассчитана на контролируемое реагирование, а не на бесконтрольные рискованные изменения.
Сначала собрать данные
AI может проверить статус сервера, алерты и логи, а затем запустить диагностику до рекомендации действия.
Сначала подготовленный playbook
Для знакомой проблемы предпочтителен готовый сценарий, а не произвольная shell-команда.
Решение человека
Действия класса approval-required обычно ждут человека. Узкое предварительное разрешение и bounded Investigation для mttrly_execute_command одобряются отдельно; AI не может включить их самостоятельно.
Ограниченное выполнение команд
Если выполнение команд включено, оно подчиняется правилам и записывается. Обычный путь требует решения для каждой команды; отдельно одобренная bounded Investigation применяется только к mttrly_execute_command.
Записать и проверить результат
У каждого действия остаётся записанный результат. Поддерживаемый сценарий добавляет явную проверку после действия; произвольной команде нужна отдельная проверка до вывода, что сервис восстановлен.
Что посмотреть дальше
FAQ
Заменяет ли mttrly Grafana?
Нет. Оставьте Grafana для дашбордов, метрик, трендов и контекста алерта. После алерта используйте mttrly для актуальной диагностики сервера и контролируемого исправления. Результат действия сохранится, а поддерживаемый сценарий дополнительно перепроверит состояние.
mttrly заменяет Datadog, Sentry, PagerDuty или Prometheus?
Нет. Эти инструменты обнаруживают и объясняют инциденты, доставляют алерты и сохраняют общий контекст. После них mttrly добавляет контролируемый слой действий.
Может ли AI выполнять команды через mttrly?
Только если выполнение команд включено и ограничено правилами. Подготовленные playbook предпочтительнее. Обычный путь требует решения для каждой команды; отдельно одобренная bounded Investigation может изменить это только для mttrly_execute_command. AI не может включить такое исключение самостоятельно.
Что происходит после алерта мониторинга?
Оператор может открыть mttrly, проверить актуальное состояние сервера и запустить подходящую диагностику. Затем он выбирает playbook или запрашивает действие. После этого mttrly применяет правила доступа, записывает результат выполнения и запускает отдельную проверку там, где выбранный сценарий её поддерживает.
Это не делает mttrly заменой Grafana, Datadog или Sentry. Обнаружение проблемы и общий тренд остаются в инструментах наблюдения. После алерта mttrly проводит диагностику сервера, применяет правила доступа, сохраняет результат действия и повторно проверяет сервис в поддерживаемых сценариях.
Нужна техническая схема? Посмотрите incident action layer.