• Autor
• Blog
• Top 16
• Biblioteka
• Top YT
• Odnośniki

Szukaj:

• Bazy danych
• Bezpieczeństwo
• Oprogramowanie
• Programowanie
• Przechowywanie danych
• Testowanie

Enterprise Tech Solutions Meetup: jak zbudować skuteczny system monitoringu

Spotkanie roz­po­czę­ło się od wy­stą­pie­nia Mateusza Beczka za­ty­tu­ło­wa­ne­go „Kiedy mo­ni­toring śpi, bu­dzą się awarie: ana­li­za przy­pad­ków”. Jako naj­częst­sze przy­czy­ny awarii apli­kac­ji wy­mie­nił on błę­dy w ko­dzie, nie­peł­ne po­kry­cie te­sta­mi, pra­ce pro­wa­dzo­ne na infra­struk­tu­rze pro­duk­cyj­nej, błę­dy ludz­kie oraz chwi­lo­we wzros­ty na­tę­że­nia ru­chu. Awarie mo­gą mieć też róż­ne po­sta­ci. Aplikac­ja mo­że dzia­łać wol­niej niż zwyk­le, nie­dos­tęp­ne mo­gą być nie­któ­re funk­cje sys­te­mu, a w skraj­nych sytu­acjach wszyst­ko mo­że prze­stać dzia­łać. Wbrew po­zo­rom, rów­nież pla­no­wa­na nie­dos­tęp­ność apli­kac­ji jest sytua­cją nie­po­żą­da­ną, sta­no­wią­cą swe­go ro­dza­ju awa­rię. Dlatego wszel­kie pla­no­wa­ne przer­wy w dzia­ła­niu sys­te­mu na­le­ży wcześ­niej za­ko­mu­ni­ko­wać użyt­kow­ni­kom.

Rozróżnie­nia wy­ma­ga­ją ter­mi­ny „in­cy­dent” oraz „prob­lem”. Incydent to ja­kie­kol­wiek za­kłó­ce­nie dzia­ła­nia apli­kac­ji. Przywróce­nie jej po­praw­ne­go dzia­ła­nia roz­wią­zu­je in­cy­dent na­wet jeś­li nie uda­ło się usta­lić przy­czy­ny zja­wi­ska. Z kolei prob­lem to przy­czy­na po­ja­wia­nia się in­cy­den­tów, naj­częś­ciej po­cząt­ko­wo nie­zna­na. Na pod­sta­wie ana­li­zy po­dob­nych in­cy­den­tów moż­na do­trzeć do przy­czy­ny prob­le­mu, roz­poz­nać go i zlik­wi­do­wać, za­po­bie­ga­jąc po­ja­wia­niu się ko­lej­nych in­cy­den­tów te­go sa­me­go ty­pu.

Incydent mo­że zo­stać zgło­szo­ny przez sys­tem auto­ma­tycz­ny lub przez klien­tów. Niezależnie od źród­ła, w mo­men­cie po­ja­wie­nia się no­we­go zgło­sze­nia roz­po­czy­na się wy­ścig z cza­sem. Najpierw prze­pro­wa­dza­ne są kon­sul­tac­je prio­ry­te­tu in­cy­den­tu, w któ­rym uczest­ni­czą przed­sta­wi­cie­le klienta oraz opie­ku­na apli­kac­ji. Następ­nie po­wo­ły­wa­na jest gru­pa, któ­ra ma roz­wią­zać in­cy­dent. Jeżeli ska­la zja­wi­ska jest więk­sza, in­cy­dent pod­le­ga eska­lac­ji a do gru­py włą­cza­ni są przed­sta­wi­cie­le in­nych ze­spo­łów apli­ka­cyj­nych. Po przy­wró­ce­niu po­praw­ne­go dzia­ła­nia sys­te­mu prze­pro­wa­dza się też ana­li­zę post mortem, by w mia­rę moż­li­woś­ci okreś­lić przy­czy­nę prob­le­mu.

