Прибыль:
- Способность понимать три столпа наблюдаемости (метрика, журнал, трассировка) и четыре золотых сигнала, а также использовать искусственный интеллект для создания запросов PromQL, правил сигналов тревоги и информационных панелей.
- Возможность предотвратить утомляемость тревогами, сохраняя их ориентированными на действия и с правильной срочностью, а также проверяя пороговые значения на основе исторических данных вашей собственной системы.
- Возможность предотвратить утечку конфиденциальной информации и секретов, маскируя конфиденциальные области перед передачей журналов искусственному интеллекту.
Хотя система может казаться работающей, внутри она может умирать: память медленно заполняется, время отклика увеличивается, частота ошибок растет. Единственный способ заметить это – постоянно следить за системой. Более продвинутая концепция — наблюдаемость: способность понимать, что происходит внутри системы, глядя на ее внешние признаки. Существует три столпа наблюдаемости, и профессионал DevOps использует все три:
- Метрика: числовые значения, измеряемые с течением времени — загрузка ЦП, количество запросов, время ответа, частота ошибок. "Сколько?" отвечает на вопрос.
- Журнал: текстовые записи событий, создаваемые системой: «пользователь вошел в систему», «соединение с базой данных потеряно». «Что именно произошло?» отвечает на вопрос.
- Трассировка: путь, по которому следует запрос при переходе от службы к службе внутри системы, а также продолжительность каждого шага. «Где медлительность?» отвечает на вопрос.
Наиболее распространенные инструменты: Prometheus для метрик, Grafana для визуализации, Loki/ELK для журналов, Jaeger/OpenTelemetry для трассировки. ИИ очень хорошо умеет писать языки запросов (особенно PromQL Prometheus), правила сигналов тревоги и настройки информационной панели для этих инструментов. Именно здесь ИИ наиболее силен: суммирует большие объемы журналов и показателей и отмечает аномалии.
Давайте проясним разницу между мониторингом и наблюдаемостью в одном предложении: мониторинг задает уже знакомые вам вопросы («Прошел ли загрузка ЦП 90%?»); наблюдательность — это возможность задавать вопросы, о которых вы еще не знали («почему эта странная медлительность происходит только с определенным клиентом в определенное время?»). Современные системы настолько сложны, что невозможно предсказать все виды отказов; Таким образом, возможность собирать обширные метрики, журналы и трассировки, а затем подробно запрашивать их, то есть наблюдаемость, становится критически важной. Именно здесь ИИ вступает в игру при ответе на «ранее неизвестный вопрос»: он быстро сканирует имеющиеся у вас необработанные данные, предлагает закономерности и аномалии, и вы доходите до основной причины, проверяя эти подсказки.
Шаг за шагом: что и как контролировать?
- Выбирайте правильные показатели. В индустрии за основу берутся «четыре золотых сигнала»: задержка, трафик, ошибки, насыщенность — насколько заполнен ресурс. Они суммируют состояние большинства служб.
- Собирайте метрики. Пусть приложение представляет конечную точку, которую может прочитать Prometheus.
- Настройте дашборды. Визуализируйте эти метрики в Grafana.
- Напишите правила тревоги. Кто и как будет предупрежден о превышении порога?
- Централизуйте журналы. Сделайте все журналы обслуживания доступными для поиска в одном месте.
- Уменьшите шум. Слишком сильная тревога создает «усталость от бдительности»; Важный сигнал тревоги исчезнет.
Совет: Хороший сигнал тревоги отвечает двум требованиям: он практичен и имеет правильную срочность. Будильник, который будит кого-то в 3 часа ночи, должен быть чем-то, что действительно требует вмешательства в ночное время. Не будите никого из-за чего-то, что само по себе не требует действий, например «ЦП 70%»; покажите его на доске.
Как написать правило тревоги?
Оповещение состоит из трех компонентов: состояние (какая метрика превышает какой порог и на какой срок), продолжительность («на 5 минут», чтобы не вызывать мгновенных колебаний) и важность/действие (для кого, через какой канал). ИИ мастерски устанавливает эти три контекста в нужном контексте. Например, трансляция правила типа «критическая тревога, если уровень ошибок превышает 5% в течение 5 минут» в PromQL — задача доли секунды для ИИ — но вы сами решаете, подходит ли порог для вашей системы.
Внимание: пороговые значения сигналов тревоги, предлагаемые ИИ, являются общими предположениями. Нормальная нагрузка, устойчивость и влияние на работу вашей системы различны. Прежде чем вводить порог непосредственно в продукт, вы смотрите на свои исторические данные и спрашиваете: «Сколько раз этот порог срабатывал в прошлом, сколько из них были реальными проблемами?» Ответьте на вопрос.
Конфиденциальность журнала: критическое предупреждение
Журналы являются наиболее часто упускаемым из виду источником утечек. Строка журнала может случайно содержать пароль, номер кредитной карты или личные данные (согласно KVKK/GDPR). При вставке логов в AI для анализа:
- Маскируйте чувствительные зоны. Замените такие значения, как токен, пароль, адрес электронной почты, идентификационный номер, на <УДАЛЕНО>.
- Приведите примеры, не все. Вместо миллиона строк часто бывает достаточно нескольких сотен репрезентативных строк.
- Выберите автомобиль, одобренный учреждением. Особенно для производственных журналов используйте инструмент, данные которого не идут на обучение.
Четыре золотых сигнала и таблицы тревог
сигнал
измеряется
Пример порога тревоги
срочность
задержка
время ответа
p95 > 800 мс, 5 мин
высокий
трафик
Запрос/сек
Внезапное увеличение/уменьшение на 300 %
средний
Ошибка
Частота неудачных запросов
> 5%, 5 мин
критический
Насыщенность
занятость ресурса
Диск > 85%
высокий
три мини-кейса
Случай 1 — 400 строк журнала, суммированных за 30 секунд. Служба замедлилась. Инженер передал ИИ замаскированные 400 строк журнала и сказал: «Обобщите повторяющиеся шаблоны ошибок и интенсивность времени». ИИ показал, что тайм-аут конкретного внешнего вызова API каждые 30 секунд. Первопричина найдена за 30 секунд; Сканирование журналов вручную заняло бы полчаса.
Случай 2 — устранена усталость тревоги. Одна команда получала 200 сигналов тревоги в день и игнорировала их все — до тех пор, пока не был упущен из виду настоящий сигнал об отключении электроэнергии. Дайте ИИ все правила оповещения и спросите «какие из них недействительны, а какие можно комбинировать?» они спросили. Количество тревог уменьшилось до 12 в день; К каждой тревоге теперь относились серьезно.
Случай 3 — раньше обнаружен неправильный порог. YZ предложил «Предупреждать при заполнении диска на 95%». Инженер просмотрел исторические данные: как только диск достиг 95%, времени на вмешательство было мало. Он снизил порог до 80% и добавил второй сигнал тревоги, основанный на «темпах роста». Проверка предотвратила фактическое отключение в полночь.
Четыре копируемых шаблона
1) Обобщение журналов (маскировано):
Проанализируйте приведенный ниже пример журнала (я замаскировал конфиденциальные значения с помощью <УДАЛЕНО>). Дайте мне: (1) повторяющиеся шаблоны ошибок, (2) концентрацию с течением времени, (3) наиболее вероятную основную причину и (4) 3 показателя, на которые я проверю. Журнал: [СТРОКИ]
2) Генерация правил тревоги:
Напишите правило тревоги для Prometheus/Alertmanager: генерировать сигнал тревоги [СЕРЬЕЗНОСТЬ], если [ПОРОГ] превышает [МЕТРИКУ][ДЛИТЕЛЬНОСТЬ]. Правило должно быть ориентировано на действие и включать поле аннотации и ссылки на Runbook. Объясните PromQL и напишите, почему этот порог разумен.
3) Написание/объявление запроса PromQL:
Напишите запрос PromQL, который измеряет: [EX. 5xxпроцент ошибок за последние 5 минут]. Объясните запрос шаг за шагом. Тогда скажите мне, каким должен быть здоровый диапазон этого значения.
4) Дизайн приборной панели:
Создайте панель управления Grafana для [СЕРВИС]: с помощью каких панелей мне следует отображать четыре золотых сигнала (задержка, трафик, ошибка, насыщенность)? Предложите метрику, тип визуализации и разумный порог для каждой панели. Цель: увидеть состояние здоровья охранника за 10 секунд.
Слабая подсказка / Сильная подсказка
Слабый: «Что в этом журнале?» (за которым следуют 5000 строк необработанного журнала, токены в нем)
Результат: вы раскрываете секреты, а ИИ дает нецелевое, поверхностное изложение.
Сильный: «Найдите повторяющиеся шаблоны ошибок и интенсивность времени в приведенном ниже примере журнала из 300 строк в маске; назовите мне наиболее вероятную основную причину и показатели, которые я проверю. Я сделал токены <УДАЛЕНО>».
Разница: вторая подсказка представляет собой замаскированный и сфокусированный пример, требующий четких результатов анализа; Это и безопасно, и полезно.
Распространенные ошибки
- Вставка лога в AI без его маскировки. Самая распространенная утечка секретных/личных данных.
- Установка будильников для всего. Усталость от тревоги заглушает настоящую тревогу.
- Недействующая сигнализация. Это предупреждающий шум, с которым никто ничего не может поделать.
- Принятие порога ИИ без вопросов. Порог должен быть установлен в соответствии с историей вашей системы.
- Просто смотрю на метрику. Без журнала и трассировки основную причину в большинстве случаев невозможно обнаружить.
- Не устанавливать время будильника (для). Мгновенные колебания вызывают ложные тревоги.
В итоге
Наблюдаемость; Это способность понять внутреннюю часть системы снаружи с помощью метрик, журналов и трассировок. Четыре золотых сигнала (задержка, трафик, ошибка, насыщение) суммируют состояние большинства сервисов. ИИ очень эффективен при написании запросов PromQL, правил сигналов тревоги и информационных панелей, а также при обобщении больших объемов журналов и обнаружении аномалий. Но вы обязаны сверять пороговые значения сигналов тревоги с историей вашей собственной системы, обеспечивать ориентированность сигналов тревоги на конкретные действия и никогда не делиться журналами без их маскировки.
Задача приложения
Для услуги (или примера услуги): (1) Создайте правило сигнализации для частоты ошибок с помощью шаблона «Генерация правила сигнализации» и установите предлагаемый порог на «сколько раз оно срабатывало в прошлом?» Проверьте это с помощью вопроса; (2) замаскируйте имеющуюся у вас выборку журнала и проанализируйте ее с помощью шаблона «Суммирование журналов»; (3) отметьте, на какой показатель вы будете обращать внимание, чтобы определить наиболее вероятную основную причину.
контрольный список
- [ ] Я выбрал показатели для отслеживания на основе четырех золотых сигналов.
- [ ] Я замаскировал все логи, которые передал ИИ, с точки зрения чувствительных областей.
- [ ] Я проверил, что каждый сигнал тревоги ориентирован на действие и имеет правильную срочность.
- [ ] Я проверил пороги срабатывания сигнализации на основе исторических данных моей системы.
- [ ] Я отфильтровал мгновенные колебания, добавив к сигналам тревоги for (длительность).
- [ ] Для определения основной причины я использовал вместе метрику + журнал + трассировку.