{"id":32322,"date":"2019-10-31T21:46:21","date_gmt":"2019-10-31T18:46:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-my-stroili-monitoring-na-prometheus-clickhouse-i-elk\/"},"modified":"2019-10-31T21:46:21","modified_gmt":"2019-10-31T18:46:21","slug":"kak-my-stroili-monitoring-na-prometheus-clickhouse-i-elk","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kak-my-stroili-monitoring-na-prometheus-clickhouse-i-elk","title":{"rendered":"Kuidas me ehitasime j\u00e4lgimise Prometheuse, Clickhouse'i ja ELK abil","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Minu nimi on Anton Baderin. T\u00f6\u00f6tan K\u00f5rgete Tehnoloogiate Keskuses ja tegeleb s\u00fcsteemiadministreerimisega. Kuu aega tagasi l\u00f5ppes meie ettev\u00f5tte konverents, kus jagasime saadud kogemusi meie linna IT-kommuuniga. R\u00e4\u00e4kisin veebirakenduste j\u00e4lgimisest. Materjal oli m\u00f5eldud junior- v\u00f5i middle-taseme spetsialistidele, kes ei ole seda protsessi nullist \u00fcles ehitanud.<\/p>\n

<\/p>\n

\"Kuidas<\/p>\n

<\/p>\n

Iga j\u00e4lgimiss\u00fcsteemi aluseks olev kivi on \u00e4ri\u00fclesannete lahendamine. J\u00e4lgimine iseenesest ei huvita kedagi. Aga mida soovib \u00e4ri? Et k\u00f5ik t\u00f6\u00f6taks kiiresti ja t\u00f5rgeteta. \u00c4ri soovib proaktiivsust, et me ise tuvastaksime teenuse t\u00f6\u00f6probleeme ja lahendaksime need v\u00f5imalikult kiiresti. Just need \u00fclesanded olid need, mida ma lahendasin kogu eelmisel aastal \u00fche meie kliendi projektis.<\/p>\n

<\/a><\/noindex><\/p>\n

Projektist<\/h2>\n

<\/p>\n

Projekt on \u00fcks suurimaid lojaalsusprogramme riigis. Me aitame jaekettidel suurendada m\u00fc\u00fcgitiheduse erinevate turundusinstrumentide, nagu boonuskardid, abil. Kokku h\u00f5lmab projekt 14 rakendust, mis t\u00f6\u00f6tavad k\u00fcmnel serveril.<\/p>\n

<\/p>\n

Kandideerimisprotsessi k\u00e4igus olen korduvalt m\u00e4rganud, et administraatorid ei pruugi alati \u00f5igesti l\u00e4heneda veebirakenduste j\u00e4lgimisele: endiselt toetuvad paljud ainult operatsioonis\u00fcsteemi m\u00f5\u00f5dikutele ja harva j\u00e4lgivad teenuseid.<\/p>\n

<\/p>\n

Minu kogemuse kohaselt p\u00f5hines kliendi j\u00e4lgimiss\u00fcsteem varem Icingal. See ei lahendanud \u00fclaltoodud probleeme. Tihti teatas klient ise meile probleemidest ja mitte harva puudusid meil lihtsalt andmed, et v\u00e4lja selgitada p\u00f5hjus.<\/p>\n

<\/p>\n

Lisaks oli selgelt m\u00f5istetav, et selle edasine arendamine on perspektiivitu. Arvan, et need, kes tunnevad Icingat, saavad mind aru. Nii otsustasime projekti veebirakenduste j\u00e4lgimiss\u00fcsteemi t\u00e4ielikult \u00fcmber t\u00f6\u00f6tada.<\/p>\n

<\/p>\n

Prometheus<\/h2>\n

<\/p>\n

Valisime Prometheuse, tuginedes kolmele peamisele n\u00e4itajale:<\/p>\n

<\/p>\n

    \n
  1. Suure hulga m\u00f5\u00f5dikute k\u00e4ttesaadavus. Meil on neid 60 000. Loomulikult tuleb m\u00e4rkida, et enamikku neist me ei kasuta (ilmselt umbes 95%). Teisest k\u00fcljest on need k\u00f5ik suhteliselt odavad. See on meie jaoks teistsugune \u00e4\u00e4rmuse v\u00f5rreldes varem kasutatud Icingaga. Seal oli m\u00f5\u00f5dikute lisamine eriline piin: olemasolevad olid v\u00e4ga kallid (piisab, kui vaadata mis tahes pistiku allikaid). Iga pistikprogramm kujutas endast Bash v\u00f5i Python skripti, mille k\u00e4itamine polnud ressursikasutuse m\u00f5ttes odav.<\/li>\n
  2. S\u00fcsteem tarbib suhteliselt v\u00e4he ressursse. K\u00f5igi meie m\u00f5\u00f5dikute jaoks piisab 600 MB RAM-ist, 15% \u00fchest tuumast ja paari k\u00fcmne IOPS-i. Loomulikult tuleb m\u00f5\u00f5dikute eksportijaid k\u00e4ivitada, kuid need on kirjutatud Go-s ja ei ole samuti ressursih\u00e4das. Ma ei usu, et see on t\u00e4nap\u00e4eva kontekstis probleem. <\/li>\n
  3. Annab v\u00f5imaluse \u00fcleminekuks Kubernetesesse. Arvestades kliendi plaane \u2014 valik on ilmne. <\/li>\n<\/ol>\n

    <\/p>\n

    ELK<\/h2>\n

    <\/p>\n

    Varem ei kogunud ega t\u00f6\u00f6tlenud logisid. Puudused on k\u00f5igile selged. Valisime ELK-i, kuna meil oli juba kogemus selle s\u00fcsteemiga. S\u00e4ilitame seal ainult rakenduste logisid. Peamised valikukriteeriumid olid t\u00e4isteksti otsing ja selle kiirus.<\/p>\n

    <\/p>\n

    Clickhouse<\/h2>\n

    <\/p>\n

    Alguses langes valik InfluxDB peale. M\u00f5istsime vajadust koguda Nginx logisid, statistikat pg_stat_statements-st ning hoida ajaloolisi andmeid Prometheus. Influx ei meeldinud meile, kuna ta hakkas perioodiliselt tarbima suurt hulka m\u00e4lu ja kukkus kokku. Lisaks soovisime r\u00fchmitada p\u00e4ringuid remote_addr-i j\u00e4rgi, kuid selle S\u00dcD r\u00fchmitamine on v\u00f5imalik vaid m\u00e4rgistuste j\u00e4rgi. M\u00e4rgised on kallid (m\u00e4lu), nende hulk on tinglikult piiratud.<\/p>\n

    <\/p>\n

    Alustasime otsinguid uuesti. Vajasime anal\u00fc\u00fctilist baasi, mille ressursikasutus oleks minimaalne, eelistatavalt andmete kompresseerimisega kettale.<\/p>\n

    <\/p>\n

    Clickhouse vastab k\u00f5ikidele nendele kriteeriumidele ja valiku \u00fcle ei ole meil kordagi kahetsust. Me ei kirjuta sinna mingeid silmapaistvaid andmemahtusid (s\u00fcstimiste arv on umbes viis tuhat minutis).<\/p>\n

    <\/p>\n

    NewRelic<\/h2>\n

    <\/p>\n

    NewRelic on ajalooliselt olnud meiega, kuna see oli kliendi valik. Meie juures kasutatakse seda APM-ina.<\/p>\n

    <\/p>\n

    Zabbix<\/h2>\n

    <\/p>\n

    Kasutame Zabbixit ainult erinevate API-de musta kasti j\u00e4lgimiseks.<\/p>\n

    <\/p>\n

    J\u00e4lgimise l\u00e4henemise m\u00e4\u00e4ratlemine<\/h2>\n

    <\/p>\n

    Me soovisime \u00fclesandeid lahti dekomponeerida, et seel\u00e4bi j\u00e4lgimismeetodit s\u00fcsteemsemaks muuta.<\/p>\n

    <\/p>\n

    Selleks jagasin meie s\u00fcsteemi j\u00e4rgmistesse tasemetesse:<\/p>\n

    <\/p>\n