Ескерту шектерін елемейтіндей етпей қалай баптаймыз?

Шектің өзі ескерту шуын тоқтатпайды. Егер ескерту нақты әрекетпен байланыспаса, шарттағы сан қандай болса да, адамдар оны елемей бастайды. Жақсы ереже сервиске қазір әсер етіп жатқан немесе жақын арада әсер ететін жағдайды хабарлайды, оны түзетуге өкілетті адамға жетеді және алғашқы шешім қабылдауға жеткілікті мәнмәтін береді.

Командалардың түнде келетін жүздеген хабарламаны бір әрекетпен азайтпақ болғанын талай көрдім: CPU шегін 80 пайыздан 90 пайызға көтереді, терезені бес минуттан он минутқа ұзартады немесе ең көп хабар жіберетін арнаны өшіреді. Бір айдан кейін шу қайта оралады, ал оқиғалар кешірек анықталады. Себебі қарапайым: шек, сигналдың тұрақтылығы, бағыттау, топтау және басу әртүрлі міндетті шешеді. Оларды бөлек баптау керек.

Ескерту адамды оятуға лайық болуы керек

Алушы нақты әрекет пен жауап беруге болатын уақытты атай алса ғана ескерту жасалуға тиіс. Егер хабарламадан кейін инженер графикті ашып, тек бақыласа, бұл кезекшіні шақыратын себеп емес, мониторинг панеліне арналған сигнал.

Google SRE ұйымының Monitoring Distributed Systems тарауында белгі мен себептің арасы дұрыс ажыратылған. Белгі «пайдаланушы үшін не бұзылды?» деген сұраққа жауап береді, ал себеп «неліктен?» дегенді түсіндіруге көмектеседі. Шұғыл шақыру үшін белгі көбіне маңыздырақ: сәтсіз сұраулар үлесінің өсуі сервис жұмысының бұзылғанын көрсетеді, ал CPU жүктемесінің 92 пайыз болуы қалыпты жұмыс та, әзірге ешкімге әсер етпеген себеп те болуы мүмкін. Ресурс метрикасы бәрібір қажет, бірақ оның орны көбіне диагностикада немесе жұмыс уақытында орындалатын өтінімде болады.

Ереже жасамас бұрын бес өрісті толтырыңыз:

1. Байқалған зиян: сервистің қай қызметі бұзылды.
2. Алушы: түзетуге қай команда жауап береді.
3. Әрекет: инженер алдымен нені тексереді немесе өзгертеді.
4. Мерзім: зиян ұлғайғанға дейін қанша күтуге болады.
5. Жабу шарты: оқиғаның шынымен аяқталған сәті.

Бір өріс бос қалса, жіберуді қоспаңыз. Алдымен жауапкершілікті, телеметрияны немесе нұсқаулықты түзетіңіз. «Кезекші қарап шықсын» деген тұжырым әсіресе қауіпті: ол инженердің назарын сұрауда іске асырылуға тиіс сүзгіге айналдырады.

Пайдалы тексеріс әдейі қатаң қойылады: соңғы он іске қосылуға ешкім жауап бермесе және ештеңе болмаса, ереже дұрыс емес адамдарға жіберілген немесе дұрыс емес күйді хабарлаған. Оны бірден жоймаңыз. Әуелі шарт жалған болды ма, әрекет автоматты орындалды ма, басымдық тым жоғары қойылды ма, әлде хабарлама басқа сигналды қайталады ма, соны анықтаңыз.

Жеткізілетін мәтінде байқалған белгіні, ауқымды, басталу уақытын, жауапты адамды және алғашқы қауіпсіз әрекетті көрсетіңіз. Өлшем бірлігі, терезесі және күтілетін шегі жоқ 87.3 сияқты мән кезекші инженерді сұрауды қайта талдауға мәжбүрлейді. Нұсқаулыққа сілтеменің өзі әлсіз хабарламаны түземейді: бірінші жол оқиғаны қабылдау керек пе және қай жерді тексеру керек деген шешімге жеткілікті болуға тиіс.

Әр ережеге жауапты адам мен қайта қарау күнін белгілеңіз. Жауапты адам оны тәулік бойы қолмен бақыламайды. Ол өрнектің мағынасына, бағытына және нұсқаулығына жауап береді. Сервис басқа командаға берілгенде, ереже де бірге өтуге тиіс. Иесі жоқ ескертулер әрдайым дерлік шуға айналады, өйткені оларды өзгертуге немесе жоюға ешкімнің өкілеті болмайды.

