Mae'n 2019, ac nid oes gennym ateb safonol o hyd ar gyfer agregu logiau yn Kubernetes. Yn yr erthygl hon, hoffem, gan ddefnyddio enghreifftiau o arfer go iawn, rannu ein chwiliadau, problemau a gafwyd a'u hatebion.
Fodd bynnag, yn gyntaf, byddaf yn archebu bod gwahanol gwsmeriaid yn deall pethau gwahanol iawn trwy gasglu logiau:
- mae rhywun eisiau gweld cofnodion diogelwch ac archwilio;
- rhywun - logio'r seilwaith cyfan yn ganolog;
- ac i rai, mae'n ddigon i gasglu logiau cais yn unig, heb gynnwys, er enghraifft, balanswyr.
Isod mae'r toriad isod ynghylch sut y gwnaethom weithredu amrywiol “restrau dymuniadau” a pha anawsterau y daethom ar eu traws.
Theori: am offer logio
Cefndir ar gydrannau system logio
Mae mewngofnodi wedi dod yn bell, ac o ganlyniad i ba fethodolegau ar gyfer casglu a dadansoddi boncyffion sydd wedi'u datblygu, sef yr hyn a ddefnyddiwn heddiw. Yn ôl yn y 1950au, cyflwynodd Fortran analog o ffrydiau mewnbwn/allbwn safonol, a helpodd y rhaglennydd i ddadfygio ei raglen. Dyma'r logiau cyfrifiadurol cyntaf a wnaeth bywyd yn haws i raglenwyr yr amseroedd hynny. Heddiw gwelwn ynddynt gydran gyntaf y system logio - ffynhonnell neu “gynhyrchydd” logiau.
Nid oedd cyfrifiadureg yn aros yn ei unfan: ymddangosodd rhwydweithiau cyfrifiadurol, y clystyrau cyntaf... Dechreuodd systemau cymhleth yn cynnwys nifer o gyfrifiaduron weithio. Nawr gorfodwyd gweinyddwyr system i gasglu logiau o sawl peiriant, ac mewn achosion arbennig gallent ychwanegu negeseuon cnewyllyn OS rhag ofn y byddai angen iddynt ymchwilio i fethiant system. I ddisgrifio systemau casglu boncyffion canolog, fe'i cyhoeddwyd yn y 2000au cynnar , a oedd yn safoni remote_syslog. Dyma sut yr ymddangosodd cydran bwysig arall: casglwr boncyffion a'u storio.
Gyda'r cynnydd yn nifer y logiau a chyflwyniad eang technolegau gwe, cododd y cwestiwn pa logiau y mae angen eu dangos yn gyfleus i ddefnyddwyr. Mae offer consol syml (awk/sed/grep) wedi'u disodli gan rai mwy datblygedig gwylwyr log - trydydd cydran.
Oherwydd y cynnydd yn nifer y boncyffion, daeth rhywbeth arall yn amlwg: mae angen logiau, ond nid pob un ohonynt. Ac mae angen gwahanol lefelau o gadwedigaeth ar wahanol foncyffion: gellir colli rhai mewn diwrnod, tra bod angen storio eraill am 5 mlynedd. Felly, ychwanegwyd cydran ar gyfer hidlo a llwybro llif data at y system logio - gadewch i ni ei galw hidlydd.
Mae storio hefyd wedi gwneud naid fawr: o ffeiliau rheolaidd i gronfeydd data perthynol, ac yna i storio sy'n canolbwyntio ar ddogfennau (er enghraifft, Elasticsearch). Felly gwahanwyd y storfa oddi wrth y casglwr.
Yn y pen draw, mae'r union gysyniad o log wedi ehangu i fath o ffrwd haniaethol o ddigwyddiadau yr ydym am eu cadw ar gyfer hanes. Neu yn hytrach, rhag ofn y bydd angen i chi gynnal ymchwiliad neu lunio adroddiad dadansoddol...
O ganlyniad, mewn cyfnod cymharol fyr, mae casglu boncyffion wedi datblygu i fod yn is-system bwysig, y gellir yn haeddiannol ei galw yn un o isadrannau Data Mawr.
Pe bai un tro y gallai printiau cyffredin fod yn ddigon ar gyfer “system logio,” nawr mae'r sefyllfa wedi newid llawer.
Kubernetes a boncyffion
Pan ddaeth Kubernetes i'r seilwaith, nid oedd y broblem a oedd eisoes yn bodoli o gasglu boncyffion yn ei osgoi ychwaith. Mewn rhai ffyrdd, daeth hyd yn oed yn fwy poenus: roedd rheoli'r llwyfan seilwaith nid yn unig wedi'i symleiddio, ond hefyd yn gymhleth ar yr un pryd. Mae llawer o hen wasanaethau wedi dechrau mudo i ficrowasanaethau. Yng nghyd-destun logiau, adlewyrchir hyn yn y nifer cynyddol o ffynonellau log, eu cylch bywyd arbennig, a'r angen i olrhain perthnasoedd holl gydrannau'r system trwy logiau ...
Wrth edrych ymlaen, gallaf nodi nawr, yn anffodus, nad oes opsiwn logio safonol ar gyfer Kubernetes a fyddai'n cymharu'n ffafriol â phob un arall. Mae’r cynlluniau mwyaf poblogaidd yn y gymuned fel a ganlyn:
- mae rhywun yn datod y pentwr EFK (Elasticsearch, Fluentd, Kibana);
- mae rhywun yn ceisio'r a ryddhawyd yn ddiweddar neu ddefnyddiau ;
- ni (ac efallai nid yn unig ni?..) Rwy'n fodlon i raddau helaeth â fy natblygiad fy hun - ...
Fel rheol, rydym yn defnyddio'r bwndeli canlynol mewn clystyrau K8s (ar gyfer datrysiadau hunangynhaliol):
- ;
- .
Fodd bynnag, ni fyddaf yn aros ar gyfarwyddiadau ar gyfer eu gosod a'u cyfluniad. Yn lle hynny, byddaf yn canolbwyntio ar eu diffygion a chasgliadau mwy byd-eang am y sefyllfa gyda logiau yn gyffredinol.
Ymarfer gyda boncyffion yn K8s
“Cofnod bob dydd”, faint ohonoch chi sydd yna?..
Mae angen adnoddau sylweddol ar gyfer casglu boncyffion yn ganolog o seilwaith gweddol fawr, a fydd yn cael eu gwario ar gasglu, storio a phrosesu boncyffion. Yn ystod gweithrediad amrywiol brosiectau, roeddem yn wynebu gofynion amrywiol a phroblemau gweithredol yn deillio ohonynt.
Gadewch i ni roi cynnig ar ClickHouse
Gadewch i ni edrych ar storfa ganolog ar brosiect gyda chymhwysiad sy'n cynhyrchu logiau yn eithaf gweithredol: mwy na 5000 o linellau yr eiliad. Gadewch i ni ddechrau gweithio gyda'i logiau, gan eu hychwanegu at ClickHouse.
Cyn gynted ag y bydd angen uchafswm amser real, bydd y gweinydd 4-craidd gyda ClickHouse eisoes yn cael ei orlwytho ar yr is-system ddisg:
Mae'r math hwn o lwytho oherwydd y ffaith ein bod yn ceisio ysgrifennu yn ClickHouse cyn gynted â phosibl. Ac mae'r gronfa ddata yn ymateb i hyn gyda llwyth disg cynyddol, a all achosi'r gwallau canlynol:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
Ffaith yw bod yn ClickHouse (maent yn cynnwys data log) yn cael eu hanawsterau eu hunain yn ystod gweithrediadau ysgrifennu. Mae'r data a fewnosodir ynddynt yn cynhyrchu rhaniad dros dro, sydd wedyn yn cael ei uno â'r prif dabl. O ganlyniad, mae'r recordiad yn troi allan i fod yn feichus iawn ar y ddisg, ac mae hefyd yn ddarostyngedig i'r cyfyngiad y cawsom hysbysiad amdano uchod: ni ellir uno mwy na 1 o is-raniadau mewn 300 eiliad (mewn gwirionedd, mae hyn yn 300 o fewnosodiadau yr eiliad).
Er mwyn osgoi'r ymddygiad hwn, mewn darnau mor fawr â phosibl a dim mwy nag 1 amser bob 2 eiliad. Fodd bynnag, mae ysgrifennu mewn pyliau mawr yn awgrymu y dylem ysgrifennu'n llai aml yn ClickHouse. Gall hyn, yn ei dro, arwain at orlif byffer a cholli boncyffion. Yr ateb yw cynyddu'r byffer Fluentd, ond yna bydd y defnydd o gof hefyd yn cynyddu.
Nodyn: Roedd agwedd broblemus arall ar ein datrysiad gyda ClickHouse yn ymwneud â'r ffaith bod rhaniad yn ein hachos ni (tŷ pren) yn cael ei weithredu trwy dablau allanol cysylltiedig . Mae hyn yn arwain at y ffaith, wrth samplu cyfnodau amser mawr, bod angen gormod o RAM, gan fod y metatable yn ailadrodd trwy bob rhaniad - hyd yn oed y rhai sy'n amlwg nad ydynt yn cynnwys y data angenrheidiol. Fodd bynnag, nawr gellir datgan yn ddiogel fod y dull hwn wedi darfod ar gyfer fersiynau cyfredol o ClickHouse (c ).
O ganlyniad, daw'n amlwg nad oes gan bob prosiect ddigon o adnoddau i gasglu logiau mewn amser real yn ClickHouse (yn fwy manwl gywir, ni fydd eu dosbarthiad yn briodol). Yn ogystal, bydd angen i chi ddefnyddio cronni, y byddwn yn dychwelyd ato yn ddiweddarach. Mae'r achos a ddisgrifir uchod yn un go iawn. Ac ar y pryd, nid oeddem yn gallu cynnig ateb dibynadwy a sefydlog a fyddai'n addas i'r cwsmer ac yn caniatáu inni gasglu logiau heb fawr o oedi...
Beth am Elasticsearch?
Mae'n hysbys bod Elasticsearch yn delio â llwythi gwaith trwm. Gadewch i ni roi cynnig arni yn yr un prosiect. Nawr mae'r llwyth yn edrych fel hyn:
Llwyddodd Elasticsearch i dreulio'r llif data, fodd bynnag, mae ysgrifennu cyfrolau o'r fath iddo yn gwneud defnydd mawr o'r CPU. Penderfynir ar hyn trwy drefnu clwstwr. Yn dechnegol, nid yw hyn yn broblem, ond mae'n ymddangos mai dim ond i weithredu'r system casglu boncyffion rydym eisoes yn defnyddio tua 8 craidd ac mae gennym gydran ychwanegol wedi'i llwytho'n fawr yn y system...
Gwaelod llinell: gellir cyfiawnhau'r opsiwn hwn, ond dim ond os yw'r prosiect yn fawr a bod ei reolaeth yn barod i wario adnoddau sylweddol ar system logio ganolog.
Yna mae cwestiwn naturiol yn codi:
Pa logiau sydd eu hangen mewn gwirionedd?
Gadewch i ni geisio newid y dull ei hun: ar yr un pryd dylai logiau fod yn addysgiadol ac nid yn gorchuddio bob digwyddiad yn y system.
Gadewch i ni ddweud bod gennym siop ar-lein lwyddiannus. Pa logiau sy'n bwysig? Mae casglu cymaint o wybodaeth â phosibl, er enghraifft, o borth talu, yn syniad gwych. Ond nid yw'r holl logiau o'r gwasanaeth sleisio delwedd yn y catalog cynnyrch yn hanfodol i ni: dim ond gwallau a monitro uwch sy'n ddigon (er enghraifft, canran y 500 o wallau y mae'r gydran hon yn eu cynhyrchu).
Felly rydym wedi dod i’r casgliad hynny ni ellir cyfiawnhau logio canolog bob amser. Yn aml iawn mae'r cleient eisiau casglu'r holl logiau mewn un lle, er mewn gwirionedd, o'r log cyfan, dim ond 5% amodol o negeseuon sy'n hanfodol i'r busnes sydd eu hangen:
- Weithiau mae'n ddigon i ffurfweddu, dyweder, dim ond maint y log cynhwysydd a'r casglwr gwallau (er enghraifft, Sentry).
- Yn aml gall hysbysiad gwall a chofnod lleol mawr ei hun fod yn ddigon i ymchwilio i ddigwyddiadau.
- Cawsom brosiectau a oedd yn ymwneud â phrofion swyddogaethol yn unig a systemau casglu gwallau. Nid oedd angen logiau ar y datblygwr fel y cyfryw - gwelsant bopeth o olion gwall.
Darlun o fywyd
Gall stori arall fod yn enghraifft dda. Cawsom gais gan dîm diogelwch un o'n cleientiaid a oedd eisoes yn defnyddio datrysiad masnachol a ddatblygwyd ymhell cyn cyflwyno Kubernetes.
Roedd angen “gwneud ffrindiau” o'r system casglu log ganolog gyda'r synhwyrydd canfod problemau corfforaethol - QRadar. Gall y system hon dderbyn logiau trwy'r protocol syslog a'u hadalw o FTP. Fodd bynnag, nid oedd yn bosibl ei integreiddio ar unwaith gyda'r ategyn remote_syslog ar gyfer fluentd (fel y digwyddodd, ). Daeth problemau gyda sefydlu QRadar allan i fod ar ochr tîm diogelwch y cleient.
O ganlyniad, uwchlwythwyd rhan o'r logiau busnes-gritigol i FTP QRadar, ac ailgyfeiriwyd y rhan arall trwy syslog anghysbell yn uniongyrchol o'r nodau. Ar gyfer hyn rydym hyd yn oed yn ysgrifennu - efallai y bydd yn helpu rhywun i ddatrys problem debyg ... Diolch i'r cynllun a ddeilliodd o hyn, derbyniodd a dadansoddodd y cleient ei hun logiau critigol (gan ddefnyddio ei hoff offer), a bu modd i ni leihau cost y system logio, gan arbed dim ond y mis diwethaf.
Mae enghraifft arall yn eithaf arwyddol o beth i beidio â'i wneud. Un o'n cleientiaid ar gyfer prosesu yr un digwyddiadau yn dod oddi wrth y defnyddiwr, gwneud aml-linell allbwn distrwythur gwybodaeth yn y log. Fel y gallech ddyfalu, roedd cofnodion o'r fath yn anghyfleus iawn i'w darllen a'u storio.
Meini prawf ar gyfer boncyffion
Mae enghreifftiau o'r fath yn arwain at y casgliad bod angen i chi wneud hynny yn ogystal â dewis system casglu boncyffion hefyd dylunio'r boncyffion eu hunain! Beth yw'r gofynion yma?
- Rhaid i logiau fod mewn fformat y gall peiriant ei ddarllen (er enghraifft, JSON).
- Dylai logiau fod yn gryno a chyda'r gallu i newid maint y logio er mwyn dadfygio problemau posibl. Ar yr un pryd, mewn amgylcheddau cynhyrchu dylech redeg systemau gyda lefel logio fel rhybudd neu gwall.
- Rhaid normaleiddio logiau, hynny yw, mewn gwrthrych log, rhaid i bob llinell gael yr un math o faes.
Gall boncyffion anstrwythuredig arwain at broblemau wrth lwytho boncyffion i'r storfa a rhoi terfyn llwyr ar eu prosesu. Fel enghraifft, dyma enghraifft gyda gwall 400, y mae llawer wedi dod ar ei draws yn bendant mewn logiau rhugl:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
Mae'r gwall yn golygu eich bod yn anfon maes y mae ei fath yn ansefydlog i'r mynegai gyda mapio parod. Yr enghraifft symlaf yw maes yn y log nginx gyda newidyn $upstream_status. Gall gynnwys naill ai rhif neu linyn. Er enghraifft:
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}
Mae'r logiau'n dangos bod gweinydd 10.100.0.10 wedi ymateb â gwall 404 ac anfonwyd y cais i storfa gynnwys arall. O ganlyniad, daeth y gwerth yn y logiau fel hyn:
"upstream_response_time": "0.001, 0.007"
Mae'r sefyllfa hon mor gyffredin fel ei bod hyd yn oed yn haeddu sefyllfa ar wahân .
Beth am ddibynadwyedd?
Mae yna adegau pan fydd pob log yn ddieithriad yn hanfodol. A chyda hyn, mae gan y cynlluniau casglu boncyffion nodweddiadol ar gyfer K8s a gynigir/a drafodir uchod broblemau.
Er enghraifft, ni all pobl rhugl gasglu boncyffion o gynwysyddion byrhoedlog. Yn un o'n prosiectau, bu'r cynhwysydd mudo cronfa ddata fyw am lai na 4 eiliad ac yna cafodd ei ddileu - yn ôl yr anodiad cyfatebol:
"helm.sh/hook-delete-policy": hook-succeeded
Oherwydd hyn, ni chynhwyswyd y log gweithredu mudo yn y storfa. Gall gwleidyddiaeth helpu yn yr achos hwn. before-hook-creation.
Enghraifft arall yw cylchdroi log Docker. Gadewch i ni ddweud bod yna gymhwysiad sy'n mynd ati i ysgrifennu at logiau. O dan amodau arferol, rydym yn llwyddo i brosesu'r holl logiau, ond cyn gynted ag y bydd problem yn ymddangos - er enghraifft, fel y disgrifir uchod gyda fformat anghywir - mae prosesu yn stopio, ac mae Docker yn cylchdroi'r ffeil. Y canlyniad yw y gallai logiau busnes-gritigol gael eu colli.
Dyna pam mae'n bwysig gwahanu ffrydiau log, gwreiddio anfon y rhai mwyaf gwerthfawr yn uniongyrchol i'r cais i sicrhau eu diogelwch. Yn ogystal, ni fyddai'n ddiangen creu rhai “cronadur” o foncyffion, a all oroesi diffyg storio byr wrth arbed negeseuon beirniadol.
Yn olaf, rhaid inni beidio ag anghofio hynny Mae'n bwysig monitro unrhyw is-system yn gywir. Fel arall, mae'n hawdd rhedeg i sefyllfa lle mae rhugl mewn cyflwr CrashLoopBackOff ac nid yw yn anfon dim, ac y mae hyn yn argoeli colli gwybodaeth bwysig.
Canfyddiadau
Yn yr erthygl hon, nid ydym yn edrych ar atebion SaaS fel Datadog. Mae llawer o'r problemau a ddisgrifir yma eisoes wedi'u datrys mewn rhyw ffordd neu'i gilydd gan gwmnïau masnachol sy'n arbenigo mewn casglu logiau, ond ni all pawb ddefnyddio SaaS am wahanol resymau (y prif rai yw cost a chydymffurfiad â 152-FZ).
Mae casglu boncyffion canolog ar y dechrau yn edrych fel tasg syml, ond nid yw o gwbl. Mae’n bwysig cofio bod:
- Dim ond cydrannau hanfodol sydd angen eu cofnodi'n fanwl, tra gellir ffurfweddu monitro a chasglu gwallau ar gyfer systemau eraill.
- Dylid cadw'r logiau cynhyrchu cyn lleied â phosibl er mwyn peidio ag ychwanegu llwyth diangen.
- Rhaid i logiau fod yn ddarllenadwy â pheiriant, wedi'u normaleiddio, a bod â fformat llym.
- Dylid anfon logiau gwirioneddol feirniadol mewn ffrwd ar wahân, y dylid eu gwahanu oddi wrth y prif rai.
- Mae'n werth ystyried cronnwr boncyff, a all eich arbed rhag hyrddiau o lwyth uchel a gwneud y llwyth ar y storfa yn fwy unffurf.
Byddai'r rheolau syml hyn, o'u cymhwyso ym mhobman, yn caniatáu i'r cylchedau a ddisgrifir uchod weithio - er eu bod yn colli cydrannau pwysig (y batri). Os na fyddwch yn cadw at egwyddorion o'r fath, bydd y dasg yn eich arwain chi a'r seilwaith yn hawdd at gydran arall o'r system sydd â llwyth uchel (ac ar yr un pryd yn aneffeithiol).
PS
Darllenwch hefyd ar ein blog:
- «";
- «";
- «'.
Ffynhonnell: hab.com