Документация

Устранение неполадок

Версия v2.3.1 · Обновлено

Устранение неполадок#

500 при дублирующихся именах или slug'ах#

Дублирующиеся ресурсы должны возвращать 409 Conflict, а не 500. Проверьте логи API на наличие IntegrityError и добавьте явную обработку ошибок в соответствующем представлении.

Типовые примеры:

  • дублирующийся slug группы;
  • дублирующийся slug команды;
  • дублирующийся slug сервиса внутри одной команды;
  • дублирующееся имя канала внутри одной команды.

Пустое тело возвращает непонятную ошибку валидации#

Эндпоинты POST/PUT должны возвращать структурированную 400 validation_error, когда тело отсутствует или содержит некорректный JSON.

Некорректная дата в календаре возвращает 500#

Параметры запроса, такие как start и end, должны валидироваться до того, как разбор даты дойдёт до бизнес-логики.

Тест email работает, а реальный алерт — нет#

Проверьте:

  • У реального алерта есть ответственный.
  • У назначенного пользователя указан email в профиле.
  • Канал привязан к сопоставленному маршруту.
  • Фильтр серьёзности пропускает серьёзность алерта.
  • SMTP-релей принял и доставил сообщение.

Голосовой вызов не проходит из-за отсутствующего телефона#

Голосовой вызов отправляется на номер телефона из профиля назначенного пользователя. Укажите phone у назначенного пользователя.

Ошибка токена Telegram#

Токен бота Telegram должен содержать двоеточие:

123456789:AA...

Если токен недействителен, исправьте конфигурацию канала или отключите канал.

Напоминания дублируются#

Проверьте, что запущен только один процесс планировщика и что планировщик не запускается внутри каждого веб-воркера.

Алерт не виден#

Проверьте:

  • Использован правильный токен приёма маршрута (route intake token).
  • Эндпоинт соответствует источнику маршрута.
  • Матчеры маршрута сопоставляются с метками алерта.
  • Группа активна.
  • Команда активна.
  • Активная группа в UI выбрана правильно.
  • Выбрано All my groups, когда алерт может принадлежать другой доступной группе.
  • routing_error в ответе интеграции.
  • JSON-логи по error_id, если сервер его вернул.

У алерта нет сервиса#

Если алерт создан, но сервис пуст:

  • Проверьте, что у маршрута есть сервис по умолчанию.
  • Проверьте, что существует правило сопоставления сервиса.
  • Проверьте, что правило сопоставления сервиса включено.
  • Проверьте, что правило ограничено правильным маршрутом или не имеет ограничения по маршруту.
  • Проверьте, что метки, аннотации или поля payload соответствуют правилу.
  • Проверьте, что сервис и владеющая им команда включены.

Пример правила сопоставления сервиса Alertmanager:

{
  "labels": {
    "job": "RabbitMQ",
    "rabbitmq": {
      "op": "regex",
      "value": "^rabbitmq-cloud$"
    }
  }
}

Ссылки сервиса или runbook'и не отображаются в уведомлениях#

Проверьте:

  • У алерта есть service_id.
  • Ссылка сервиса или runbook включены.
  • Ссылка сервиса или runbook не удалены.
  • Матчеры runbook'а пусты либо соответствуют меткам/аннотациям/payload алерта.
  • Форматтер уведомлений поддерживает контекст сервиса для выбранного канала.

Поведение матчеров runbook'а:

empty matchers -> generic runbook for all alerts of the service
matchers set -> only matching alerts

Браузерные push-уведомления отключены или не настроен публичный ключ VAPID#

Проверьте эндпоинт конфигурации профиля:

GET /api/profile/push/vapid-public-key

Ожидаемый ответ:

{
  "enabled": true,
  "public_key": "B..."
}

Если enabled равно false или public_key равно null, исправьте конфигурацию [browser_push] и перезапустите веб-сервис. Перезапустите также планировщик, если он отправляет уведомления в вашей установке.

Тест браузерного push работает, а реальный алерт — нет#

Тестовый push отправляется текущему пользователю профиля. Push реального алерта отправляется на alert.assignee_id.

Проверьте:

  • У алерта есть ответственный.
  • Ответственный — тот же пользователь, который включил push в профиле.
  • У строки подписки enabled = true и deleted = false.
  • Браузерные push-уведомления включены в конфигурации.
  • /service-worker.js актуален в браузере пользователя.

Браузерные push-уведомления не являются каналом, поэтому они не отображаются в привязках каналов маршрута.

Действие браузерного push возвращает token_expired#

Одноразовый токен ACK/Resolve/Shelve/Unshelve был старше [browser_push] action_token_ttl_seconds, когда браузер отправил действие.

Действие браузерного push возвращает token_already_used#

Тот же токен действия уведомления уже был использован. Это может произойти после двойного клика, повторной попытки браузера или нажатия на то же действие уведомления более одного раза.

Имя сервиса, команды или группы отображается как -#

Код отображения должен использовать такой порядок:

name -> slug -> "-"

Для ссылок и runbook'ов убедитесь, что сериализаторы включают:

service_id
service_name
service_slug
team_id
team_name
team_slug