Шудың қайдан шыққанын күйлер тарихы көрсетеді

Шектерді баптау жаңа сан таңдаудан емес, бірнеше аптадағы күй ауысуларын талдаудан басталады. Басталу және аяқталу уақыты, метрика мәні, белгілер жиыны, алушы, растау, жасалған әрекет және оқиғамен байланыс қажет. Мұндай тарих болмаса, талқылау тез арада жеке пікірлерге тіреледі.

Шулы іске қосылуларды шығу тегіне қарай бөліңіз. Әдетте төрт бөлек түрі кездеседі:

• адам жауап беріп үлгергенше өтіп кететін қысқа секіріс;
• шарттың бірде орындалып, бірде орындалмауына әкелетін шек маңындағы тербеліс;
• артық белгілерден туындаған бір апаттың көптеген данасы;
• маңыздылығы немесе алушысы дұрыс таңдалмаған нақты сигнал.

Бұлардың бәрі бір мәселе емес. Қысқа секіріске күту кезеңі, тербеліске кіру мен шығудың бөлек шектері, даналар тасқынына топтау, ал қате алушыға басқа бағыттау саясаты қажет. Төрт жағдайда да шекті көтеру қауіпті: хабарламалар азаяды, бірақ мәннің өзі дұрыс болған жерде сезімталдық жоғалады.

Тек хабарламалар санын есептемеңіз. Адам әрекет жасаған іске қосылулардың үлесі пайдасын жақсырақ көрсетеді. Сигнал дер кезінде келмеген расталған оқиғаларды, бір оқиға бойынша қайталанған хабарламаларды, ережелерді қолмен өшіруді және растауға кеткен уақытты бөлек белгілеңіз. Жауаптың болмауы кейде зиянның жоқтығын емес, адамдардың қажығанын білдіреді.

Жалған ескерту мен маңызы аз ескертуді араластырмаңыз. Жалған дегеніміз өрнек байқалған күйді дұрыс сипаттамағанын білдіреді. Маңызы аз дегеніміз күй нақты болғанымен, мұндай арна мен жауап мерзімін қажет етпейді. Бірінші жағдайда сұрауды немесе деректерді түзетеді. Екінші жағдайда маңыздылық деңгейі мен бағыт өзгереді.

«Қайталау» сөзінің артында тағы бір түр жиі жасырынады: қысқа уақытқа жабылғаннан кейінгі жаңа хабарлама. Адам үшін бұл сол оқиға, ал жүйе жаңа күйлер тізбегін көреді. Хабарламаларды тек техникалық идентификатор бойынша емес, уақыт терезесі, сервис және қабылданған оқиға бойынша да салыстырыңыз. Сонда мәселе қайта жеткізу жиілігінде емес, қалпына келу шартында екені көрінеді.

Іске қосылулардың сағаттар мен өзгерістер бойынша таралуын тексеріңіз. Резервтік көшіру, пакеттік өңдеу немесе енгізу кезінде жиналған шу алдын ала белгілі жұмыс режимін көрсетеді. Жұмыс қауіпсіз шектен асып кетуі мүмкін болса, мониторингті бүкіл жоспарланған кезеңге өшірмеңіз. Рұқсат етілген әрекетті бөлек шартпен сипаттап, ұзаққа созылу немесе пайдаланушыға зиян келу сигналын сақтаңыз.

Шек салдар мен уақыт қорына қарай таңдалады

Шек командаға байқалатын зиянға дейін аз уақыт қалған шекараны көрсетуге тиіс. Тыныш аптадағы орташа мән бұл шекара туралы ештеңе айтпайды. Метрика, қордың таусылуы және сервистің нақты бұзылуы арасындағы байланысты іздеңіз.

Диск толуы үшін «80 пайыздан көбі пайдаланылды» деген қарапайым шарт әр көлемде бірдей жұмыс істемейді. 100 ГБ дискіде қалған 20 ГБ бірнеше минутта таусылуы мүмкін, ал 20 ТБ дискіде сол пайыз 4 ТБ бос орын қалдырады. Толуға дейінгі болжамды уақытқа негізделген сигнал операциялық сұраққа дәлірек жауап береді. Жазу жылдамдығы кенет өссе, бөлек қорғаныс керек, өйткені сызықтық болжам соңғы әрекетке сүйенеді.