Jest bar­dzo istot­ne, by po po­myśl­nym zam­knię­ciu in­cy­den­tu opi­sać w zgło­sze­niu wszyst­kie pod­ję­te dzia­ła­nia oraz po­dej­rze­nia co do przy­czy­ny prob­le­mu. Pomoże to gru­pie w mo­men­cie zgło­sze­nia na­stęp­ne­go, po­dob­ne­go lub wręcz ta­kie­go sa­me­go in­cy­den­tu. Zgłoszenie po­win­no też zo­stać uzu­peł­nio­ne o su­ge­stie prac na­praw­czych, któ­re ma­ją za­po­biec po­wtór­ne­mu po­ja­wia­niu się te­go ty­pu in­cy­den­tów lub ułat­wić ich diag­no­zo­wa­nie.

Po tym sze­ro­kim wstę­pie teore­tycz­nym pre­le­gent prze­szedł do opi­su pa­ru przy­pad­ków ilustru­ją­cych za­sto­so­wa­nie opi­sa­nych tech­nik. W pierw­szym przy­pad­ko­we za­stą­pie­nie wzor­ca pro­to­ty­pu wzor­cem singleton unie­moż­li­wi­ło zwal­nia­nie za­so­bów i pro­wa­dzi­ło do stop­nio­we­go zmniej­sza­nia wy­daj­noś­ci apli­kac­ji. Doraźne kro­ki za­rad­cze po­le­ga­ją­ce na wy­łą­cza­niu nie­któ­rych mo­du­łów apli­kac­ji po­wo­do­wa­ły chwi­lo­wą po­pra­wę, jed­nak zwol­nio­ne za­so­by by­ły wkrót­ce zaj­mo­wa­ne przez wy­ciek i wy­daj­ność znów spa­da­ła. Dopiero po dłuż­szej ana­li­zie uda­ło się zna­leźć błąd ar­chi­tek­to­nicz­ny, wdro­żyć po­pra­wio­ną wer­sję apli­kac­ji oraz – co istot­ne – uzu­peł­nić sys­tem nad­zo­ro­wa­nia o wskaź­ni­ki po­zwa­la­ją­ce wy­kryć w przy­szło­ści stop­nio­we, bez­zwrot­ne alo­ko­wa­nie za­so­bów. Z te­go przy­kła­du pły­nie wnio­sek, że brak me­cha­niz­mu nad­zo­ro­wa­nia sta­nu apli­kac­ji mo­że spo­wo­do­wać eska­lo­wa­nie spo­wol­nie­nia dzia­ła­nia do ran­gi awarii, a od­po­wied­ni do­bór met­ryk mo­że przy­spie­szyć wy­kry­cie prob­le­mu.

Brak właś­ci­we­go nad­zo­ru apli­kac­ji był źród­łem rów­nież ko­lej­ne­go opi­sy­wa­ne­go prob­le­mu. Aktuali­zac­ja apli­kac­ji w jed­nym z dwóch cen­trów ser­we­ro­wych za­koń­czy­ła się „ci­chym nie­po­wo­dze­niem”, któ­re uszło uwa­dze, gdyż peł­nię obo­wiąz­ków prze­ję­ło dru­gie cen­trum. Pech chciał, że zo­sta­ło ono krót­ko póź­niej wy­łą­czo­ne z po­wo­dów tech­nicz­nych i nag­le oka­za­ło się, że apli­kac­ja prze­sta­ła dzia­łać cał­ko­wi­cie. Gdyby me­cha­nizm nad­zo­ru sta­nu apli­kac­ji po­ka­zy­wał licz­bę pra­wid­ło­wo dzia­ła­ją­cych in­stan­cji, brak jed­nej z nich zo­stał­by wy­kry­ty za­nim do­szło do peł­nej utra­ty funkcjo­nal­noś­ci.

