Практические сценарии

Как пройти путь от вопроса к данным, которые на него отвечают, и затем к решению.

Исследуйте новое соединение

Откройте группы событий приложения и выберите недавний интервал. Найдите исходящую сетевую активность, посмотрите на IP и порт назначения, на процесс и нагрузку, из которых она пришла, и откройте сохранившиеся подробности события. Если есть DNS-контекст, проверьте уверенность, TTL и нет ли неоднозначности. Событие с одним только IP — вполне полноценное свидетельство: домен угадывать не нужно.

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

Группа исходящего соединения примерного приложения: процесс, адрес и порт назначения, свидетельства DNS с пометкой неоднозначности и сроком действия.

Адрес назначения самодостаточен; блок DNS сообщает, что для этого IP наблюдалось несколько имён, и когда это свидетельство истекает.

Работа с политиками

Политики помечают наблюдаемое поведение приложения как ожидаемое или как требующее проверки. Они не блокируют процессы и соединения, не меняют жизненный цикл находок и никогда не удаляют данные. Чтобы создать политику, нужно войти в систему, иметь доступ к приложению и начать с сохранённой группы событий или записи инвентаризации, из которой политику можно построить.

Политики для назначений, доменов, системных вызовов и файловой активности описывают каноническое поведение приложения, а не команду Linux-потока. Совпавшая политика действует для всех потоков в настроенной области размещения. Группы событий по-прежнему показывают команду процесса, создавшего данные.

Откройте группу событий или запись инвентаризации и выберите «Создать политику из наблюдения». Задайте имя, проверьте показанную область действия и нажмите «Предварительный просмотр влияния» — без просмотра политика не создаётся. Он показывает, сколько групп и наблюдений будет затронуто и сколько из них окажутся ожидаемыми, а сколько потребуют проверки. Если из наблюдения политику построить нельзя, диалог сообщит об этом вместо создания.

После создания откройте в приложении «Управляемые политики». Там видны текущая ревизия, её эффекты внутри и вне области действия и история ревизий; кнопки «Включить» и «Отключить» управляют активностью. Редактировать существующую ревизию текущий интерфейс не позволяет. Пока результаты пересчитываются, наблюдения показывают «Вычисление политики»; когда пересчёт закончится, проверьте действующий вердикт в группах событий или инвентаризации, а найти затронутое поведение помогут фильтры по вердикту и вычислению.

«Новые находки» примерного приложения: фильтры по вердикту политики, подавлению и состоянию оценки над наблюдаемым поведением.

Фильтры по вердикту, подавлению и состоянию оценки — это способ найти поведение, которого коснулась политика. Здесь группа ещё не классифицирована.

Сравните релизы

В разделе релизов приложения выберите базовую и целевую версии и откройте сравнение поведения. Сначала проверьте идентичности образов и интервалы наблюдения — именно они придают смысл всему остальному. Затем разберите поведение, которое появилось, исчезло или изменилось, вместе со счётчиками и временем. Разная нагрузка или запуск, попавший в одно окно наблюдения и не попавший в другое, объясняют многие различия, за которыми не стоит никакой ошибки.

Прямо проговаривайте случаи, когда покрытие неизвестно. Числовая история может пережить подробности, на которых она построена, а по истёкшим данным нельзя уверенно утверждать, что чего-то не было. Завершайте разбор так: откройте сохранившийся показательный пример или отметьте, что подробности уже недоступны.

Сравнение релизов примерного приложения: образы цели и базы, способ выбора базы и счётчики нового, более не наблюдаемого, по-прежнему наблюдаемого и неизвестного поведения.

Сверьте образы и окна наблюдения прежде, чем читать счётчики. «Неизвестно» — это отдельный ответ, не то же самое, что «больше не наблюдается».

Разберитесь с перезапуском

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

Считайте находку указателем, а не ответом: проверьте лимиты нагрузки, журналы приложения и события Kubernetes привычными инструментами. Если нужные данные истекли или вообще не собирались, оставьте причину неустановленной. Неразобранный перезапуск лучше правдоподобной истории, которую ничто не подтверждает.

Настройте и проверьте уведомления

В уведомлениях проекта добавьте разрешённого получателя и поддерживаемые им правила. Перед сохранением просмотрите получателя и действующие настройки. Само сохранение ничего не запускает: обработчик доставки должен включить оператор. Затем создайте контролируемую подходящую находку и проверьте запись доставки и её попытки.

На стороне получателя проверяйте HMAC-подпись с временной меткой и отсеивайте дубликаты по идентификатору доставки — он остаётся стабильным. Восстановление сохраняет этот идентификатор, поэтому повтор может прийти получателю, который уже обработал сообщение. Прежде чем подтверждать повтор или отмену, посмотрите, к чему они приведут: активная аренда может помешать отмене. Отличить отключённый обработчик от повторяющего или сбоящего помогает снимок состояния.

Запись доставки уведомления примерного проекта: устойчивый идентификатор, статус ожидания, число попыток и время следующей попытки.

Запись доставки отслеживается отдельно от самой находки. Дедуплицируйте по этому идентификатору доставки: он переживает повторную отправку.