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


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

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

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

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

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

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

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

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

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

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

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

# В поле ввода запроса для синего узла удалите последнюю строку, содержащую команду <code>makeTimeseries</code>.
# Добавьте следующую команду фильтрации, чтобы получить только запросы с кодом ответа 503:
<pre>
| filter response_code == 503
</pre>

# Добавьте следующую команду <code>summarize</code>, чтобы взять минимальное значение метки времени из всех результатов:
<pre>
| summarize min(timestamp)
</pre>

# Запустите запрос.
# Это создаст новый узел с одним значением в поле <code>timestamp</code>.
# Щёлкните правой кнопкой мыши по метке времени в таблице результатов и выберите '''Установить как опорное время''', чтобы определить её как опорную.

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

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

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

# Перейдите ко второму (оранжевому) узлу, чтобы увидеть логи '''Istio'''. Вы заметите, что поле смещения опорного времени также присутствует в этой таблице результатов.
# В меню поля опорного времени выберите '''Раньше чем'''. Это создаст фильтр по метке времени, чтобы получить логи, записанные до времени опорного значения метки времени.
# Переименуйте <code>timestamp</code> в <code>start_time</code> в команде фильтрации по метке времени.
#* '''Причина''': при создании опорного времени для фильтрации используется первое поле метки времени. В данном случае используется поле <code>timestamp</code>. Для логов '''Istio''' нам нужно использовать поле <code>start_time</code>; это означает, что вам нужно вручную изменить фильтр и переименовать <code>timestamp</code> в <code>start_time</code> в операторе фильтра.
# Добавьте команду сортировки, чтобы отсортировать результаты в хронологическом порядке.

Ваш запрос '''DQL''' должен выглядеть примерно так:<pre>
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
</pre>

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

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

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

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

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

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