Јединице
1. Увод у ДевОпс и Цлоуд АИ: улоге, границе, аутентификација, безбедност и тајне 2. Дизајнирање ЦИ/ЦД цевовода са вештачком интелигенцијом: ГитХуб акције и ГитЛаб ЦИ 3. Управљање инфраструктуром као код: вештачка интелигенција са Терраформом и ИаЦ-ом 4. Контејнеризација: Доцкерфиле и оптимизација слике са вештачком интелигенцијом 5. Кубернетес: Манифест, кормило и АИ-поверед оркестрација 6. Мониторинг и опсервабилност: метричка, дневник, правила праћења и аларма 7. Управљање инцидентима и постмортем: анализа корена уз помоћ вештачке интелигенције 8. Оптимизација трошкова у облаку (ФинОпс): Лов на отпад помоћу вештачке интелигенције 9. Генерисање скрипти и аутоматизације: Басх, Питхон и ПоверСхелл 10. Безбедност и управљање тајнама: ДевСецОпс и вештачка интелигенција 11. Провера производа, стратегије издавања и ток АИ рада од краја до краја
Јединица 6 / 11

Мониторинг и опсервабилност: метричка, дневник, правила праћења и аларма

Добици:

  • Способност да се разумеју три стуба уочљивости (метрика, евиденција, траг) и четири златна сигнала и да вештачка интелигенција генерише ПромКЛ упите, правила аларма и контролне табле
  • Способност да спречите замор аларма одржавањем аларма оријентисаним на акцију иу правој хитности и тестирањем прагова у односу на историјске податке вашег сопственог система
  • Способност да се спречи приватност и тајно цурење маскирањем осетљивих области пре него што се записници предају вештачкој интелигенцији

Иако се чини да систем ради, можда умире изнутра: меморија се полако пуни, време одзива се повећава, стопа грешака расте. Једини начин да то приметите је да стално надгледате систем. Напреднији концепт је опсервабилност: способност да се разуме шта се дешава унутар система гледајући његове спољашње знакове. Постоје три стуба уочљивости, а ДевОпс професионалац користи сва три:

  • Метрика: Нумеричке вредности мерене током времена — коришћење ЦПУ-а, број захтева, време одговора, стопа грешке. "Колико?" одговара на питање.
  • Дневник: Записи о текстуалним догађајима које производи систем—„корисник је пријављен“, „веза са базом података је изгубљена“. "Шта се тачно догодило?" одговара на питање.
  • Праћење: Пут којим захтев следи док прелази са услуге на услугу унутар система и трајање сваког корака. „Где је спорост?“ одговара на питање.

Најчешћи алати: Прометхеус за метрику, Графана за визуелизацију, Локи/ЕЛК за дневник, Јаегер/ОпенТелеметри за праћење. АИ је веома вешт у писању језика упита (посебно Прометхеусовог ПромКЛ), правила аларма и конфигурација контролне табле за ове алате. То је такође место где је вештачка интелигенција најјача: сажима велике делове евиденције и метрике и означава аномалије.

Хајде да разјаснимо разлику између надгледања и уочљивости у једној реченици: надгледање је постављање питања која већ знате („Да ли је ЦПУ преко 90%?“); уочљивост је могућност постављања питања која већ нисте знали („зашто се ова чудна спорост дешава само за одређеног купца у одређено време?“). Савремени системи су толико сложени да не можете предвидети све начине квара; Због тога, способност прикупљања богатих метрика, евиденција и трагова, а затим њихово дубински упитник – то јест, видљивост – постаје критична. Овде АИ долази у игру када одговара на „претходно непознато питање“: брзо скенира необрађене податке које имате, предлаже обрасце и аномалије, а ви долазите до основног узрока провером ових трагова.

