Мониторинг API и SLA эндпоинтов

Что это за сервис

Внутренняя панель для дежурных инженеров, владельцев сервисов и руководителя платформы. Она отвечает на вопрос «что сейчас с нашими API»: какие эндпоинты работают штатно, где выросли задержка или доля ошибок, кто отвечает за сервис и что менялось перед сбоем.

Без такой панели состояние эндпоинтов разнесено по системе наблюдаемости, трекеру инцидентов и журналу деплоев, и у каждой своя шкала времени. Дежурный начинает смену с поиска нужного дашборда, рост P95 замечают по жалобе клиента, а владельца сервиса ищут в устаревшей вики. Разбор после инцидента растягивается на неделю, потому что события приходится собирать из чатов, пейджинга и логов деплоя.

Что он делает

Показывает все эндпоинты на одном экране. Статус, задержка P95, доля ошибок и время последнего замера видны в общей таблице с фильтрами по сервису, владельцу и состоянию.
Сравнивает показатели с порогами SLA. У каждого эндпоинта свой целевой уровень: платёжному API нужен быстрый ответ, отчётному допустима задержка в секунды. Нарушение подсвечивается и порождает уведомление.
Переключает статус автоматически. При выходе за порог эндпоинт переходит в «Деградация» или «Недоступен», а после устойчивого восстановления возвращается в норму без ручной правки.
Держит владельца на виду. Ответственный сервиса — обязательное поле карточки, поэтому эскалация не начинается с вопроса «чей это сервис».
Собирает общую ленту событий. Смена статуса, срабатывание порога и деплой попадают в одну хронологию эндпоинта, и материал для разбора инцидента готов сразу после его закрытия.

Нюансы и особенности

Панель не заменяет систему наблюдаемости. Метрики собирают Prometheus, Grafana, Datadog или Sentry. Приложение на Filament забирает из них агрегаты через API или из хранилища и добавляет то, чего там нет: владельцев, SLA по договорённостям и ленту решений. Если команде хватает дашборда Grafana и алертов в пейджинге, отдельная панель не нужна.
Широкие пороги сначала. Жёсткие пороги «на глаз» порождают поток ложных тревог. Начинают с широких значений, сужают их по реальным инцидентам и раз в месяц пересматривают правила. Пороги хранят в данных, а не в коде.
Автовосстановление статуса. Красный значок, который никто не снял после починки, дезинформирует следующую смену. Статус возвращается в норму, когда доля ошибок держится ниже порога заданное время, например 10 минут.
Ручное переопределение с причиной. На время плановых работ дежурный может выставить статус вручную, но с комментарием и сроком действия, иначе переопределение забудут.
Контекст деплоя. К каждому нарушению подтягивается последний деплой сервиса: коммит, автор и время. Без этого первая четверть часа инцидента уходит на поиск изменения.
Отсутствие данных — не норма. Эндпоинт без инцидентов показывают как исправный, но эндпоинт без свежих замеров — как «Нет данных». Иначе упавший сборщик метрик выглядит как идеальная доступность.
Разные роли — разные права. Дежурный меняет статус и поля инцидента, руководитель видит сводку и тренды только для чтения. Ограничение действует на сервере во всех таблицах и выгрузках.

Как сгенерировать через ИИ-агентов

Промпты рассчитаны на AI-агента (Claude Code, Cursor и аналоги) в Laravel-проекте с установленным Filament 4.x. Отправляйте их по одному и проверяйте результат каждого шага.

1. Данные и модели

Создай модели и миграции для мониторинга API: Service (название, владелец,
команда), Endpoint (сервис, метод, путь, порог P95 в мс, порог доли ошибок,
текущий статус, время последнего замера, ручное переопределение с причиной
и сроком), MetricSample (эндпоинт, время, P95, доля ошибок, число запросов),
EndpointEvent (эндпоинт, тип события, описание, автор, время). Владелец
сервиса обязателен. Добавь фабрики с реалистичными демо-данными.

2. Таблица эндпоинтов и карточка

Сгенерируй Filament-ресурс для Endpoint. В таблице покажи сервис, путь,
статус цветным значком, P95, долю ошибок, владельца и возраст последнего
замера; добавь фильтры по сервису, владельцу и статусу. В карточке выведи
график последних замеров и ленту EndpointEvent через relation manager.

Проверьте, что эндпоинт без замеров за последний час показан как «Нет данных», а не как исправный.

3. Правила статуса

Сделай фоновую задачу, которая раз в минуту сравнивает свежие замеры
с порогами эндпоинта и выставляет статус «Норма», «Деградация» или
«Недоступен». Возврат в «Норма» — только если показатели ниже порога
не меньше 10 минут (значение из конфига). Ручное переопределение
действует до своего срока. Каждую смену статуса пиши в EndpointEvent.

4. Интеграции

Добавь импорт агрегированных метрик из внешнего API системы наблюдаемости
по расписанию и приём вебхуков о деплоях от CI с проверкой подписи.
Повторная доставка того же события не должна создавать дубль. Деплой
записывай в ленту эндпоинтов его сервиса.

5. Роли, уведомления и сводка

Настрой роли: дежурный меняет статусы и переопределения, руководитель
видит всё только для чтения. При переходе в «Деградация» или «Недоступен»
отправляй уведомление в панели владельцу сервиса. Добавь виджеты: число
эндпоинтов по статусам и доля нарушений SLA за неделю.

Войдите под руководителем и убедитесь, что действия изменения статуса недоступны ни в таблице, ни в карточке.