{"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\u00e4lgimist Prometheuse, Clickhouse'i ja ELK-ga","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Minu nimi on Anton Baderin. T\u00f6\u00f6tan K\u00f5rgete Tehnoloogiate Keskuses ja tegelen s\u00fcsteemiadministreerimisega. Kuu aega tagasi l\u00f5ppes meie ettev\u00f5tte konverents, kus jagasime oma teadmisi linna IT-kogukonnaga. R\u00e4\u00e4kisin veebirakenduste j\u00e4lgimisest. Materjal oli suunatud junior v\u00f5i middle tasemele, kellel ei ole seda protsessi nullist \u00fcles ehitatud.<\/p>\n

<\/p>\n

\"Kuidas<\/p>\n

<\/p>\n

Iga j\u00e4lgimiss\u00fcsteemi nurgakivi on \u00e4ri\u00fclesannete lahendamine. J\u00e4lgimine iseenesest ei huvita kedagi. Aga mida soovib \u00e4ri? Et k\u00f5ik t\u00f6\u00f6taks kiiresti ja ilma vigadeta. \u00c4ri soovib proaktiivsust, et me ise tuvastaks probleemid teenuse toimimises ja lahendaks need maksimaalselt kiiresti. Just need olidki \u00fclesanded, millega eelmisel aastal \u00fche meie kliendi projektis tegelesin.<\/p>\n

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

Projektist<\/h2>\n

<\/p>\n

Projekt on \u00fcks suurimaid lojaalsusprogramme riigis. Aitame jaem\u00fc\u00fcgiketidel suurendada m\u00fc\u00fcgifrekventsi erinevate turundusinstrumentide, n\u00e4iteks boonuskardid, kaudu. Projekti kuulub kokku 14 rakendust, mis t\u00f6\u00f6tavad k\u00fcmnel serveril.<\/p>\n

<\/p>\n

Vestluste k\u00e4igus olen korduvalt m\u00e4rganud, et administraatorid ei l\u00e4henenud veebirakenduste j\u00e4lgimisele alati \u00f5igesti: paljud piirdusid endiselt operatsioonis\u00fcsteemi m\u00f5\u00f5dikute j\u00e4lgimisega ja harva j\u00e4lgisid teenuseid.<\/p>\n

<\/p>\n

Minu puhul p\u00f5hines kliendi j\u00e4lgimiss\u00fcsteem varem Icingal. See ei lahendanud \u00fclaltoodud \u00fclesandeid. Klient teatas sageli ise meile probleemidest ja meil j\u00e4i tihti andmetest puudu, et s\u00fcvitsi kaevata p\u00f5hjuse leidmiseks.<\/p>\n

<\/p>\n

Lisaks oli selge arusaam, et selle edasine arendamine ei ole perspektiivikas. Mulle tundub, et need, kes tunnevad Icinga, saavad mind h\u00e4sti aru. Nii otsustasime t\u00e4ielikult \u00fcmber kujundada veebirakenduste j\u00e4lgimiss\u00fcsteemi projektis.<\/p>\n

<\/p>\n

Prometheus<\/h2>\n

<\/p>\n

Valisime Prometheuse, l\u00e4htudes kolmest p\u00f5hin\u00e4itajast:<\/p>\n

<\/p>\n

    \n
  1. Suur hulk saadaval m\u00f5\u00f5dikuid. Meie puhul 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. Meie jaoks on see teine \u00e4\u00e4rmuses v\u00f5rreldes varasemalt kasutatud Icingaga. Seal oli m\u00f5\u00f5dikute lisamine eriti keeruline: olemasolevad olid kallid (piisab, kui vaadata mistahes plugina l\u00e4htekoodi). Iga plugin oli kas Bash v\u00f5i Python skript, mille k\u00e4itamine on ressursikulu m\u00f5ttes kallis.<\/li>\n
  2. See s\u00fcsteem tarbib suhteliselt v\u00e4he ressursse. K\u00f5ikide meie m\u00f5\u00f5dikute jaoks piisab 600 MB RAM-ist, 15% \u00fchest tuumast ja paarik\u00fcmnest IOPS-ist. Loomulikult tuleb k\u00e4itada m\u00f5\u00f5dikute eksportijaid, kuid k\u00f5ik need on kirjutatud Go keeles ja ei ole ka liiga n\u00e4ljased. Ei arva, et see oleks praegustes oludes probleem. <\/li>\n
  3. Pakub v\u00f5imalust \u00fcleminekuks Kubernetesesse. Arvestades kliendi plaane \u2014 valik on ilmne. <\/li>\n<\/ol>\n

    <\/p>\n

    ELK<\/h2>\n

    <\/p>\n

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

    <\/p>\n

    Clickhouse<\/h2>\n

    <\/p>\n

    Alguses langes valik InfluxDB-le. Tunnustasime vajadust koguda Nginx logisid, statistikat pg_stat_statements-st ja s\u00e4ilitada ajaloolisi andmeid Prometheuse kohta. Influx ei meeldinud meile, kuna see hakkas perioodiliselt tarbima suures koguses m\u00e4lu ja lakkas t\u00f6\u00f6tamast. Lisaks soovisime r\u00fchmitada p\u00e4ringud remote_addr j\u00e4rgi, kuid selle S\u00dcSISD-s sai r\u00fchmitada ainult siltide j\u00e4rgi. Sildid on kallid (m\u00e4lu), nende arv on tinglikult piiratud.<\/p>\n

    <\/p>\n

    Alustasime otsingut uuesti. Vajasime anal\u00fc\u00fctilise baasi minimaalsete ressursin\u00f5uetega, soovitavalt andmete tihendamisega kettal.<\/p>\n

    <\/p>\n

    Clickhouse vastab k\u00f5ikidele nendele kriteeriumidele ja me ei ole kordagi oma valikut kahetsenud. Me ei kirjuta sinna mingeid erakordseid andmemahtusid (kandmise arvu on kokku umbes viis tuhat minutis).<\/p>\n

    <\/p>\n

    NewRelic<\/h2>\n

    <\/p>\n

    NewRelic on ajalooliselt meiega olnud, kuna see oli kliendi valik. Me kasutame seda APM-i jaoks.<\/p>\n

    <\/p>\n

    Zabbix<\/h2>\n

    <\/p>\n

    Kasutame Zabbixit ainult erinevate API-de Black Box'i monitooringuks.<\/p>\n

    <\/p>\n

    Monitooringu l\u00e4henemise m\u00e4\u00e4ratlemine<\/h2>\n

    <\/p>\n

    Soovisime dekomponeerida \u00fclesande ja seel\u00e4bi s\u00fcsteematiseerida l\u00e4henemise monitooringule.<\/p>\n

    <\/p>\n

    Selle jaoks jagasin meie s\u00fcsteemi j\u00e4rgmisteks tasemeteks:<\/p>\n

    <\/p>\n