{"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\/da\/blog\/administrirovanie\/kak-my-stroili-monitoring-na-prometheus-clickhouse-i-elk","title":{"rendered":"Hvordan vi byggede overv\u00e5gning p\u00e5 Prometheus, Clickhouse og ELK","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Mit navn er Anton Baderin. Jeg arbejder i Center for H\u00f8j Teknologi og besk\u00e6ftiger mig med systemadministration. For en m\u00e5ned siden afsluttede vores virksomhed vores konference, hvor vi delte vores erfaringer med IT-samfundet i vores by. Jeg talte om overv\u00e5gning af webapplikationer. Materialet var tilt\u00e6nkt junior og middle niveau, der ikke har opbygget denne proces fra bunden.<\/p>\n

<\/p>\n

\"Hvordan<\/p>\n

<\/p>\n

Grundstenen i enhver overv\u00e5gningssystem er l\u00f8sningen af forretningsproblemer. Overv\u00e5gning for overv\u00e5gningens skyld er ikke interessant for nogen. Hvad \u00f8nsker virksomheden? At alt fungerer hurtigt og uden fejl. Virksomheden \u00f8nsker proaktivitet, s\u00e5 vi selv opdager problemer i serviceydelsen og hurtigst muligt l\u00f8ser dem. Det er i grunden de opgaver, jeg har arbejdet med det sidste \u00e5r p\u00e5 et af vores kunders projekter.<\/p>\n

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

Om projektet<\/h2>\n

<\/p>\n

Projektet er et af de st\u00f8rste loyalitetsprogrammer i landet. Vi hj\u00e6lper detailhandlere med at \u00f8ge salgsfrekvensen ved hj\u00e6lp af diverse marketingv\u00e6rkt\u00f8jer som bonuskort. Samlet set er projektet sammensat af 14 applikationer, der k\u00f8rer p\u00e5 ti servere.<\/p>\n

<\/p>\n

Ved gennemf\u00f8relsen af interviews har jeg flere gange bem\u00e6rket, at administratorer ikke altid griber overv\u00e5gningen af webapplikationer korrekt an: mange stopper stadig ved operationelle systemmetrikker og overv\u00e5ger sj\u00e6ldent serviceydelser.<\/p>\n

<\/p>\n

I mit tilf\u00e6lde byggede kundens overv\u00e5gningssystem tidligere p\u00e5 Icinga. Det l\u00f8ste ikke de ovenn\u00e6vnte opgaver. Ofte informerede kunden os selv om problemer, og vi manglede ofte bare data til at finde \u00e5rsagen.<\/p>\n

<\/p>\n

Desuden var der en klar forst\u00e5else af det meningsl\u00f8se i dens fremtidige udvikling. Jeg tror, dem der kender Icinga, vil forst\u00e5 mig. S\u00e5 vi besluttede at redesigne overv\u00e5gningssystemet for webapplikationer i projektet helt.<\/p>\n

<\/p>\n

Prometheus<\/h2>\n

<\/p>\n

Vi valgte Prometheus baseret p\u00e5 tre hovedfaktorer:<\/p>\n

<\/p>\n

    \n
  1. Et stort antal tilg\u00e6ngelige metrikker. I vores tilf\u00e6lde er der 60.000. Selvf\u00f8lgelig skal det n\u00e6vnes, at st\u00f8rstedelen af dem ikke bruges (sandsynligvis omkring 95%). P\u00e5 den anden side er de alle relativt billige. For os er det en anden ekstrem i forhold til det tidligere anvendte Icinga. I den var det en s\u00e6rlig udfordring at tilf\u00f8je metrikker: de eksisterende var dyre at erhverve (man skal bare se p\u00e5 koden til enhver plugin). Ethvert plugin var et script skrevet i Bash eller Python, hvis k\u00f8rsel ikke er billig med hensyn til ressourcer.<\/li>\n
  2. Dette system forbruger relativt f\u00e5 ressourcer. Alle vores metrikker kr\u00e6ver 600 MB RAM, 15% af en kerne og et par dusin IOPS. Selvf\u00f8lgelig skal vi k\u00f8re metric eksport\u00f8rer, men de er alle skrevet i Go og er heller ikke sultne. Jeg tror ikke, det er et problem i moderne forhold. <\/li>\n
  3. Giver mulighed for overgang til Kubernetes. I betragtning af kundens planer er valget indlysende. <\/li>\n<\/ol>\n

    <\/p>\n

    ELK<\/h2>\n

    <\/p>\n

    Tidligere indsamlede og behandlede vi ikke logs. Ulemperne er klare for alle. Vi valgte ELK, da vi allerede havde erfaring med dette system. Vi opbevarer kun applikationslogs der. De vigtigste kriterier var fuldtekst-s\u00f8gning og hastighed.<\/p>\n

    <\/p>\n

    Clickhouse<\/h2>\n

    <\/p>\n

    Oprindeligt faldt valget p\u00e5 InfluxDB. Vi var klar over n\u00f8dvendigheden af at indsamle logs fra Nginx, statistik fra pg_stat_statements og opbevaring af historiske data fra Prometheus. Influx var ikke tilfredsstillende, da det periodisk begyndte at forbruge store m\u00e6ngder hukommelse og faldt. Desuden \u00f8nskede vi at gruppere foresp\u00f8rgsler efter remote_addr, men grupp\u00e9ringen i denne DB var kun baseret p\u00e5 tags. Tags er dyre (hukommelse), og deres antal er begr\u00e6nset.<\/p>\n

    <\/p>\n

    Vi begyndte vores s\u00f8gning forfra. Vi havde brug for et analysemilj\u00f8 med et minimalt ressourceforbrug, helst med data komprimering p\u00e5 disken.<\/p>\n

    <\/p>\n

    Clickhouse opfylder alle disse krav, og vi har aldrig fortrudt vores valg. Vi skriver ikke store m\u00e6ngder data til det (antallet af indsatser er kun omkring fem tusinde pr. minut).<\/p>\n

    <\/p>\n

    NewRelic<\/h2>\n

    <\/p>\n

    NewRelic har historisk v\u00e6ret med os, da det var kundens valg. Vi bruger det som APM.<\/p>\n

    <\/p>\n

    Zabbix<\/h2>\n

    <\/p>\n

    Vi bruger Zabbix udelukkende til at overv\u00e5ge Black Box af forskellige API'er.<\/p>\n

    <\/p>\n

    Bestemmelse af tilgang til overv\u00e5gning<\/h2>\n

    <\/p>\n

    Vi \u00f8nskede at dekomponere opgaven og dermed systematisere tilgangen til overv\u00e5gning.<\/p>\n

    <\/p>\n

    Jeg har opdelt vores system i f\u00f8lgende niveauer:<\/p>\n

    <\/p>\n