Кідіріс пен қателер үшін пайдаланушы ағынына сәйкес терезе таңдаңыз. Орташа мән үлестірімнің шетін жасырады, ал трафик аз кезде тым тар процентиль бірнеше сұраудан секіреді. Сапаның нашарлауын да, бақылау санының жеткілікті болуын да талап еткен дұрыс. Әйтпесе түнде екі сұраудың бір қатесі «50 пайыз қате» жасайды, бірақ шұғыл жауап ештеңені өзгертпеуі мүмкін.

Қатаң шек бар кезде статикалық шек дұрыс таңдау болып қалады: сертификат мерзімі, мекенжайлар қоры, белгілі ақауға дейінгі кезек ұзындығы, жабдық сипаттамасындағы температура. «Ақылды» динамикалық шек физикалық немесе шарттық шекараны қайта анықтамауға тиіс. Ол маусымдық әрекеттен ауытқуды табуға көмектеседі, бірақ нашар кезеңдерден де үйреніп, баяу нашарлауды жаңа қалыпты күй деп қабылдауы мүмкін.

Әр ережедегі санның негізін қарапайым мәтінмен жазыңыз: «осы жылдамдықпен орын төрт сағатқа жетпей таусылады, ал қауіпсіз кеңейту екі сағат алады». Негізін қайта анықтау мүмкін болмаса, сан түсініксіз қағидаға айналып, жүктеме, архитектура және қалпына келу уақыты өзгерсе де сақталып қалады.

SLO белгіленген сервис үшін барлық жағдайға арналған бір қате шегінен гөрі қателер бюджетінің жұмсалу жылдамдығы пайдалырақ. Қысқа терезе тез өршіген ақауды табады, ал ұзын терезе шығынның тұрақты екенін растайды. Екі терезенің қатар бұзылуы кездейсоқ секіріске жауапты азайтып, ауыр апатты ерте анықтауды сақтайды. Бірақ мұндай сигнал тек SLO анықталып, сәтті оқиғалар дұрыс есептелгенде мағыналы.

Сыйымдылық шегі жеткізу мен инфрақұрылымды өзгерту уақытын ескеруі керек. Кеңейту келісуді, жабдық жеткізуді және көшіруді қажет етсе, өтінім автоматты түрде қауіпсіз қосылатын ресурсқа қарағанда ертерек жасалады. Физикалық серверлері бар ортада қорды диск немесе жад пайызымен ғана өлшемеңіз. Команданың бос сыйымдылықты шынымен қалпына келтіруіне кететін уақытты да қосыңыз.

Күту мен гистерезис әртүрлі қайталауды жояды

Күту кезеңі қысқа бұзылуларды сүзеді, ал гистерезис күйдің бір шек маңында тербелуіне жол бермейді. Бірі екіншісін алмастырмайды. Тұрақсыз шек маңындағы ұзақ күту келесі хабарламаны тек кешіктіреді, ал күтусіз кең гистерезис әрбір күрт секірісті өткізеді.

Prometheus жүйесінде for өрісі өрнектің pending күйінен firing күйіне ауысқанға дейін үздіксіз орындалуын талап етеді. keep_firing_for өрісі шарт жойылғаннан кейін белсенді күйді біраз уақыт сақтайды. Prometheus ресми құжаттамасы екінші өрісті тербелісті және деректердің жоғалуынан болатын жалған жабылуларды азайту үшін қолдануды ұсынады.

Жұмыс істейтін ереже мынадай болуы мүмкін:

groups:
- name: api-slo
  rules:
  - alert: ApiHighErrorRate
    expr: |
      (
        sum(rate(http_requests_total{status=~"5.."}[5m]))
        /
        sum(rate(http_requests_total[5m]))
      ) > 0.05
      and
      sum(rate(http_requests_total[5m])) > 1
    for: 10m
    keep_firing_for: 5m
    labels:
      severity: page
      service: api
      team: platform
    annotations:
      summary: "API returns more than 5% server errors"
      action: "Check recent deployment and upstream availability"

Мұнда сапа шегі ең аз трафиктен бөлінген, он минут қысқа секірістен қорғайды, ал бес минут сақтау бір жақсы өлшемнен кейін хабарламаның жабылып, қайта ашылуына жол бермейді. Бұл сандарды ойланбай көшірмеңіз. for кезеңі жауап беруге болатын уақыттан қысқа, бірақ қалыпты қауіпсіз секірістен ұзақ болуы керек.