System nad­zo­ro­wa­nia mo­że sam stać się przy­czy­ną nie­do­ma­gań. W jed­nym z przy­kła­dów zwięk­szo­ny ruch spo­wo­do­wał prze­cią­że­nie klast­ra apli­kac­ji Splunk, reali­zu­ją­cej zbie­ra­nie i ana­li­zę da­nych oraz pre­zen­to­wa­nie ra­por­tów sta­nu apli­kac­ji. W efek­cie sys­tem za­czął po­mi­jać część zgło­szeń, co spo­wo­do­wa­ło brak in­for­mac­ji o sta­nie apli­kac­ji i unie­moż­li­wi­ło wy­kry­cie awarii, któ­re za­częły po­ja­wiać się w tym sa­mym cza­sie w nad­zo­ro­wa­nych apli­kac­jach. Grupy na­praw­cze mu­sia­ły sa­mo­dziel­nie wy­kry­wać bra­ki funkcjo­nal­noś­ci, zgła­szać incy­den­ty i ob­ser­wo­wać met­ry­ki mo­gą­ce do­pro­wa­dzić do przy­czy­ny prob­le­mu. Wynika z te­go, że sam sys­tem nad­zo­ro­wa­nia mo­że wy­ma­gać sta­łej we­ry­fi­ka­cji swo­je­go sta­nu.

Kontynuacją tej te­ma­ty­ki by­ła dru­ga pre­zen­tac­ja, po­pro­wa­dzo­na przez Arkadiusza Szewczyka i za­ty­tu­ło­wa­na „Jak zbu­do­wać i utrzy­mać ra­kie­tę do lo­gów”. Przedsta­wił on zgrub­nie archi­tek­tu­rę sys­te­mu nad­zo­ro­wa­nia sta­nu apli­kac­ji na przy­kła­dzie sys­te­mu Splunk. Opisy za­cho­dzą­cych w apli­kac­jach zda­rzeń za­wie­ra­ją in­for­mac­ję o źród­le zda­rze­nia, sta­nie mo­du­łu oraz su­ge­ro­wa­nej ak­cji. Na przy­kład, ser­wer HTTP mo­że w przy­pad­ku wy­kry­cia dłu­go­trwa­łe­go zwięk­szo­ne­go ob­cią­że­nia CPU wy­ge­ne­ro­wać zda­rze­nie za­wie­ra­ją­ce in­for­mac­ję o swo­im ad­re­sie i śred­nim ob­cią­że­niu CPU za ostat­nich kil­ka mi­nut oraz po­le­ce­nie zgło­sze­nia in­cy­den­tu, w ra­mach któ­re­go po­win­na zo­stać usta­lo­na przy­czy­na tej sytu­acji. Poszczegól­ne zda­rze­nia mo­gą też mo­dy­fi­ko­wać ist­nie­ją­ce zgło­sze­nia in­cy­den­tów lub je od­wo­ły­wać, a każ­dy in­cy­dent mo­że być po­wią­za­ny z wie­lo­ma zda­rze­nia­mi źród­ło­wy­mi. System nad­zo­ro­wa­nia rów­nież mo­że być źród­łem zda­rzeń.

Jedna z istot­nych trud­noś­ci le­ży we właś­ci­wym skon­fi­gu­ro­wa­niu wa­run­ków pod­ję­cia ak­cji. Możemy mieć bo­wiem do czy­nie­nia z błę­da­mi ty­pu false posi­tive, w któ­rych stan sys­te­mu jest błęd­nie in­ter­pre­to­wa­ny ja­ko awaria i zgła­sza­ny jest in­cy­dent, jak i false nega­tive, w któ­rych mi­mo wy­stę­po­wa­nia awarii wska­za­nia su­ge­ru­ją po­praw­ne dzia­ła­nie. Należy też uwzględ­nić czas, w któ­rym są wy­ko­ny­wa­ne pla­no­we pra­ce nad sys­te­mem i blo­ko­wać auto­ma­tycz­ne ak­cje tak, by za­po­biec nie­po­trzeb­ne­mu zgła­sza­niu in­cy­den­tów.

