Наблюдаемость API: от сигналов к решениям

Подключение телеметрии к пользовательской задаче

Метрики, журналы и трассировки отвечают на разные вопросы. Высокая доступность может скрывать сбой при оформлении заказа или входе в систему. Определите ожидаемый пользователями результат, а затем инструментируйте вызовы, которые его обеспечивают.

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

Первичный источник: OpenTelemetry — Observability primer. Связанный метод: прочитать практическое руководство.

Сбой сбора: сверить журналы и отсутствующие события

Разделить созданные, полученные и пригодные события, не считая тишину отсутствием инцидентов.

• Сопоставьте приложение, коллектор и хранилище с ответственными. Подготовьте конечную вымышленную последовательность со стабильными идентификаторами без секретов и клиентских данных. Сохраняйте время события и наблюдения: задержка не обязательно означает потерю.
• В тесте отключите получателя и восстановите его. Наблюдайте очередь, попытки, отказы и перезапуск. Постоянная очередь может ограничить потери, но имеет ёмкость и зависит от хранилища; задайте поведение при заполнении. Проверьте, что сбор не блокирует сервис незаметно.
• Сверьте эталон с читаемыми событиями на общей отсечке. Считайте повторы, задержки и отсутствия отдельно: сетевое подтверждение не доказывает конечную пригодность. Без надёжного эталона покрытие неизвестно, а не ноль потерь или инцидентов.

{
    "expected_ids": [
        "E1",
        "E2",
        "E3"
    ],
    "received_ids": [
        "E1",
        "E1",
        "E3"
    ],
    "received_rows": 3,
    "unique_received": 2,
    "missing_ids": [
        "E2"
    ],
    "observation_cutoff": "same_for_both_sets"
}

Первичный источник: OpenTelemetry — Collector resiliency. Связанный метод: прочитать практическое руководство.

Заброшенные поддомены: контролируемое удаление CNAME

Свяжите DNS-имена с подконтрольными ресурсами и закройте зависимости до освобождения сервиса.

• Запишите имя, цепочку CNAME, ресурс поставщика и ответственного. Сопоставьте DNS с инвентарём разрешённой учётной записи. Ошибка HTTP, NXDOMAIN или отсутствие ресурса требуют проверки, но не доказывают возможность захвата; защиты поставщиков различаются.
• Удалите ссылку или направьте её на подконтрольную цель до освобождения ресурса. Учтите прежние TTL и кэши; проверьте авторитетный DNS и несколько резолверов. Сохраните нужные проверки владения, не удаляйте все TXT подряд.
• Проверьте ссылки, перенаправления, callback OAuth, вебхуки и домены cookie. Если ресурс уже освобождён, исправьте DNS и исследуйте возможное раскрытие по процедуре инцидента. Сверяйте DNS и ресурсы после каждого удаления.

{
    "name": "portal.example",
    "cname_present": true,
    "resource_deleted": true,
    "provider_claimability": "not_verified",
    "takeover_observed": false,
    "expected": "remove_or_replace_mapping_and_review_exposure"
}

Первичный источник: Microsoft — Prevent dangling DNS entries. Связанный метод: прочитать практическое руководство.

Повторы API: считать полный бюджет времени

Разделяйте вызовы, ожидания и весь путь.

Связанный метод: прочитать практическое руководство.