Нақты гистерезис кіру мен шығудың әртүрлі шарттарын қажет етеді. Мысалы, толу 85 пайыздан асқанда күйді ашып, 80 пайыздан төмендегенде ғана қалпына келуді тұрақты деп санауға болады. Ережелер жүйесінің бәрі мұны бір шартпен көрсете алмайды. Кейде күйді бөлек метрикаға жазу немесе өңдегіште екі шек қолдану оңайырақ. Жабылу шекке кездейсоқ жанасуды емес, қордың қалпына келгенін білдіруі керек.

for мәнін есептеу жиілігімен сәйкестендіріңіз. Бір минуттық аралықта он минут күту шамамен он рет қатарынан растау береді, ал бес минуттық аралықта небәрі екі рет береді. Ереже сервері қайта іске қосылғанда және қатар уақытша жоғалғанда не болатынын тексеріңіз: пайдаланушы мәселесі сақталса да, күйдің үздіксіздігі үзілуі мүмкін.

Қайтымсыз зиян болып қойғанын білдіретін сигналға ұзақ for қоймаңыз. Резервтеу жұмыс істеп тұрса, бір репликаның жоғалуы растауды күте алады. Деректердің расталған бұзылуы, сертификат мерзімінің өтуі немесе жалғыз кіру нүктесінің қолжетімсіздігі басқа логиканы қажет етеді. Ондайда жалған шақырудан өлшем сапасын жақсарту және тәуелсіз растау арқылы қорғанады, күту арқылы емес.

Дереккөз бойынша емес, оқиға бойынша топтаңыз

Бір жағдайды жүздеген дана анықтаса да, бір хабарлама бір операциялық жағдайды сипаттауы керек. Alertmanager бірдей белгілер жиынын қайталамайды және байланысты ескертулерді бір жеткізілімге топтай алады. Бірақ белгілерді дұрыс таңдамау әр оқиғаны бірегей етеді.

request_id, қатенің толық мәтіні, уақытша контейнер атауы немесе метриканың дәл мәні сияқты белгілер әрдайым дерлік бақыланбайтын кардиналдық жасайды. Сәйкестікте иесін анықтайтын және тәуелсіз апаттарды ажырататын тұрақты сипаттарды қалдырыңыз: сервис, кластер, өңір, команда, маңыздылық класы. Дана туралы мәліметтерді аннотацияға орналастыруға немесе панельден ашуға болады.

Бағыт конфигурациясы қағиданы көрсетеді:

route:
  receiver: operations
  group_by: [cluster, service, alertname]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
  - matchers:
    - severity="page"
    receiver: oncall
    repeat_interval: 30m

group_wait байланысты оқиғалардың алғашқы жеткізілімге жиналуына қысқа уақыт береді. group_interval бар топ ішіндегі өзгерістердің қаншалық жиі жіберілетінін анықтайды. repeat_interval күй жалғасса, еске салу уақытын басқарады. Соңғысын барлық класс үшін бірдей қоймаңыз: жарты сағат сайын еске салу ұзаққа созылған ауыр апатқа жарайды, бірақ жұмыс уақытындағы өтінімді спамға айналдырады.

Тек team бойынша топтамаңыз. Әртүрлі сервистердегі тәуелсіз апаттар бір хабарламаға бірігіп, даналардың бір бөлігі жабылғанын түсіну қиындайды. Әдепкіде instance қоспаңыз. Әр дана бөлек әрекетті қажет етіп, команда оларды қатар орындай алса ғана әр данаға жеке шақыру орынды.

Тым үлкен group_wait жинақы қорытынды үшін алғашқы шақыруды кешіктіреді. Ауыр бағытта ол жауап уақытының аз бөлігі болып қалуы керек. Тым қысқа аралық алғашқы ұшқынды бөлек жіберіп, бірнеше секундтан кейін тасқын қосады. Оны апаттың өзара тәуелді тексерістер арасында әдетте қаншалық жылдам тарайтынына қарай таңдаңыз.

Қайталамау тұрақты белгілерге тәуелді. Метрика мәні бар аннотацияны байқамай белгіге айналдырса, әр есептеу жаңа таңба алып, қайталамауды айналып өтеді. Ереже үлгісінде белгілер келісімін бекітіп, өзгерістерді автоматты тексеріңіз. Бұл бір шарттың неліктен жүздеген «бірегей» оқиға жасағанын іздеуден арзанырақ.