Skuteczne diag­no­zo­wa­nie awarii wy­ma­ga do­stęp­noś­ci du­żej iloś­ci in­for­mac­ji. Jak jed­nak zo­sta­ło wspom­nia­ne, sys­tem Splunk mo­że nie ra­dzić so­bie w przy­pad­ku du­że­go ob­cią­że­nia. Można wpro­wa­dzić środ­ki za­rad­cze w po­sta­ci po­dzie­le­nia za­dań zbie­ra­nia zda­rzeń oraz ana­li­zo­wa­nia ich mię­dzy dwa od­dziel­nie kla­stry. Najskutecz­niej­szym roz­wią­za­niem jest jed­nak edu­ko­wa­nie użyt­kow­ni­ków tak, by nie two­rzy­li bez po­trze­by skom­pli­ko­wa­nych, częs­to rea­li­zo­wa­nych za­py­tań wy­ma­ga­ją­cych ana­li­zy ol­brzy­mich zbio­rów da­nych. Warto też do­ko­nać prze­glą­du ze­sta­wu nad­zo­ro­wa­nych met­ryk tak, aby nie re­jes­tro­wać da­nych któ­re ma­ją ma­łe zna­cze­nie dla ana­li­zy sta­nu apli­kac­ji. Chodzi tu jed­nak nie ty­le o ogra­ni­cze­nie iloś­ci in­for­mac­ji – Splunk ra­dzi so­bie na­praw­dę z ogrom­ną ba­zą zda­rzeń – lecz o zmniej­sze­nie po­ku­sy wy­ko­ny­wa­nia ana­liz wszyst­kie­go, co tyl­ko się da.

Ostatnia pre­zen­tac­ja, za­ty­tu­ło­wa­na „Jak wy­ko­rzys­tać Elastic­search i Kafkę na po­trze­by mo­ni­to­rin­gu” i przed­sta­wio­na przez Pawła Dąbka, do­ty­czy­ła alter­na­ty­wy dla sys­te­mu Splunk w po­sta­ci duetu open-source Elastic­search oraz Apache Kafka. Elastic­search to ba­za da­nych NoSQL wspie­ra­ją­ca roz­pro­szo­ne prze­cho­wy­wa­nie i prze­twa­rza­nie da­nych. Choć cha­rak­te­ry­zu­je się ol­brzy­mim ape­ty­tem na za­so­by sprzę­to­we (głów­nie pa­mięć opera­cyj­ną), po­tra­fi nie­zmier­nie szyb­ko rea­li­zo­wać wy­szu­ki­wa­nie i ana­li­zę da­nych tek­sto­wych. Zapewnia też wy­so­ką do­stęp­ność da­nych oraz od­por­ność na awarie. Z kolei Kafka reali­zu­je wy­daj­ny me­cha­nizm dys­try­buc­ji stru­mie­ni da­nych tak, aby roz­dzie­lać, agre­go­wać i prze­twa­rzać stru­mie­nie w spo­sób przez­ro­czy­sty dla opro­gra­mo­wa­nia.

W prak­tycz­nych za­sto­so­wa­niach stru­mie­nie da­nych po­cho­dzą­cych z wie­lu źró­deł prze­ka­zu­je się do ser­we­ra Kafka, któ­ry do­ko­nu­je wstęp­ne­go prze­two­rze­nia oraz zbu­fo­ro­wa­nia ich tak, aby prze­ka­zać do ba­zy da­nych tyl­ko po­trzeb­ne in­for­mac­je w tem­pie nie pro­wa­dzą­cym do jej prze­cią­że­nia. Dane mo­gą być po­bie­ra­ne al­bo za po­mo­cą włas­nych mo­du­łów Elastic­search (ang. beat), al­bo udos­tęp­nia­ne przez nad­zo­ro­wa­ne apli­kac­je za po­mo­cą do­dat­ko­wych bi­blio­tek, ta­kich jak APM Agent. Zawartość ba­zy moż­na na­stęp­nie ana­li­zo­wać al­bo ręcz­nie, al­bo z wy­ko­rzys­ta­niem go­to­wych me­cha­niz­mów two­rzą­cych pa­ne­le kon­trol­ne (ang. dash­board), ta­kich jak Kibana lub Grafana. Istnieje też moż­li­wość od­czy­ty­wa­nia da­nych za po­mo­cą inter­fej­su REST.

