Добивки:
- Способност да се разберат трите столба на набљудување (метричка, лог, трага) и четирите златни сигнали и вештачката интелигенција да генерира PromQL прашања, правила за аларм и контролни табли
- Способност да се спречи замор на алармот со тоа што алармите се ориентирани кон акција и на вистинските прагови за итност и тестирање во однос на историските податоци на вашиот сопствен систем
- Способност да се спречи приватност и тајно истекување со маскирање на чувствителните области пред да се дадат дневниците на вештачката интелигенција
Додека системот може да изгледа дека работи, тој може да умира внатре: меморијата полека се пополнува, времето на одговор се зголемува, стапката на грешки се зголемува. Единствениот начин да се забележи ова е постојано да се следи системот. Понапреден концепт е набљудувањето: способност да се разбере што се случува внатре во системот со гледање на неговите надворешни знаци. Постојат три столба на набљудување, а професионалецот DevOps ги користи сите три:
- Метрика: нумерички вредности измерени со текот на времето - користење на процесорот, број на барања, време на одговор, стапка на грешки. „Колку? одговара на прашањето.
- Дневник: записи за текстуални настани произведени од системот - „корисникот е најавен“, „изгубена врска со базата на податоци“. „Што точно се случи? одговара на прашањето.
- Трага: патеката што ја следи барањето додека поминува од услуга до услуга во системот и времетраењето на секој чекор. „Каде е бавноста? одговара на прашањето.
Најчести алатки: Prometheus за метрика, Grafana за визуелизација, Loki/ELK за дневник, Jaeger/OpenTelemetry за трага. Вештачката интелигенција е многу вешт во пишувањето на јазиците за прашања (особено Prometheus's PromQL), правилата за аларм и конфигурациите на контролната табла за овие алатки. Тоа е, исто така, местото каде што вештачката интелигенција е најсилна: сумирање на големи делови од логови и метрика и означување на аномалии.
Ајде да ја разјасниме разликата помеѓу следењето и набљудувањето во една реченица: мониторингот е поставување прашања што веќе ги знаете („Дали процесорот помина 90%?“); набљудување е можност да поставувате прашања што веќе не сте ги знаеле („зошто оваа чудна бавност се случува само за одреден клиент во одредено време?“). Современите системи се толку сложени што не можете да ги предвидите сите начини на неуспех; Затоа, способноста да се соберат богати метрики, логови и траги, а потоа длабински да се побараат - односно да се набљудуваат - станува критична. Ова е местото каде што вештачката интелигенција стапува во игра кога одговара на „претходно непознатото прашање“: таа брзо ги скенира необработените податоци што ги имате, предлага шеми и аномалии и ќе стигнете до основната причина со потврдување на овие индиции.
Чекор по чекор: што и како да се следи?
- Изберете ја вистинската метрика. Во индустријата, како основа се земаат „четири златни сигнали“: латентност, сообраќај, грешки, заситеност - колку е полн ресурсот. Овие го сумираат здравјето на повеќето услуги.
- Собери метрика. Нека апликацијата претстави крајна точка што Прометеј може да ја чита.
- Поставете контролни табли. Визуелизирајте ги овие метрики во Графана.
- Напишете правила за аларм. Кој ќе биде предупреден кога ќе се надмине прагот и како?
- Централизирајте ги дневниците. Направете ги сите дневници за услуги да се пребаруваат на едно место.
- Намалете ја бучавата. Премногу аларм создава „буден замор“; Важниот аларм исчезнува.
Совет: Добриот аларм исполнува две работи: може да се примени и има вистинска итност. Алармот што буди некого во 3 часот наутро мора да биде нешто што всушност бара ноќна интервенција. Не разбудувајте никого за нешто што не бара акција самостојно, како „CPU 70%“; прикажете го на табла.
Како да напишете правило за аларм?
Предупредувањето се состои од три компоненти: состојба (која метрика го надминува кој праг и колку долго), времетраење („за 5 минути“ за да се избегне активирање на моментални флуктуации) и важност/дејство (на кого, преку кој канал). ВИ мајсторски ги воспоставува овие три со вистинскиот контекст. На пример, преведувањето на правило како „критичен аларм ако стапката на грешка надминува 5% за 5 минути“ во PromQL е задача во дел од секундата за вештачката интелигенција - но вие одлучувате дали прагот е соодветен за вашиот систем.
Внимание: Праговите за аларм предложени од вештачката интелигенција се општи претпоставки. Нормалното оптоварување, толеранцијата и влијанието на работата на вашиот систем се различни. Пред да ставите праг директно во прод, ги гледате вашите историски податоци и прашувате „колку пати овој праг бил активиран во минатото, колку од нив биле вистински проблеми? Одговорете на прашањето.
Приватност на дневникот: критично предупредување
Дневниците се најчесто занемарениот извор на протекување. Линијата за дневник може случајно да содржи лозинка, број на кредитна картичка или лични податоци (според KVKK/GDPR). Кога залепувате логови во вештачка интелигенција за анализа:
- Маскирај ги чувствителните области. Заменете ги вредностите како токен, лозинка, е-пошта, идентификациски број со <REDACTED>.
- Наведи примери, не сите. Наместо милион линии, често се доволни неколку стотици репрезентативни линии.
- Изберете возило одобрено од институција. Особено за дневници за производство, користете алатка чии податоци не одат на обука.
Четири златни сигнали и алармни табели
сигнал
мерено со
Пример праг на аларм
итност
латентност
време на одговор
p95 > 800 ms, 5 мин
високо
сообраќајот
Барање/сек
Ненадејно зголемување/намалување од 300%.
средно
Грешка
Стапка на неуспешни барања
> 5%, 5 мин
критички
Заситеност
зафатеност на ресурси
диск > 85%
високо
три мини футроли
Случај 1 - 400 реда дневник сумирани во 30 секунди. Еден сервис беше забавен. Инженерот ги дал маскираните 400 линии на дневник на вештачката интелигенција и рекол: „Сумирајте ги повторливите шеми на грешки и временскиот интензитет“. AI покажа дека одреден надворешен API повик истекува на секои 30 секунди. Откриена основна причина за 30 секунди; Рачното скенирање на дневниците би траело половина час.
Случај 2 — решен замор од аларм. Еден тим добиваше 200 аларми дневно и ги игнорираше сите - додека не се занемари и вистински аларм за прекин. Дајте ѝ ги на вештачката интелигенција сите правила за предупредување и прашајте „кои не се постапливи и кои може да се комбинираат? прашаа тие. Бројот на аларми се намали на 12 дневно; Сега секој аларм беше сфатен сериозно.
Случај 3 - погрешен праг фатен рано. YZ предложи „Предупреди кога е 95% полн“ за дискот. Инженерот ги разгледа историските податоци: штом дискот достигна 95% имаше малку време за интервенција. Го намали прагот на 80% и додаде втор аларм заснован на „стапка на раст“. Потврдата спречи вистински прекин на полноќ.
Четири шаблони за копирање
1) Резимирање на дневникот (маскирано):
Анализирајте го примерот на дневникот подолу (ги маскирав чувствителните вредности со <REDACTED>). Дајте ми: (1) повторливи шеми на грешки, (2) концентрација со текот на времето, (3) најверојатно основна причина и (4) 3 метрики што ќе ги разгледам за да ги потврдам. Дневник: [LINES]
2) Генерирање на правила за аларм:
Напишете правило за аларм за Prometheus/Alertmanager: Генерирајте [SEVERITY] аларм ако [THRESHOLD] надмине [METRIC][DURATION]. Правилото треба да биде ориентирано кон акција и да вклучува поле за врска со прибелешки и рачни книги. Објаснете го PromQL и напишете зошто овој праг е разумен.
3) Пишување/објавување на барање PromQL:
Напишете барање PromQL кое мери: [EX. 5xxerror процент во последните 5 минути]. Објаснете го барањето чекор по чекор. Потоа кажи ми колкав треба да биде здравиот опсег за оваа вредност.
4) Дизајн на контролната табла:
Дизајнирајте ја контролната табла на Grafana за [SERVICE]: со кои панели треба да ги прикажам четирите златни сигнали (латентност, сообраќај, грешка, заситеност)? Предложете метрика, тип на визуелизација и разумен праг за секој панел. Цел: да се види здравствената состојба на чуварот за 10 секунди.
Слаб промпт / Силен промпт
Слаб: "Што има во тој дневник?" (проследено со 5000 линии суров трупец, токени во него)
Резултат: откривате тајни и вештачката интелигенција дава нетаргетирано, површно резиме.
Силно: „Пронајдете ги повторливите шеми на грешки и интензитетот на времето во примерот на маскиран дневник со 300 линии подолу; кажете ми ја најверојатната основна причина и метриката што ќе ги разгледам за да ги потврдам. Ги направив токените <REDACTED>“.
Разлика: вториот промпт дава маскиран и фокусиран пример, барајќи јасен резултат на анализа; Тоа е и безбедно и корисно.
Вообичаени грешки
- Вметнување на дневникот во вештачка интелигенција без да се маскира. Најчесто истекување на тајни/лични податоци.
- Поставување аларми за сè. Заморот од аларм го закопува вистинскиот аларм.
- Аларм што не може да се дејствува. Тоа е предупредувачка бучава за која никој ништо не може да направи.
- Прифаќање на прагот на вештачка интелигенција без прашање. Прагот треба да се постави според историјата на вашиот систем.
- Само гледајќи ја метриката. Без дневник и трага, главната причина не може да се најде поголемиот дел од времето.
- Непоставување време на аларм (за). Моменталните флуктуации произведуваат лажни аларми.
Сумирано
Набљудливост; Тоа е способност да се разбере внатрешноста на системот однадвор со метрика, логови и траги. Четирите златни сигнали (латентност, сообраќај, грешка, сатурација) го сумираат здравјето на повеќето услуги. Вештачката интелигенција е многу моќна во пишувањето барања за PromQL, правила за аларм и контролни табли, како и во сумирање на големи делови од дневници и наоѓање аномалии. Но, ваша одговорност е да ги потврдите праговите за аларми во однос на историјата на вашиот сопствен систем, да ги одржувате алармите ориентирани кон акција и никогаш да не споделувате дневници без да ги маскирате.
Задача за апликација
За услуга (или примерок на услуга): (1) Дали е генерирано правило за аларм за стапката на грешка со шаблонот „Генерирање правило за аларм“ и поставете го предложениот праг на „колку пати се активирал во минатото? Тестирајте го со прашањето; (2) маскирајте примерок од дневникот што го имате и нека го анализираат со шаблонот „Сумирање на дневник“; (3) забележете која метрика ќе ја погледнете за да ја потврдите најверојатната основна причина.
листа за проверка
- [ ] Избрав метрика за следење врз основа на четири златни сигнали.
- [ ] Ги маскирав сите дневници што и ги дадов на вештачката интелигенција во однос на чувствителните области.
- [ ] Потврдив дека секој аларм е ориентиран кон акција и со правилна итност.
- [ ] Ги тестирав праговите за аларм според историските податоци на мојот систем.
- [ ] Ги филтрирав моменталните флуктуации со додавање за (траење) на алармите.
- [ ] Користев метрика + дневник + трага заедно за основната причина.