Басу нақты тәуелділікті көрсетуге тиіс

Белгілі негізгі апат кейінгі белгілерді түсіндірсе, негізгі сигналды жіберіп, салдарын басыңыз. Alertmanager мұны inhibition деп атайды: equal тізіміндегі белгілері сәйкес бастапқы ескерту белсенді тұрғанда, мақсатты ескерту жеткізілмейді.

Кластер қолжетімсіз болса, әр сервис пен түйін туралы хабарлама бөлек әрекет қоспайды. Басу ережесі сол кластердегі InstanceDown хабарламасын жасырып, ClusterUnreachable шақыруын қалдыра алады:

inhibit_rules:
- source_matchers:
  - alertname="ClusterUnreachable"
  - severity="page"
  target_matchers:
  - alertname="InstanceDown"
  equal: [cluster]

cluster бойынша сәйкестік көрші кластерлерді кездейсоқ басудан қорғайды. Alertmanager ресми конфигурациясы бір нәзік жайтты ескертеді: жоқ белгі мен бос мәні бар белгі тең деп саналады. Сондықтан equal ішіндегі өрістер екі ережеде де болуы және тексерілуі керек. Әйтпесе белгісі жоқ бастапқы оқиға байланыстырғыңыз келмеген мақсаттарды өшіруі мүмкін.

Басу уақытша тыныштықтан өзгеше. Оператор жұмыстар кезеңіне silence жасайды, ол белгілер бойынша сәйкес келеді. Inhibition сигналдар арасындағы тәуелділікті тұрақты түрде кодтайды. Шулы ережені түзетудің орнына ұзақ тыныштық қолданбаңыз: мерзім біткенде тасқын қайта келеді, ал себебі белгісіз қалады.

Автоматты басу тек негізгі сигнал сенімді болғанда жарайды. Егер ClusterUnreachable сол бұзылған жинау жүйесіне тәуелді болса, кейінгі хабарламалар жалғыз дәлел болып қалуы мүмкін. Ережені мұрағаттағы оқиғамен және дереккөз жоғалғанда тексеріңіз, содан кейін басылған оқиғалар диагностика үшін интерфейсте көрінетініне көз жеткізіңіз.

Жоспарлы қызмет көрсету терезесі үшінші міндетті шешеді. Ол белгілі нысанның күтілетін әрекетін уақытша өзгертеді, бірақ сигналдар арасындағы тәуелділікті дәлелдемейді. Терезені сервис, кластер және уақыт бойынша тар етіп, авторы мен себебін көрсетіңіз. Түнге бүкіл арнаны өшіру көрші апаттарды жасырып, жұмыстардан кейін түсініксіз күй қалдырады.

Болжамды себеп белсенді екен деп пайдаланушыға келген зиян белгісін баспаңыз. Дерекқор қолжетімсіз болып, сыртқы тексеріс төлемдердің өтпегенін растаса, кезекшіге негізгі оқиғадан пайдаланушы әсерінің ауқымын көрген пайдалы. Артық шақыруларды басыңыз, бірақ белгілерді апаттың дамуы туралы дерек ретінде оқиға карточкасында немесе тобында сақтаңыз.

Маңыздылық жеткізу тәртібін анықтайды

Маңыздылық белгісі ереже авторының эмоциялық бағасын емес, жауап мерзімін, арнаны және алушы өкілетін анықтауы керек. Команда әр класқа не істейтінін келіспейінше, critical, warning және info сөздерінің пайдасы жоқ.

Іс жүзіндегі схема салдардан басталады:

• page: зиян қазір болып жатыр немесе келесі жұмыс уақытына дейін басталады, дереу әрекет қажет;
• ticket: уақыт қоры жауапты адамды тағайындап, жұмыс уақытында түзетуге мүмкіндік береді;
• info: оқиға іздеу және талдау үшін сақталады, адамға жіберілмейді;
• security: қолжетімділікке немесе деректерге әсер етуі мүмкін болса, бекітілген тәртіп бойынша бөлек бағыт қолданылады.

«Әйтпесе ешкім қарамайды» деп маңыздылықты көтермеңіз. Бұл өтінімдер кезегінің жұмыс істемейтінін мойындау. Шұғыл арна да көп ұзамай сол мәселеге тап болады, ал нақты апаттар назар аудартуға тырысқан хабарлардың арасында жоғалады.

