Печалби:
- Възможност за разбиране на трите стълба на наблюдаемостта (метрика, дневник, проследяване) и четирите златни сигнала и генериране на изкуствен интелект в PromQL заявки, правила за аларми и табла за управление
- Възможност за предотвратяване на умората на алармата чрез поддържане на алармите ориентирани към действие и при правилната спешност и тестване на прагове спрямо историческите данни на вашата собствена система
- Възможност за предотвратяване на поверителност и изтичане на тайни чрез маскиране на чувствителни зони, преди да предоставите регистрационните файлове на изкуствен интелект
Въпреки че една система може да изглежда работеща, тя може да умира отвътре: паметта бавно се запълва, времето за реакция се увеличава, честотата на грешките се увеличава. Единственият начин да забележите това е да наблюдавате постоянно системата. По-напреднала концепция е наблюдаемостта: способността да се разбере какво се случва вътре в системата, като се погледнат нейните външни признаци. Има три стълба на видимост и специалистът по DevOps използва и трите:
- Метрика: Числени стойности, измерени във времето — използване на процесора, брой заявки, време за отговор, процент грешки. — Колко? отговаря на въпроса.
- Дневник: Текстови записи на събития, създадени от системата — „потребител е влязъл“, „загубена връзка с базата данни“. — Какво точно се случи? отговаря на въпроса.
- Проследяване: Пътят, който следва една заявка, докато преминава от услуга към услуга в системата и продължителността на всяка стъпка. „Къде е бавността?“ отговаря на въпроса.
Най-често срещаните инструменти: Prometheus за метрики, Grafana за визуализация, Loki/ELK за журнал, Jaeger/OpenTelemetry за проследяване. AI е много опитен в писането на езици за заявки (особено PromQL на Prometheus), правила за аларми и конфигурации на таблото за тези инструменти. Това е и мястото, където AI е най-силен: обобщаване на големи части от регистрационни файлове и показатели и маркиране на аномалии.
Нека изясним разликата между мониторинг и наблюдаемост в едно изречение: мониторингът задава въпроси, които вече знаете („ЦП над 90% ли е?“); наблюдаемостта е възможността да задавате въпроси, които все още не сте знаели („защо това странно забавяне се случва само за определен клиент в определен момент?“). Съвременните системи са толкова сложни, че не можете да предвидите всички видове повреда; Поради това способността да се събират богати показатели, регистрационни файлове и следи и след това да се правят запитвания към тях в дълбочина – тоест, наблюдаемостта – става критична. Това е мястото, където AI влиза в игра, когато отговаря на „преди неизвестния въпрос“: той бързо сканира необработените данни, които имате, предлага модели и аномалии и вие стигате до първопричината, като проверявате тези улики.
Стъпка по стъпка: какво и как да наблюдаваме?
- Изберете правилните показатели. В индустрията за основа се вземат "четири златни сигнала": латентност, трафик, грешки, насищане - колко пълен е ресурсът. Те обобщават състоянието на повечето услуги.
- Събирайте показатели. Нека приложението представи крайна точка, която Prometheus може да прочете.
- Настройте табла за управление. Визуализирайте тези показатели в Grafana.
- Напишете правила за аларма. Кой ще бъде предупреден при превишаване на праг и как?
- Централизиране на регистрационни файлове. Направете всички регистрационни файлове на услугата достъпни за търсене на едно място.
- Намаляване на шума. Твърде много аларма създава „умора от тревога“; Важната аларма изчезва.
Съвет: Добрата аларма отговаря на две неща: тя е активна и има правилната спешност. Аларма, която събужда някого в 3 сутринта, трябва да е нещо, което всъщност изисква намеса през нощта. Не събуждайте никого за нещо, което не изисква действие само по себе си, като "CPU 70%"; покажете го на дъската.
Как да напиша правило за аларма?
Сигналът се състои от три компонента: условие (кой показател надвишава кой праг и за колко време), продължителност („за 5 минути“, за да се избегнат задействането на моментни колебания) и важност/действие (за кого, през кой канал). AI майсторски установява тези три с правилния контекст. Например, превеждането на правило като „критична аларма, ако процентът на грешки надвишава 5% за 5 минути“ в PromQL е задача за част от секундата за AI — но вие решавате дали прагът е подходящ за вашата система.
Внимание: Предложените от AI прагове на алармата са общи предположения. Нормалното натоварване, толерантността и въздействието върху работата на вашата система са различни. Преди да поставите праг директно в prod, преглеждате вашите исторически данни и питате "колко пъти този праг е бил задействан в миналото, колко от тях са били реални проблеми?" Отговорете на въпроса.
Поверителност на регистрационния файл: критично предупреждение
Дневниците са най-често пренебрегваният източник на течове. Ред от регистрационен файл може случайно да съдържа парола, номер на кредитна карта или лични данни (съгласно KVKK/GDPR). Когато поставяте регистрационни файлове в AI за анализ:
- Маскирайте чувствителните зони. Заменете стойности като токен, парола, имейл, идентификационен номер с <REDACTED>.
- Дайте примери, не всички. Вместо милион реда често са достатъчни няколкостотин представителни реда.
- Изберете превозно средство, одобрено от институцията. Специално за производствени регистрационни файлове използвайте инструмент, чиито данни не отиват на обучение.
Четири златни сигнални и алармени маси
сигнал
измерено чрез
Примерен праг на аларма
спешност
латентност
време за реакция
p95 > 800 ms, 5 минути
високо
трафик
Заявка/сек
Внезапно 300% увеличение/намаляване
среден
Грешка
Процент на неуспешни заявки
> 5%, 5 мин
критичен
Насищане
заетост на ресурсите
Диск > 85%
високо
три мини калъфа
Случай 1 — 400 реда дневник, обобщени за 30 секунди. Една услуга се беше забавила. Инженерът даде маскираните 400 реда дневник на AI и каза: „обобщете моделите на повтарящи се грешки и интензивността на времето“. AI показа, че определено външно извикване на API изтича на всеки 30 секунди. Основната причина е открита за 30 секунди; Ръчното сканиране на регистрационни файлове ще отнеме половин час.
Случай 2 — умората на алармата е разрешена. Един екип получаваше по 200 аларми на ден и ги пренебрегваше всички – докато не беше пренебрегната и истинска аларма за прекъсване. Дайте на AI всички правила за предупреждение и попитайте "кои не са приложими и кои могат да бъдат комбинирани?" – попитаха те. Броят на алармите намаля до 12 на ден; Всяка аларма вече се приемаше сериозно.
Случай 3 — грешен праг, уловен рано. YZ предложи "Предупреждение при 95% пълен" за диска. Инженерът погледна исторически данни: след като дискът достигна 95%, нямаше много време за намеса. Той намали прага до 80% и добави втора аларма въз основа на „темп на растеж“. Проверката предотврати действително среднощно прекъсване.
Четири копируеми шаблона
1) Резюмиране на регистрационния файл (маскирано):
Анализирайте примера на регистрационния файл по-долу (маскирах чувствителните стойности с <REDACTED>). Дайте ми: (1) модели на повтарящи се грешки, (2) концентрация във времето, (3) най-вероятната основна причина и (4) 3 показателя, които ще разгледам, за да проверя. Дневник: [LINES]
2) Генериране на правило за аларма:
Напишете правило за аларма за Prometheus/Alertmanager: Генерирайте [SEVERITY] аларма, ако [THRESHOLD] надвиши [METRIC][DURATION]. Правилото трябва да е ориентирано към действие и да включва поле за пояснение и връзка към runbook. Обяснете PromQL и напишете защо този праг е разумен.
3) Писане/деклариране на PromQL заявка:
Напишете PromQL заявка, която измерва: [ПР. 5xx процент на грешки през последните 5 минути]. Обяснете заявката стъпка по стъпка. Тогава ми кажете какъв трябва да бъде здравословният диапазон за тази стойност.
4) Дизайн на таблото:
Проектирайте табло за управление на Grafana за [УСЛУГА]: с кои панели трябва да покажа четирите златни сигнала (закъснение, трафик, грешка, насищане)? Предложете показател, тип визуализация и разумен праг за всеки панел. Цел: да се види здравословното състояние на пазач за 10 секунди.
Слаба подкана / Силна подкана
Слаб: „Какво има в този дневник?“ (последван от 5000 реда необработен дневник, токени в него)
Резултат: издавате тайни и AI дава ненасочено, повърхностно резюме.
Силно: „Намерете модели на повтарящи се грешки и времева интензивност в примера за маскиран дневник с 300 реда по-долу; кажете ми най-вероятната основна причина и показателите, които ще разгледам, за да проверя. Направих токените <РЕДАКТИРАНИ>.“
Разлика: втората подкана дава маскиран и фокусиран пример, изискващ ясен резултат за анализ; Той е едновременно безопасен и полезен.
Често срещани грешки
- Поставяне на дневника в AI без маскиране. Най-често срещаното изтичане на секретни/лични данни.
- Настройване на аларми за всичко. Умората от алармата погребва истинската аларма.
- Бездействаща аларма. Това е предупредителен шум, срещу който никой не може да направи нищо.
- Приемане на прага на AI без съмнение. Прагът трябва да бъде зададен според историята на вашата система.
- Просто гледам показателя. Без лог и проследяване основната причина не може да бъде открита през повечето време.
- Не е зададено време за аларма (за). Моментните колебания предизвикват фалшиви аларми.
В обобщение
Наблюдаемост; Това е способността да се разбере вътрешността на системата отвън с метрики, регистрационни файлове и следи. Четирите златни сигнала (латентност, трафик, грешка, насищане) обобщават здравето на повечето услуги. AI е много мощен при писане на PromQL заявки, правила за аларми и табла за управление, както и при обобщаване на големи части от регистрационни файлове и намиране на аномалии. Но ваша отговорност е да проверявате праговете на алармата спрямо историята на собствената си система, да поддържате алармите ориентирани към действие и никога да не споделяте регистрационни файлове, без да ги маскирате.
Задача за приложение
За услуга (или примерна услуга): (1) Генерирайте правило за аларма за процента грешки с шаблона „Генериране на правило за аларма“ и задайте предложения праг на „колко пъти се е задействало в миналото?“ Тествайте го с въпроса; (2) маскирайте извадка от дневник, която имате, и я анализирайте с шаблона „Обобщаване на дневник“; (3) отбележете кой показател ще разгледате, за да потвърдите най-вероятната основна причина.
контролен списък
- [ ] Избрах показателите за проследяване въз основа на четири златни сигнала.
- [ ] Маскирах всички регистрационни файлове, които дадох на AI по отношение на чувствителни зони.
- [ ] Проверих дали всяка аларма е ориентирана към действие и с правилната спешност.
- [ ] Тествах праговете на алармата спрямо историческите данни на моята система.
- [ ] Филтрирах моментните колебания, като добавих за (продължителност) към алармите.
- [ ] Използвах metric + log + trace заедно за основната причина.