Po fwyaf cymhleth yw'r system, y mwyaf y mae'n gordyfu gyda phob math o rybuddion. Ac mae angen ymateb i'r un rhybuddion hyn, eu hagregu a'u delweddu. Rwy'n meddwl bod hon yn sefyllfa sy'n gyfarwydd i lawer i'r pwynt o nerfusrwydd.
Nid yr ateb a drafodir yw'r mwyaf annisgwyl, ond nid yw'r chwiliad yn dychwelyd erthygl lawn ar y pwnc hwn.
Felly, penderfynais rannu profiad FunCorp a siarad am strwythur y broses ddyletswydd, pwy sy'n galw, pam a sut y gallwch chi edrych ar y cyfan.
Beth yw PagerDuty?
Felly, i ddatrys yr holl broblemau hyn, dechreuon ni chwilio am offeryn cyfleus. Ar ôl ychydig o chwilio, dewisom PagerDuty. Roedd PD yn ymddangos i ni yn ateb gweddol gyflawn a chryno gyda nifer fawr o integreiddiadau a gosodiadau. Beth ydy hi fel?
Yn fyr, mae PagerDuty yn blatfform prosesu digwyddiadau a all brosesu digwyddiadau sy'n dod i mewn trwy amrywiol integreiddiadau, sefydlu gorchmynion dyletswydd ac yna rhybuddio'r peiriannydd ar ddyletswydd yn dibynnu ar lefel y digwyddiad (ar lefel uchel - galwad, ar lefel isel - gwthio o'r cais / SMS).
Pwy yw'r swyddog ar ddyletswydd?
Mae'n debyg mai dyma'r lle cyntaf i ddechrau sefydlu PD.
Yn FunCorp, fel cwmnïau eraill, mae swydd swyddog dyletswydd anrhydeddus. Mae'n cael ei drosglwyddo o beiriannydd i beiriannydd unwaith y dydd. Mae llinell ymateb gyntaf ac ail i rybudd gan PagerDuty fel y'i gelwir. Tybiwch fod rhybudd blaenoriaeth uchel yn cyrraedd, ac os 10 munud ar ôl yr alwad i'r swyddog ar ddyletswydd o'r llinell gyntaf nad oes unrhyw ymateb iddo (h.y., nid yw'n cael ei drosglwyddo i'r statws cydnabod neu wedi'i ddatrys), mae'r alwad yn mynd i'r ail. peiriannydd ar ddyletswydd. Mae hwn wedi'i ffurfweddu yn PagerDuty ei hun trwy Bolisïau Uwchgyfeirio.
Os na fydd yr ail swyddog ar ddyletswydd yn ymateb, bydd yr hysbysiad yn dychwelyd i prif i'r swyddog ar ddyletswydd.
Felly, ni all unrhyw rybudd blaenoriaeth uchel sy'n dod i mewn aros heb ei brosesu.
Nawr gadewch i ni weld o ble y gall digwyddiadau ddod.
Pa integreiddiadau ydyn ni'n eu defnyddio?
Mae PD yn derbyn llawer o wahanol ddigwyddiadau gan wahanol wasanaethau. Ar hyn o bryd mae gennym tua 25 o wasanaethau o'r fath, ac i'w prosesu rydym yn defnyddio rhai integreiddiadau parod.
- Prometheus
Y brif system casglu metrigau yw Prometheus. Mae llawer eisoes wedi'i ysgrifennu amdano ar Habré, byddaf yn dweud bod gennym ni sawl un ar gyfer gwahanol amgylcheddau: mae un yn casglu metrigau o beiriannau rhithwir a docwyr, un arall o wasanaethau Amazon, a'r trydydd o beiriannau caledwedd. Defnyddir Telegraf yn bennaf fel allforiwr metrigau.
- E-bost
Yma hefyd, dwi'n meddwl, mae popeth yn glir o'r teitl. Defnyddir yr integreiddiad hwn i anfon hysbysiadau o rai sgriptiau a weithredir gan cron. Mae PD yn rhoi cyfeiriad penodol i chi yr ydych yn anfon llythyrau iddo. Wrth greu gwasanaeth gydag integreiddio o'r fath, gallwch osod blaenoriaethau, ym mha drefn y bydd digwyddiadau sy'n dod i mewn yn cael eu prosesu, sut yn union i greu rhybudd (ar gyfer pob llythyr sy'n dod i mewn, ar gyfer llythyr sy'n dod i mewn + rheol benodol, ac ati).
- Slac
Yn fy marn i, integreiddio diddorol iawn. Mae yna adegau pan fydd rhywbeth yn digwydd ond nad yw wedi'i gwmpasu gan ddigwyddiadau. Felly, fe wnaethom ychwanegu integreiddio gan Slack i greu digwyddiad. Hynny yw, gallwch chi ysgrifennu at Slack corfforaethol /callofduty mae popeth yn araf a bydd yn torri'n fuan a bydd y PD yn ei brosesu ac yn anfon y digwyddiad at y peiriannydd ar ddyletswydd.
Rydym yn gwneud:
Rydym yn gweld:
- API
Integreiddio HTTP. Mewn gwirionedd, nid oes dim byd arbennig o ddiddorol yma, dim ond cais POST gyda chorff mewn fformat JSON. Er enghraifft, rhywbeth diddorol: rydym yn ei ddefnyddio ar gyfer monitro allanol gan ddefnyddio . Mae'r gwasanaeth hwn yn gwirio hygyrchedd ein gwefannau o wahanol rannau o'r byd. Yn yr achos pan fyddwn yn derbyn cod ymateb annerbyniol (er enghraifft, 502), mae digwyddiad yn cael ei greu ac yna mae popeth yn dilyn y gadwyn a ddisgrifir uchod. Mae gan StatusCake ei hun y gallu i fonitro URLs mewnol, tystysgrif SSL neu barth yn dod i ben.
- LibreNMS
Mae hon yn system fonitro arall, gallwch ddarllen mwy amdano ar eu gwefan . Gyda'i help, rydym yn monitro rhyngwynebau rhwydwaith ac iDRAC o weinyddion.
Roedd yna integreiddiadau hefyd fel Datadog, CloudWatch. Gallwch weld mwy am yr hyn a ddigwyddodd iddynt .
Delweddu
Y brif system adrodd am ddigwyddiadau yw Slack. Mae pob digwyddiad sy'n dod i PD yn cael ei ysgrifennu i sgwrs arbennig, ac os yw eu statws yn newid, mae hyn hefyd yn cael ei arddangos yn y sgwrs.
Pan gododd y cyfle i arddangos data defnyddiol ar sgriniau monitorau yn hongian o'r nenfwd, sylweddolom yn sydyn nad oedd gennym ni (yn yr adran devops) unrhyw beth i'w arddangos arnynt. Mae yna Grafana hyfryd, ond nid yw'n cwmpasu popeth, ac mae gweithwyr yn ymateb i rybuddion, nid siartiau.
Ar ôl chwiliad trylwyr ond aflwyddiannus ar GitHub am “fwrdd” cryno ac addysgiadol ar gyfer PD, fe benderfynon ni ysgrifennu ein rhai ein hunain - dim ond gyda'r hyn yr oedd ei angen arnom. Er bod syniad ar y dechrau i arddangos y rhyngwyneb PD ei hun, roedd yn edrych hyd yn oed yn fwy anghyfleus.
Er mwyn ei ysgrifennu, y cyfan sydd angen i chi ei wneud yw cael allwedd o PD gyda hawliau darllen yn unig.
A dyma beth gawson ni:
Mae'r sgrin yn dangos y digwyddiadau agored cyfredol, enw'r peiriannydd presennol sydd ar ddyletswydd o'r amserlen a ddewiswyd, a'r amser heb ddigwyddiad blaenoriaeth uchel (bydd y panel â digwyddiad blaenoriaeth uchel yn cael ei amlygu mewn coch).
.
O ganlyniad, cawsom ddangosfwrdd cyfleus ar gyfer gweld ein holl ddigwyddiadau. Byddaf yn falch os bydd ein profiad yn ddefnyddiol i rai ohonoch.
Ffynhonnell: hab.com