Корак по корак: шта и како пратити?

  1. Изаберите праве метрике. У индустрији се као основа узимају „четири златна сигнала“: кашњење, саобраћај, грешке, засићење — колико је ресурс пун. Ово сумира здравље већине услуга.
  2. Прикупите метрику. Нека апликација представља крајњу тачку коју Прометеј може да прочита.
  3. Подесите контролне табле. Визуелизирајте ове метрике у Графани.
  4. Напишите правила за аларм. Ко ће бити упозорен када је праг прекорачен и како?
  5. Централизујте дневнике. Омогућите претрагу свих сервисних дневника на једном месту.
  6. Смањите буку. Превише аларма ствара „умор упозорења“; Важан аларм нестаје.
Савет: Добар аларм испуњава две ствари: изводљив је и има праву хитност. Аларм који некога буди у 3 сата ујутро мора бити нешто што заправо захтева ноћну интервенцију. Немојте никога будити због нечега што не захтева акцију само по себи, као што је „ЦПУ 70%“; приказати на табли.

Како написати правило аларма?

Упозорење се састоји од три компоненте: стања (који показатељ прелази који праг и колико дуго), трајања („за 5 минута“ да би се избегле тренутне флуктуације) и важности/радње (коме, кроз који канал). АИ мајсторски успоставља ова три са правим контекстом. На пример, превођење правила попут „критичног аларма ако стопа грешке прелази 5% током 5 минута“ у ПромКЛ је задатак у делићу секунде за АИ – али ви одлучујете да ли је праг исправан за ваш систем.

Опрез: Прагови аларма које предлаже АИ су опште претпоставке. Нормално оптерећење вашег система, толеранција и радни утицај су различити. Пре него што ставите праг директно у прод, погледате своје историјске податке и питате "колико пута је овај праг био активиран у прошлости, колико су од тога били стварни проблеми?" Одговори на питање.

Приватност дневника: критично упозорење

Трупци су извор цурења који се најчешће занемарује. Ред евиденције може случајно да садржи лозинку, број кредитне картице или личне податке (према КВКК/ГДПР). Када налепите логове у АИ ради анализе:

  1. Маска осетљива подручја. Замените вредности као што су токен, лозинка, е-пошта, ИД број са <РЕДИГОВАНО>.
  2. Наведите примере, не све. Уместо милион редова, често је довољно неколико стотина репрезентативних линија.
  3. Изаберите возило које је одобрила институција. Посебно за дневнике производње користите алат чији подаци не иду у обуку.

Четири златна сигнала и таблице аларма

сигнал

мерено по

Пример прага аларма

хитност

латенција

време одговора

п95 > 800 мс, 5 мин

висока

саобраћаја

Захтев/сек

Изненадно повећање/смањење од 300%.

средње

Грешка

Стопа неуспешних захтева

> 5%, 5 мин

критичан

Сатуратион

заузетост ресурса

Диск > 85%

висока

три мини кофера

Случај 1 — 400 редова дневника сумираних у 30 секунди. Услуга је успорила. Инжењер је дао маскираних 400 линија дневника АИ-у и рекао, „сажмите обрасце грешака које се понављају и временски интензитет“. АИ је показао да одређени екстерни АПИ позив истекне сваких 30 секунди. Основни узрок пронађен за 30 секунди; Ручно скенирање дневника трајало би пола сата.

Случај 2 — решен замор аларма. Један тим је примао 200 аларма дневно и све их је игнорисао - све док се није превидио и прави аларм за прекид. Дајте АИ сва правила упозорења и питајте "која од њих нису делотворна и која се могу комбиновати?" питали су. Број аларма се смањио на 12 дневно; Сваки аларм је сада схваћен озбиљно.

Случај 3 — погрешан праг је рано ухваћен. ИЗ је предложио „Упозори када је 95% пун“ за диск. Инжењер је погледао историјске податке: када је диск достигао 95% било је мало времена за интервенцију. Спустио је праг на 80% и додао други аларм на основу „стопе раста“. Верификација је спречила стварни прекид рада у поноћ.

Четири шаблона за копирање

1) Резиме дневника (маскиран):