Zaletą opi­sy­wa­ne­go roz­wią­za­nia jest wy­daj­ność i kom­plet­ność. Bez spe­cjal­nej kon­fi­gu­rac­ji moż­na ob­słu­żyć zbio­ry da­nych o roz­mia­rze się­ga­ją­cym 100 TB. Dostępne są też go­to­we mo­du­ły za­pi­su­ją­ce w ba­zie za­war­tość dzien­ni­ków zda­rzeń apli­kac­ji oraz wska­za­nia naj­waż­niej­szych met­ryk sys­te­mu opera­cyj­ne­go oraz kon­te­ne­ra apli­kac­ji. Cenne jest też to, że w prze­ci­wień­stwie do pros­tych roz­wią­zań ty­pu mrtg, Elastic­search zaw­sze do­ko­nu­je ana­li­zy su­ro­wych da­nych bez ich uśred­nia­nia. Dzięki te­mu za­cho­wa­ne są wszyst­kie skraj­ne war­toś­ci, a dłu­go­ter­mi­no­we wy­kre­sy jaw­nie pre­zen­tu­ją wszyst­kie wska­za­nia od­bie­ga­ją­ce od nor­my.

System nad­zo­ro­wa­nia moż­na też za­sto­so­wać do uspraw­nia­nia pra­cy ze­spo­łu. Elastic­search mo­że prze­cho­wy­wać in­for­mac­je o zmia­nach wpro­wa­dza­nych do re­po­zy­to­riów, błę­dach wdra­ża­nia apli­kac­ji czy po­myśl­nie roz­wią­zy­wa­nych zgło­sze­niach błę­dów. Dane te moż­na ana­li­zo­wać by wy­kry­wać prob­le­my zwią­za­ne z bra­kiem wy­szko­le­nia pra­cow­ni­ków lub nie­wy­star­cza­ją­cy­mi za­so­ba­mi ludz­ki­mi lub sprzę­to­wy­mi.

Wystąpie­nie za­koń­czy­ło się ape­lem, by sys­tem nad­zo­ro­wa­nia stał się przy­czyn­kiem do za­stą­pie­nia dzia­łań reak­tyw­nych pro­aktyw­ny­mi. Dzięki zgro­ma­dzo­nym da­nym moż­na nie tyl­ko wy­kry­wać za­cho­dzą­ce awarie, ale też prze­wi­dy­wać ich zbli­ża­nie się. Na przy­kład, ros­ną­ce wska­za­nia met­ryk ob­cią­że­nia RAM i CPU oraz cza­su reali­zac­ji żą­dań przez apli­ka­cję su­ge­ru­ją, że ko­niecz­ne jest al­bo do­ko­na­nie opty­ma­li­zac­ji, al­bo mi­grac­ja do bar­dziej wy­daj­ne­go śro­do­wis­ka sprzę­to­we­go.

Spotkanie za­koń­czy­ło się krót­ką dys­kus­ją, któ­rej te­ma­tem prze­wod­nim by­ło zwięk­sza­nie wy­daj­noś­ci sys­te­mu nad­zo­ro­wa­nia sta­nu apli­kac­ji. Organiza­to­rzy wspom­nie­li, że dzia­ła­ją­cy w ING sys­tem nad­zo­ru świet­nie ra­dzi już so­bie z ana­li­zą za­so­bów po­trzeb­nych do dzia­ła­nia apli­kac­ji, wy­ma­ga jed­nak do­pra­co­wa­nia w za­kre­sie auto­ma­tycz­ne­go wy­kry­wa­nia ano­malii oraz ko­re­la­cji po­mię­dzy dzia­ła­ją­cy­mi apli­kac­ja­mi. Obecnie osiąg­nię­ty po­ziom do­stęp­noś­ci wszyst­kich apli­kac­ji na po­zio­mie 99.8% (oko­ło 17 go­dzin nie­do­stęp­no­ści rocz­nie) po­wi­nien zo­stać zde­cy­do­wa­nie pod­nie­sio­ny.

Spotkanie by­ło świet­nie przy­go­to­wa­ne or­ga­ni­za­cyj­nie. Prezentac­je by­ły do­brze skoordy­no­wa­ne w cza­sie, a po za­koń­czo­nej dy­sku­sji na go­ści cze­ka­ła go­rą­ca piz­za sta­no­wią­ca świet­ną pod­sta­wę dla dal­szych roz­mów i na­wią­zy­wa­nia kon­tak­tów.