Hodiaŭ, krom la monolita kodo, dekoj da mikroservoj funkcias en nia projekto. Ĉiu el ili bezonas esti kontrolata. Estas probleme fari tion en tiaj volumoj de DevOps-inĝenieroj. Ni evoluigis monitoran sistemon, kiu funkcias kiel servo por programistoj. Ili povas sendepende skribi metrikojn al la monitora sistemo, uzi ilin, konstrui instrumentpanelojn bazitajn sur ili, alligi al ili atentigojn, kiuj estos ekigitaj kiam sojlaj valoroj estas atingitaj. Kun DevOps-inĝenieroj - nur infrastrukturo kaj dokumentaro.
Ĉi tiu afiŝo estas transskribo de mia parolado de nia sur RIT++. Multaj petis nin fari tekstajn versiojn de raportoj de tie. Se vi estis al konferenco aŭ spektis videon, vi ne trovos ion novan. Kaj al ĉiuj aliaj - bonvenon sub kato. Mi rakontos al vi kiel ni venis al tia sistemo, kiel ĝi funkcias kaj kiel ni planas ĝisdatigi ĝin.
Pasinteco: skemoj kaj planoj
Kiel ni venis al la ekzistanta monitora sistemo? Por respondi ĉi tiun demandon, vi devas iri al 2015. Jen kiel ĝi aspektis tiam:
Ni havis ĉirkaŭ 24 nodojn, kiuj respondecis pri monitorado. Estas tuta aro da malsamaj kronoj, skriptoj, demonoj, kiuj monitoras ion ie, sendas mesaĝojn, plenumas funkciojn. Ni pensis, ke ju pli for, des malpli tia sistemo estus realigebla. Ne havas sencon disvolvi ĝin: ĝi estas tro maloportuna.
Ni decidis elekti tiujn elementojn de monitorado, kiujn ni forlasos kaj disvolvos, kaj tiujn, kiujn ni forlasos. Ili estis 19. Restis nur grafitoj, agregantoj kaj Grafana kiel instrumentpanelo. Sed kiel aspektos la nova sistemo? Kiel tio:
Ni havas deponejon de metrikoj: ĉi tiuj estas grafitoj, kiuj estos bazitaj sur rapidaj SSD-diskoj, ĉi tiuj estas certaj agregantoj por metrikoj. Poste - Grafana por montri instrumentpanelojn kaj Moira kiel alarmon. Ni ankaŭ volis evoluigi sistemon por trovi anomaliojn.
Normo: Monitorado 2.0
Tiel aspektis la planoj en 2015. Sed ni devis prepari ne nur la infrastrukturon kaj la servon mem, sed ankaŭ la dokumentadon por ĝi. Ni evoluigis kompanian normon por ni mem, kiun ni nomis monitorado 2.0. Kio estis la postuloj por la sistemo?
- konstanta havebleco;
- metrika stoka intervalo = 10 sekundoj;
- strukturita stokado de metrikoj kaj paneloj;
- SLA > 99,99%
- kolekto de eventaj metrikoj per UDP (!).
Ni bezonis UDP ĉar ni havas multe da trafiko kaj eventoj, kiuj generas metrikojn. Se ili ĉiuj estas skribitaj en grafito samtempe, la deponejo kolapsos. Ni ankaŭ elektis unuanivelajn prefiksojn por ĉiuj metrikoj.
Ĉiu el la prefiksoj havas iun econ. Estas metrikoj por serviloj, retoj, ujoj, rimedoj, aplikoj ktp. Klara, strikta, tajpita filtrado estis efektivigita, kie ni akceptas la unuanivelajn metrikojn, kaj simple faligas la reston. Jen kiel ni planis ĉi tiun sistemon en 2015. Kio estas en la nuntempo?
Nuna: la skemo de interago de monitoraj komponantoj
Unue ni kontrolas aplikaĵojn: nian PHP-kodon, aplikaĵojn kaj mikroservojn - unuvorte ĉion, kion niaj programistoj skribas. Ĉiuj aplikaĵoj sendas metrikojn per UDP al la Brubeck-agregator (statsd, reverkita en C). Ĝi rezultis esti la plej rapida laŭ la rezultoj de sintezaj provoj. Kaj ĝi sendas la jam aldonitajn metrikojn al Grafito per TCP.
Ĝi havas tian tipon de metrikoj kiel tempigiloj. Ĉi tio estas tre oportuna afero. Ekzemple, por ĉiu uzantkonekto al la servo, vi sendas respondtempometrikon al Brubeck. Venis miliono da respondoj, kaj la agreganto donis nur 10 metrikojn. Vi havas la nombron da homoj, kiuj venis, la maksimuman, minimuman kaj mezan respondtempojn, la medianon kaj 4 procentojn. Tiam la datumoj estas transdonitaj al Grafito kaj ni vidas ilin ĉiujn en vivas.
Ni ankaŭ havas agregadon por aparataro, programaro, sistema metriko kaj nia malnova Munin-monitora sistemo (ĝi funkciis kun ni ĝis 2015). Ni kolektas ĉion ĉi per la C'ish-demono CollectD (tuta amaso da diversaj kromprogramoj estas kudritaj en ĝin, ĝi povas pridemandi ĉiujn rimedojn de la gastiga sistemo sur kiu ĝi estas instalita, nur specifi en la agordo kie skribi datumojn) kaj skribi datumojn per ĝi en Grafito. Ĝi ankaŭ subtenas python-aldonaĵojn kaj ŝelajn skriptojn, do vi povas skribi viajn proprajn kutimajn solvojn: CollectD kolektos ĉi tiujn datumojn de loka aŭ fora gastiganto (supozi, ke ekzistas Curl) kaj sendos ĝin al Graphite.
Plue, ĉiuj metrikoj, kiujn ni kolektis, estas senditaj al Carbon-c-relay. Ĉi tio estas la solvo de Carbon Relay de Graphite, modifita en C. Ĉi tio estas enkursigilo, kiu kolektas ĉiujn metrikojn, kiujn ni sendas de niaj agregantoj kaj direktas ilin tra la nodoj. Ankaŭ ĉe la vojigo, ĝi kontrolas la validecon de la metrikoj. Unue, ili devas kongrui kun la prefiksa skemo, kiun mi montris pli frue, kaj, due, ili devas esti validaj por grafito. Alie, ili falas.
Tiam Karbono-c-relajso sendas la metrikojn al la Graphite-areto. Ni uzas Carbon-cache reverkitan en Go kiel la ĉefa stokado por metrikoj. Go-karbono, pro sia multfadenado, estas multe pli alta en rendimento al Karbon-kaŝmemoro. Ĝi prenas datumojn en si mem kaj skribas ĝin al disko per la flustro-pakaĵo (norma, skribita en python). Por legi datumojn de niaj stokejoj, ni uzas la Graphite API. Ĝi funkcias multe pli rapide ol la norma Graphite WEB. Kio okazas al la datumoj poste?
Ili iras al Grafana. Ni uzas niajn grafitajn aretojn kiel la ĉefan datumfonton, krome ni havas Grafana kiel TTT-interfacon por montri metrikojn, konstrui instrumentpanelojn. Por ĉiu el iliaj servoj, programistoj kreas sian propran panelon. Poste ili konstruas grafikaĵojn bazitajn sur ili, kiuj montras la metrikojn, kiujn ili skribas el siaj aplikoj. Krom Grafana, ni ankaŭ havas SLAM. Ĉi tio estas pitona demono, kiu kalkulas SLA surbaze de datumoj de grafito. Kiel mi diris, ni havas plurajn dekduojn da mikroservoj, ĉiu el kiuj havas siajn proprajn postulojn. Kun la helpo de SLAM, ni iras al la dokumentado kaj komparas ĝin kun kio estas en Graphite kaj komparas kiel la postuloj respondas al la havebleco de niaj servoj.
Iri plu: atentigi. Ĝi estas organizita kun forta sistemo - Moira. Ŝi estas sendependa ĉar ŝi havas sian propran Grafiton sub la kapuĉo. Disvolvita de la uloj de SKB Kontur, verkita en python kaj Go, plene malfermita fonto. Moira ricevas la saman fluon kiu iras en grafitojn. Se ial via konservado mortas, tiam via atentigo funkcios.
Ni deplojis Moira en Kubernetes, ĝi uzas aron de Redis-serviloj kiel ĉefa datumbazo. La rezulto estas mistolerema sistemo. Ĝi komparas la fluon de metrikoj kun la listo de ellasiloj: se ne estas mencioj en ĝi, tiam ĝi faligas la metrikon. Do ŝi kapablas digesti gigabajtojn da metriko por minuto.
Ni ankaŭ aldonis al ĝi kompanian LDAP, kun la helpo de kiu ĉiu uzanto de la kompania sistemo povas krei sciigojn por si pri ekzistantaj (aŭ ĵus kreitaj) ellasiloj. Ĉar Moira enhavas Grafiton, ĝi subtenas ĉiujn ĝiajn trajtojn. Do vi unue prenu la linion kaj kopiu ĝin en Grafana. Vidu kiel la datumoj estas montrataj sur la leteroj. Kaj tiam vi prenas la saman linion kaj kopiu ĝin en Moira. Pendu ĝin kun limoj kaj ricevu alarmon ĉe la eligo. Por fari ĉion ĉi, vi ne bezonas specifan scion. Moira povas atentigi per SMS, retpoŝto, Jira, Slack... Ĝi ankaŭ subtenas kutimajn skriptojn. Kiam ŝi havas ellasilon, kaj ŝi estas abonita al kutima skripto aŭ binaro, ŝi lanĉas ĝin kaj sendas ĉi tiun JSON-binaron al stdin. Sekve, via programo devus analizi ĝin. Kion vi faros kun ĉi tiu JSON, dependas de vi. Se vi volas, sendu ĝin al Telegramo, se vi volas, malfermu taskojn en Jira, faru kion vi volas.
Ni ankaŭ uzas nian propran evoluon por atentigo - Imagotag. Ni adaptis la panelon, kiu estas kutime uzata por elektronikaj prezaj etikedoj en vendejoj, al niaj bezonoj. Ni alportis ellasilon de Moira al ĝi. Ĝi indikas en kia kondiĉo ili estas, kiam ili okazis. Kelkaj el la uloj de la evoluo forlasis sciigojn en Slack kaj en la poŝto favore al ĉi tiu panelo.
Nu, ĉar ni estas progresema kompanio, ni ankaŭ monitoris Kubernetes en ĉi tiu sistemo. Inkluzivita ĝin en la sistemon uzante Heapster, kiun ni instalis en la areto, ĝi kolektas datumojn kaj sendas ĝin al Graphite. Kiel rezulto, la skemo aspektas jene:
Monitoraj Komponentoj
Jen listo de ligiloj al la komponantoj, kiujn ni uzis por ĉi tiu tasko. Ĉiuj ili estas malferma fonto.
Grafito:
- iri-karbono:
- flustri:
- grafito-api:
Karbono-c-relajso:
Brubeck:
Kolektita:
Moira:
Grafana:
heapster:
Статистика
Kaj jen kelkaj nombroj pri kiel la sistemo funkcias por ni.
Agregator (brubeck)
Nombro da metrikoj: ~ 300 / sek
Grafita Metriko Sendanta Intervalo: 30 sek
Uzado de la rimedoj de la servilo: ~ 6% CPU (ni parolas pri plenrajtaj serviloj); ~ 1 Gb RAM; ~ 3 Mbps LAN
Grafito (karbono)
Nombro da metrikoj: ~ 1 / min
Metrika ĝisdatiga intervalo: 30 sek
Metrika stokadoskemo: 30 sek 35 d, 5 min 90 d, 10 min 365 d (donas komprenon pri kio okazas al la servo dum longa tempodaŭro)
Uzado de servilo-rimedo: ~10% CPU; ~ 20Gb RAM; ~ 30 Mbps LAN
Fleksebleco
Ni ĉe Avito vere aprezas la flekseblecon en nia monitora servo. Kial li efektive rezultis tiel? Unue, ĝiaj konsistigaj partoj estas interŝanĝeblaj: kaj la komponantoj mem kaj iliaj versioj. Due, konservebleco. Ĉar la tuta projekto estas konstruita sur malferma fonto, vi povas redakti la kodon mem, fari ŝanĝojn kaj efektivigi funkciojn kiuj ne estas disponeblaj el la skatolo. Sufiĉe oftaj stakoj estas uzataj, ĉefe Go kaj Python, do tio estas farita tute simple.
Jen ekzemplo de vera problemo. Metriko en Grafito estas dosiero. Ĝi havas nomon. Dosiernomo = metrika nomo. Kaj estas maniero atingi tien. Dosiernomoj en Linukso estas limigitaj al 255 signoj. Kaj ni havas (kiel "internaj klientoj") ulojn de la datumbaza fako. Ili diras al ni: "Ni volas kontroli niajn SQL-demandojn. Kaj ili ne estas 255 signoj, sed 8 MB ĉiu. Ni volas montri ilin en Grafana, vidi la parametrojn por ĉi tiu peto, kaj eĉ pli bone, ni volas vidi la supron de tiaj petoj. Estos bonege se ĝi montriĝas en reala tempo. Kaj estus vere mojose ŝovi ilin en la alarmon."
La SQL-demanda ekzemplo estas prenita kiel ekzemplo de
Ni levas la Redis-servilon kaj niajn Collectd-kromaĵojn, kiuj iras al Postgres kaj prenas ĉiujn datumojn de tie, sendas metrikojn al Graphite. Sed ni anstataŭigas la nomon de la metriko per hashoj. La sama hash estas samtempe sendita al Redis kiel ŝlosilo, kaj la tuta SQL-demando kiel valoro. Restas al ni fari Grafana kapabla iri al Redis kaj preni ĉi tiun informon. Ni malfermas la Graphite API ĉar ĉi tiu estas la ĉefa interfaco por la interago de ĉiuj monitoraj komponantoj kun grafito, kaj ni eniras novan funkcion nomitan aliasByHash () tie - ni ricevas la nomon de la metriko de Grafana, kaj uzas ĝin en peto al Redis kiel ŝlosilon, kiel respondo ni ricevas la valoron de la ŝlosilo, kiu estas nia "SQL-demando". Tiel, ni alportis al Grafana la montradon de SQL-demando, kiu, en teorio, ne povus esti montrita tie, kune kun statistikoj pri ĝi (vokoj, vicoj, totala_tempo, ...).
Rezultoj
Havebleco Nia monitora servo disponeblas 24/7 de iu ajn aplikaĵo kaj ajna kodo. Se vi havas aliron al la stokejoj, vi povas skribi datumojn al la servo. Lingvo ne gravas, decidoj ne gravas. Vi nur bezonas scii kiel malfermi ingon, ĵeti metrikon tien kaj fermi la ingon.
Fidindeco Ĉiuj komponantoj estas toleremaj al misfunkciadoj kaj bone manipulas niajn laborŝarĝojn.
Malalta enira sojlo. Por uzi ĉi tiun sistemon, vi ne bezonas lerni programlingvojn kaj demandojn en Grafana. Nur malfermu vian aplikaĵon, aldonu al ĝi ingon, kiu sendos metrikojn al Graphite, fermu ĝin, malfermu Grafana, kreu instrumentpanelojn tie kaj rigardu la konduton de viaj metrikoj, ricevante sciigojn per Moira.
Sendependeco. Vi povas fari ĉion ĉi mem, sen la helpo de DevOps-inĝenieroj. Kaj ĉi tio estas troo, ĉar vi povas kontroli vian projekton nun, vi ne devas peti iun ajn - nek komenci laboron, nek fari ŝanĝojn.
Al kio ni strebas?
Ĉio listigita malsupre estas ne nur abstraktaj pensoj, sed io al kio almenaŭ la unuaj paŝoj estis faritaj.
- detektilo de anomalioj. Ni volas krei servon, kiu iros al niaj Graphite-stokoj kaj kontrolos ĉiun metrikon per diversaj algoritmoj. Jam ekzistas algoritmoj, kiujn ni volas vidi, estas datumoj, ni scias kiel labori kun ĝi.
- metadatenoj. Ni havas multajn servojn, ili ŝanĝiĝas laŭlonge de la tempo, same kiel la homoj, kiuj laboras kun ili. Konservi rekordojn permane ne estas eblo. Tial, metadatenoj nun estas enigitaj en niaj mikroservoj. Ĝi deklaras kiu evoluigis ĝin, la lingvojn kun kiuj ĝi interagas, SLA-postuloj, kie kaj al kiu sendi sciigojn. Dum deplojado de servo, ĉiuj entaj datumoj estas kreitaj sendepende. Kiel rezulto, vi ricevas du ligilojn - unu por ellasiloj, la alia por paneloj en Grafana.
- Monitorado en ĉiu hejmo. Ni kredas, ke ĉiuj programistoj devus uzi tian sistemon. En ĉi tiu kazo, vi ĉiam komprenas kie estas via trafiko, kio okazas al ĝi, kie ĝi falas, kie ĝi havas malfortajn punktojn. Se, ekzemple, io venas kaj frakasas vian servon, tiam vi ekscios pri tio ne dum voko de la administranto, sed de atentigo, kaj vi povas tuj malfermi freŝajn protokolojn kaj vidi kio okazis tie.
- Alta rendimento. Nia projekto konstante kreskas, kaj hodiaŭ ĝi prilaboras ĉirkaŭ 2-metrajn valorojn por minuto. Antaŭ jaro, ĉi tiu cifero estis 000 000. Kaj la kresko daŭras, kaj tio signifas, ke post iom da tempo Grafito (flustrado) komencos ŝarĝi la disksubsistemon tre peze. Kiel mi diris, ĉi tiu monitora sistemo estas sufiĉe versátil pro la interŝanĝebleco de komponantoj. Iu specife por Graphite konservas kaj konstante pligrandigas ilian infrastrukturon, sed ni decidis iri alidirekten: uzi kiel deponejo por niaj metrikoj. Ĉi tiu transiro estas preskaŭ finita, kaj tre baldaŭ mi rakontos al vi pli detale kiel ĝi estis farita: kiaj estis la malfacilaĵoj kaj kiel ili estis venkitaj, kiel la migra procezo iris, mi priskribos la elektitajn komponantojn kiel devigajn kaj iliajn agordojn.
Dankon pro via atento! Demandu viajn demandojn pri la temo, mi provos respondi ĉi tie aŭ en la sekvaj afiŝoj. Eble iu havas sperton konstrui similan monitoran sistemon aŭ ŝanĝi al Clickhouse en simila situacio - dividu ĝin en la komentoj.
fonto: www.habr.com