Анализирајте пример дневника у наставку (маскирао сам осетљиве вредности са <РЕДАГОВАНО>). Дајте ми: (1) обрасце грешака које се понављају, (2) концентрацију током времена, (3) највероватније основни узрок и (4) 3 метрике које ћу погледати да бих проверио. Дневник: [ЛИНЕС]

2) Генерисање правила за аларм:

Напишите правило аларма за Прометхеус/Алертманагер: Генеришите [СЕВЕРИТИ] аларм ако [ТХРЕСХОЛД] премаши [МЕТРИЦ][ДУРАТИОН]. Правило треба да буде оријентисано на радњу и да садржи напомену и поље везе за рунбоок. Објасните ПромКЛ и напишите зашто је овај праг разуман.

3) Писање/декларисање ПромКЛ упита:

Напишите ПромКЛ упит који мери: [ЕКС. 5ккеррор рате проценат у последњих 5 минута]. Објасните упит корак по корак. Онда ми реците који би требао бити здрав распон за ову вредност.

4) Дизајн контролне табле:

Дизајнирајте Графана контролну таблу за [СЕРВИС]: са којим панелима треба да прикажем четири златна сигнала (латенција, саобраћај, грешка, засићеност)? Предложите метрику, тип визуелизације и разумни праг за сваки панел. Сврха: видети здравствено стање чувара за 10 секунди.

Слаби промпт / Јаки промпт

Слаб: "Шта је у том дневнику?" (прати 5000 редова необрађеног дневника, токени у њему)

Резултат: одајете тајне и АИ даје нециљани, површни сажетак.

Снажно: „Пронађите обрасце грешака које се понављају и интензитет времена у доњем примеру маскираног дневника од 300 редова; реците ми највероватнији основни узрок и метрику коју ћу погледати да бих проверио. Направио сам токене <РЕДИГОВАНО>.“

Разлика: други упит даје маскиран и фокусиран пример, тражећи јасан излаз анализе; То је и безбедно и корисно.

Уобичајене грешке

  • Лепљење дневника у АИ без маскирања. Најчешће цурење тајних/личних података.
  • Подешавање аларма за све. Умор од аларма сахрањује прави аларм.
  • Неактиван аларм. То је бука упозорења којој нико ништа не може.
  • Прихватање прага АИ без питања. Праг треба да буде подешен у складу са историјом вашег система.
  • Само гледам метрику. Без евиденције и трага, главни узрок се већину времена не може пронаћи.
  • Не поставља се време аларма (за). Тренутне флуктуације производе лажне аларме.

Укратко

Опсервабилити; То је способност разумевања унутрашњости система споља помоћу метрике, евиденције и трагова. Четири златна сигнала (латенција, саобраћај, грешка, засићење) сумирају здравље већине услуга. АИ је веома моћан у писању ПромКЛ упита, правила аларма и контролних табли, као и у сумирању великих комада евиденције и проналажењу аномалија. Али ваша је одговорност да проверите прагове аларма у односу на историју вашег сопственог система, држите аларме оријентисаним на акцију и никада не делите евиденције без маскирања.

Задатак апликације

За услугу (или пример услуге): (1) Нека се генерише правило аларма за стопу грешке са шаблоном „Генерисање правила аларма“ и поставите предложени праг на „колико пута се оно активирало у прошлости?“ Тестирајте га питањем; (2) маскирајте узорак дневника који имате и анализирајте га помоћу шаблона „Резиме дневника“; (3) забележите који показатељ ћете погледати да бисте потврдили највероватнији основни узрок.

контролна листа

  • [ ] Одабрао сам метрику за праћење на основу четири златна сигнала.
  • [ ] Све записе које сам дао АИ сам маскирао у смислу осетљивих области.
  • [ ] Проверио сам да је сваки аларм оријентисан на акцију и да је хитан.
  • [ ] Тестирао сам прагове аларма у односу на историјске податке мог система.
  • [ ] Филтрирао сам тренутне флуктуације додајући за (трајање) алармима.
  • [ ] Користио сам метрику + дневник + траг заједно за основни узрок.