Ауқым мен шұғылдықты бөліңіз. Резервтелген кластердегі бір түйіннің істен шығуы техникалық жағынан ауқымды, бірақ пайдаланушы үшін шұғылдығы төмен болуы мүмкін. Авторизацияның шағын компонентіндегі қате барлық кіруді тоқтатып, дереу шақыруды қажет етуі мүмкін. Бағытты сервер өлшеміне немесе компонент атауының салмағына емес, зиянға дейінгі уақыт пен жүйенің қалпына келу қабілетіне қарай құрыңыз.

Әр класта қайталау шегі болуы керек. page үшін растау және жауапты адам жауап бермесе, жоғары деңгейге өткізу қажет. ticket үшін бір рет ашу және елеулі өзгерістердегі жаңарту жеткілікті. info байқатпай электрондық поштаға түспеуі керек: толған бума да адамдарды жүйелік хабарларды оқымауға үйретеді.

Бір ереже әр ортада әртүрлі маңыздылыққа ие болуы мүмкін, бірақ айырмасын түсіндіріңіз. Сынақ ортасындағы түйін ақауы әдетте өтінім жасайды, ал өндірістік сервистегі жалғыз түйіннің ақауы кезекшіні шақырады. Ортаны ереже атауына енгізбеңіз. Тұрақты белгі мен анық бағыттау саясатын қолданыңыз, әйтпесе көшірмелердің логикасы біртіндеп алшақтайды.

Алушының әрекетті орындай алатынын тексеріңіз. Қолдау қызметі пайдаланушы әсерін тіркей алады, бірақ кластерге қолжетімділігі болмауы мүмкін. Платформа инженері инфрақұрылымды көреді, бірақ қаржылық операцияны тоқтату туралы шешім қабылдамайды. Күрделі апатта бір бағыт оқиға жетекшісін тағайындайды, ал басқа командалар бірдей тәуелсіз шақыру алудың орнына бекітілген тәртіппен қосылады.

Деректердің жоғалуы қалыпты күйді білдірмейді

Нәтижесіз сұрау, жоғалған қатар және есептеу қатесі әртүрлі ақауды білдіреді. Олардың кез келгенін нөлге айналдыру ыңғайлы, бірақ қауіпті: мониторинг жүйесі сервисті көруді тоқтатқан сәтте оның сау екенін көрсетуі мүмкін.

Grafana No Data, Error және жеке қатардың жоғалуын ажыратады. No Data сұрау орындалып, бірақ бірде-бір нүкте қайтармағанда пайда болады. Error сұраудың қатесін немесе уақыт шегінен асқанын білдіреді. Бір қатар жоғалғанда деректің бір бөлігі қалады, сондықтан жалпы ереже есептеле беріп, нақты өңір немесе дана туралы үндемеуі мүмкін.

Саясатты метрика мағынасына қарай белгілеңіз. Мерзімді пакеттік тапсырма үшін іске қосылулар арасындағы нүктелердің болмауы қалыпты. Төлем шлюзінің жүрек соғысы үшін оның жоғалуы өзі белгі болып саналады. Prometheus жүйесіндегі absent_over_time(metric[5m]) функциясы терезеде қатардың толық жоғалуын табады, бірақ жоғалған дананы көрсетуге керек белгілер жиынын үнемі сақтамайды. Динамикалық ортада даналардың қолмен жазылған тізімі тез ескіреді.

Әр DatasourceError хабарламасын қолданба иесіне жібермеңіз. Ортақ дереккөздің қатесі әр ережеге жеке көшірме жасай алады. Мұндай оқиғаларды дереккөз идентификаторы бойынша топтап, мониторинг командасына жіберіңіз, ал пайдаланушы сервисінің күйін тәуелсіз сыртқы сигналмен тексеріңіз. «Соңғы күйді сақтау» қысқа үзілісте пайдалы, бірақ дереккөздің ұзақ үнсіздігі бөлек ескертуді қажет етеді.

Мониторингке жеткізуді тексеру де қажет. Prometheus ресми тәжірибесі әр буын туралы бөлек хабарлама орнына дереккөзден Prometheus пен Alertmanager арқылы алушыға дейін баратын мерзімді сигнал сияқты толық жолды тексеруді ұсынады. Мұндай тексеріс негізгі сұраққа жауап береді: арна дәл қазір адамды шақыра ала ма?

