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