Ускорьте реагирование на инциденты с помощью опорного времени

Ускорьте реагирование на инциденты с помощью опорного времени в Расследованиях

Руководство

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

Целевая аудитория

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

Сценарий

Вы получаете уведомление о том, что в вашей продуктивной среде наблюдается высокая нагрузка ошибок HTTP 503. Теперь вам нужно быстро выяснить, что вызвало эти ошибки. Вы входите в свою среду Ключ-АСТРОМ и начинаете расследование. К счастью, ваши коллеги уже начали расследование, и некоторые первоначальные шаги уже предприняты.

Перед началом

1. Откройте общее расследование в режиме только для чтения в Ключ-АСТРОМ Playground.
2. Дублируйте расследование, чтобы продолжить сценарий расследования и иметь возможность выполнять запросы. Инструкции см. в разделе «Дублирование расследований».

Начало работы

Следующие шаги проведут вас через процесс анализа первопричин с использованием опорного времени как одного из инструментов в Расследованиях.

Шаг 1. Проанализируйте график ответов

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

Вы можете увидеть всплеск кода ответа 503 в течение некоторого времени, прежде чем он вернётся к нормальному состоянию.

Шаг 2. Найдите первое появление ошибки

Как указано в RFC7231, код ответа 503 (Service Unavailable) указывает на то, что сервер в настоящее время не может обработать запрос из-за временной перегрузки или запланированного обслуживания, которое, вероятно, будет устранено после некоторой задержки. Другими словами, запрос, приводящий к ответу 503, не является причиной проблемы, а лишь указывает на то, что что-то уже нарушило работу сервиса.

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

1. В поле ввода запроса для синего узла удалите последнюю строку, содержащую команду makeTimeseries.
2. Добавьте следующую команду фильтрации, чтобы получить только запросы с кодом ответа 503:

| filter response_code == 503

1. Добавьте следующую команду summarize, чтобы взять минимальное значение метки времени из всех результатов:

| summarize min(timestamp)

1. Запустите запрос.
2. Это создаст новый узел с одним значением в поле timestamp.
3. Щёлкните правой кнопкой мыши по метке времени в таблице результатов и выберите Установить как опорное время, чтобы определить её как опорную.

Вы заметите поле опорного времени в верхней части страницы и новый виртуальный столбец timestamp_diff, представляющий смещение между значением метки времени и вашим опорным временем. Опорное время равно 00:00:00.000, так как значение в поле timestamp и опорное время совпадают.

Несколько виртуальных полей смещения могут находиться в одном наборе результатов; вы можете создать виртуальное поле для любого типа метки времени.

Шаг 3. Найдите предшествующее сообщение об ошибке

Используя опорное время, давайте поищем запрос, который привёл к неотзывчивости нашего сервиса.

1. Перейдите ко второму (оранжевому) узлу, чтобы увидеть логи Istio. Вы заметите, что поле смещения опорного времени также присутствует в этой таблице результатов.
2. В меню поля опорного времени выберите Раньше чем. Это создаст фильтр по метке времени, чтобы получить логи, записанные до времени опорного значения метки времени.
3. Переименуйте timestamp в start_time в команде фильтрации по метке времени.
   • Причина: при создании опорного времени для фильтрации используется первое поле метки времени. В данном случае используется поле timestamp. Для логов Istio нам нужно использовать поле start_time; это означает, что вам нужно вручную изменить фильтр и переименовать timestamp в start_time в операторе фильтра.
4. Добавьте команду сортировки, чтобы отсортировать результаты в хронологическом порядке.

Ваш запрос DQL должен выглядеть примерно так:

fetch logs, timeframe: "05:00:00Z/06:00:00Z"
| filter k8s.cluster.name == "prod.cupid.cluster"
| filter k8s.container.name == "istio-proxy"
| parse content, "json{JSONTIMESTAMP:start_time, INT:response_code}(flat=true)"
| filter start_time < toTimestamp("2025-05-12T05:32:01.000Z")
| sort timestamp desc

1. Запустите запрос.
2. Первая запись в таблице результатов содержит ответ HTTP 500, что может указывать на запрос, который мог вызвать ошибку в вашей системе.
3. Щёлкните правой кнопкой мыши по метке времени записи и выберите Заменить как опорное время, чтобы заменить текущее опорное время значением из подозрительного запроса.

Шаг 4. Проанализируйте логи приложения

Вы нашли запрос, который привёл к ошибке HTTP 500 в логах Istio. Однако, чтобы понять, что произошло с вашим приложением, вам нужно углубиться в логи приложения.

1. Перейдите к первому узлу дерева запросов. Здесь вы можете увидеть все контейнеры и процессы, для которых у вас есть логи.
2. В поле ввода запроса удалите команду summarize.
3. Щёлкните правой кнопкой мыши по значению heartbeat-matcher-service в столбце k8s.container.name, выберите Фильтр и запустите запрос.
4. Результаты показывают все логи приложения и их относительное расстояние от момента возникновения ошибки (то есть смещение относительно нашего опорного времени).
5. В меню поля опорного времени в разделе Показать окружающие логи выберите 1 мин и запустите запрос.
6. Это позволит вам внимательно изучить соответствующие события и отфильтровать только те, что находятся вокруг вашего опорного времени.
7. В заголовке столбца timestamp выберите Сортировать по возрастанию, чтобы отсортировать результаты в хронологическом порядке.

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

Заключение

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

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