Метриканың жаңалығын оның мәнінен бөлек тексеріңіз. Датчик екі сағат үнсіз тұрса, соңғы белгілі 40 градус температура жабдықтың қазір салқын екенін дәлелдемейді. Соңғы сәтті өлшем уақытын және деректің рұқсат етілетін жасын қосыңыз. Маңызды дереккөздер үшін жаңалықты тәуелсіз жолмен жинаңыз, сонда бір агенттің ақауы метриканы да, оның жоғалу белгісін де жасыра алмайды.

Сұрау қатесі мен бақыланатын сервис қатесін атауы және бағыты бойынша ажыратыңыз. ApiHighErrorRate және ApiAlertQueryFailed әртүрлі әрекетті, көбіне әртүрлі жауапты адамды қажет етеді. Оларды бір атауға біріктірсеңіз, кезекші таныс тақырыпты көргенімен, мағынасы керісінше болады: қолданба дұрыс істеп, тек есептеу бұзылған болуы мүмкін.

Ережелер бақыланатын тәжірибе арқылы өзгереді

Шекті өзгерту тарихи деректерде тексеріліп, шектеулі бақылау кезеңінен өткенде ғана аяқталады. Ескі және жаңа өрнекті бірдей аралықта салыстырыңыз: әрқайсысы қанша нақты оқиғаны тапты, неше рет әрекет жасатты, қаншалық тез іске қосылды және неше бөлек жеткізілім жасады.

Шекті, терезені, for, топтауды және бағытты бір уақытта өзгертпеңіз. Шу жоғалса, себебін білмейсіз. Қажетті сигнал жоғалса, сезімталдықты қалпына келтіру де қиын болады. Бір мағыналы өзгеріс жасаңыз, күтілетін әсер мен қайта қарау мерзімін жазыңыз.

Жаңа ереже үшін алдымен шұғыл жеткізусіз есептеуді қосыңыз. Күйді журналға немесе сынақ қабылдағышына жазсын. Белгілі нашар аралықты, қалыпты жүктеме шыңын, енгізуді және деректердің жоғалуын өткізіңіз. Содан кейін жұмыс бағытын қосып, тексеру күнін белгілеңіз. Бұл мерзімсіз «көлеңкелі режим» емес: күн қойылмаса, ереже жылдар бойы ештеңені қорғамай тұруы мүмкін.

Айына бір рет жиі іске қосылған, мүлдем қосылмаған және өшірулі қалған ережелерді қарап шығыңыз. Оқиғалардың болмауы сапаны дәлелдемейді: шарт сирек тәуекелден қорғауы мүмкін немесе метрика атауларымен бұрыннан үйлеспеуі мүмкін. Архитектура қатты өзгергеннен кейін жауапты адам сұрауды, бағытты және әрекетті растауға тиіс.

Ереже өзгерісінің қасына себебін сақтаңыз: оқиға идентификаторы, шудың күтілетін азаюы, өткізіп алу тәуекелі және кері қайтару әдісі. Үш айдан кейін 10m санының себебін ешкім есіне түсірмейді, ал жазба оның қай қауіпсіз секірісті сүзуге арналғанын көрсетеді. Жүктеме сипаты өзгерсе, шешімді қайтадан жадқа сүйеніп талқыламай, есептеуге болады.

Іске қосылғаннан кейінгі бағалау екі сұраққа жауап беруі керек. Бір оқиғаға шаққандағы жеткізілім саны азайды ма және маңызды апаттарды анықтау уақыты сақталды ма? Өткізіп алынған оқиғалар көбейген кездегі шудың азаюы жақсарту емес. Дұрыс баптау көрінбейтін зиян есебінен тыныштық сатып алмай, қажетсіз алаңдатуды азайтады.

GSE инфрақұрылымдық жобаларында біз мониторинг схемасын зауыттық шектер жиыны ретінде қалдырмай, оны ЦОД құрамдастарына, жауапкершілік аймақтарына және қолдау тәртібіне байланыстырамыз. Бұл бір оқиға жабдық, платформа және қолданбалы сервис арқылы өтетін аралас ортада ерекше маңызды.

Шұғыл арнада мына сөйлемді аяқтауға болатын ережелерді ғана қалдырыңыз: «Бұл іске қосылса, кезекші көрсетілген мерзімге дейін мына әрекетті орындайды». Қалған сигналдарды жоғалтудың қажеті жоқ. Оларға дұрыс орын белгілеңіз: өтінім, панель, журнал немесе адамсыз автоматика түзететін шарт.