🥇ClickHouse-databas för människor, eller Utomjordingars teknologi

Aleksej Lizunov, chef för avdelningen för kompetenscentrum för fjärrservicekanaler vid IT-direktionen för MKB

Som ett alternativ till ELK-stacken (ElasticSearch, Logstash, Kibana) genomför vi forskningsarbete om användningen av ClickHouse-databasen som datalager för loggar.

I denna artikel vill vi berätta om våra erfarenheter av att använda ClickHouse-databasen och om de preliminära resultaten efter den inledande driften. Det är värt att notera från början att resultaten har varit imponerande.

Nedan kommer vi att beskriva mer detaljerat hur vårt system är konfigurerat och av vilka komponenter det består. Men vi skulle först vilja berätta lite om denna databas i allmänhet och varför den förtjänar att uppmärksammas. ClickHouse-databasen är en högpresterande kolumnorienterad databas från Yandex. Den används i Yandex-tjänster, och den var från början huvudlagret för data för Yandex.Metrica. Systemet är open-source och gratis. Ur ett utvecklarperspektiv har jag alltid varit nyfiken på hur de har implementerat detta, eftersom de hanterar fantastiskt stora data. Och användargränssnittet för Metrica är mycket flexibelt och snabbt. Vid första bekantskap med denna databas är intrycket: "Äntligen! Gjord för människor!" Från installationsprocessen till att skicka förfrågningar.

Denna databas har en mycket låg inträdeströskel. Även en medelstor utvecklare kan installera denna databas på några minuter och börja använda den. Allt fungerar smidigt. Även personer som är dåligt bekanta med Linux kan snabbt hantera installationen och utföra grundläggande operationer. Tidigare, när ordet Big Data nämndes, hade vanliga utvecklare ofta en uppfattning om att det handlade om terabyte, petabyte, att det var övermän som sysslade med inställningar och utveckling för dessa system. Men med framkomsten av ClickHouse-databasen har vi fått ett enkelt, begripligt verktyg som gör det möjligt att lösa tidigare oöverkomliga uppgifter. Det räcker med en tämligen medelmåttig maskin och fem minuter för installation. Så vi har fått en databas som MySql, fast för att lagra miljarder poster! En slags superkompressor med SQL-språk. Det är som om människor har fått utomjordisk beväpning.

Om vårt loggsamlingssystem

För insamling av information används loggfiler från IIS webbapplikationer i standardformat (vi arbetar även med att parsa loggar från applikationer, men vårt huvudsyfte under pilotdriften är insamling av IIS-loggar).

Vi har inte kunnat helt överge ELK-stacken av olika skäl, och vi fortsätter att använda komponenter som LogStash och Filebeat, vilka har visat sig pålitliga och fungerar stabilt.

Den övergripande loggning schemat presenteras i bilden nedan:

En specifik egenskap för att skriva data i ClickHouse-databasen är den sällsynta (en gång per sekund) insättningen av poster i stora batchar. Detta är nämligen den mest «problematiska» delen som man stöter på vid första användning av ClickHouse: schemat blir något mer komplicerat.
Här hjälpte en plugin för LogStash, som direkt sätter in data i ClickHouse. Denna komponent installeras på samma server som databasen. Generellt sett rekommenderas inte detta, men praktiskt sett, för att undvika att skapa separata servrar, är det acceptabelt så länge den är installerad på samma server. Vi har inte observerat några krascher eller resurskonflikter med databasen. Dessutom är det värt att nämna att plugin har en retry-mekanism vid fel. Vid fel skriver plugin en batch data som inte kunde sättas in på disk (filformatet är bekvämt: efter redigering kan man enkelt återinsätta den korrigerade batchen med hjälp av clickhouse-client).

Den fullständiga listan över programvara som används i schemat presenteras i tabellen:

Lista över använda programvaror

Namn

Beskrivning

Länk till distributionen

NGINX

Reverse-proxy för att begränsa åtkomst via portar och organisera autentisering

Används för närvarande inte i schemat

https://nginx.org/ru/download.html

https://nginx.org/download/nginx-1.16.0.tar.gz

FileBeat

Överföring av loggfiler.

https://www.elastic.co/downloads/beats/filebeat (distribution för Windows 64bit).

https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-7.3.0-windows-x86_64.zip

LogStash

Loggsamlare.

Används för insamling av loggar från FileBeat samt för att samla loggar från RabbitMQ-kön (för servrar som finns i DMZ).

https://www.elastic.co/products/logstash

https://artifacts.elastic.co/downloads/logstash/logstash-7.0.1.rpm

Logstash-output-clickhouse

Logstash-plugin för att överföra loggar till ClickHouse-databasen i batchar

https://github.com/mikechris/logstash-output-clickhouse

/usr/share/logstash/bin/logstash-plugin install logstash-output-clickhouse

/usr/share/logstash/bin/logstash-plugin install logstash-filter-prune

/usr/share/logstash/bin/logstash-plugin install logstash-filter-multiline

ClickHouse

Logglagring https://clickhouse.yandex/docs/ru/

https://packagecloud.io/Altinity/clickhouse/packages/el/7/clickhouse-server-19.5.3.8-1.el7.x86_64.rpm

https://packagecloud.io/Altinity/clickhouse/packages/el/7/clickhouse-client-19.5.3.8-1.el7.x86_64.rpm

Anmärkning. Från och med augusti 2018 finns det "normala" rpm-byggnader i Yandex-repositoriet för RHEL, så de kan provas. Vid installationstillfället använde vi paket byggda av Altinity.

Grafana

Visualisering av loggar. Inställning av instrumentpaneler

https://grafana.com/

https://grafana.com/grafana/download

Redhat & Centos (64 Bit) – senaste versionen

ClickHouse-datakälla för Grafana 4.6+

Plugin för Grafana med ClickHouse datakälla

https://grafana.com/plugins/vertamedia-clickhouse-datasource

https://grafana.com/api/plugins/vertamedia-clickhouse-datasource/versions/1.8.1/download

LogStash

Loggrouter från FileBeat till RabbitMQ-kön.

Observera. Tyvärr har FileBeat ingen direkt output till RabbitMQ, så en mellanhand i form av Logstash krävs.

https://www.elastic.co/products/logstash

https://artifacts.elastic.co/downloads/logstash/logstash-7.0.1.rpm

RabbitMQ

Meddelandekö. Detta är en buffert för loggposter i DMZ.

https://www.rabbitmq.com/download.html

https://github.com/rabbitmq/rabbitmq-server/releases/download/v3.7.14/rabbitmq-server-3.7.14-1.el7.noarch.rpm

Erlang Runtime (Nödvändigt för RabbitMQ)

Erlang-miljö. Krävs för att köra RabbitMQ.

http://www.erlang.org/download.html

https://www.rabbitmq.com/install-rpm.html#install-erlang http://www.erlang.org/downloads/21.3

Serverkonfiguration med ClickHouse-databas redovisas i följande tabell:

Namn

Värde

Anmärkning

Konfiguration

HDD: 40GB
RAM: 8GB
Processor: Core 2 2Ghz

Det är viktigt att följa råden för användning av ClickHouse-databasen (https://clickhouse.yandex/docs/ru/operations/tips/)

Systemprogramvara

OS: Red Hat Enterprise Linux Server (Maipo)

JRE (Java 8)

Som synes är det en vanlig arbetsstation.

Tabellstrukturen för att lagra loggar ser ut på följande sätt:

log_web.sql

CREATE TABLE log_web (
  logdate Date,
  logdatetime DateTime CODEC(Delta, LZ4HC),
   
  fld_log_file_name LowCardinality( String ),
  fld_server_name LowCardinality( String ),
  fld_app_name LowCardinality( String ),
  fld_app_module LowCardinality( String ),
  fld_website_name LowCardinality( String ),
 
  serverIP LowCardinality( String ),
  method LowCardinality( String ),
  uriStem String,
  uriQuery String,
  port UInt32,
  username LowCardinality( String ),
  clientIP String,
  clientRealIP String,
  userAgent String,
  referer String,
  response String,
  subresponse String,
  win32response String,
  timetaken UInt64
   
  , uriQuery__utm_medium String
  , uriQuery__utm_source String
  , uriQuery__utm_campaign String
  , uriQuery__utm_term String
  , uriQuery__utm_content String
  , uriQuery__yclid String
  , uriQuery__region String
 
) Engine = MergeTree()
PARTITION BY toYYYYMM(logdate)
ORDER BY (fld_app_name, fld_app_module, logdatetime)
SETTINGS index_granularity = 8192;

Vi använder standardvärden för partitionering (per månad) och indexgranularitet. Alla fält stämmer praktiskt taget överens med loggposterna från IIS för registrering av http-förfrågningar. Särskilt märkta är separata fält för lagring av utm-taggar (de parsas vid insättning i tabellen från förfrågningssträngen).

I tabellen har även flera systemfält lagts till för att lagra information om system, komponenter, servrar. Beskrivning av dessa fält finns nedan i tabellen. I en tabell lagrar vi loggar från flera system.

Namn

Beskrivning

Exempel

fld_app_name

Namn på applikationen/systemet
Tillåtna värden:

site1.domain.com Extern webbplats 1
site2.domain.com Extern webbplats 2
internal-site1.domain.local Intern webbplats 1

site1.domain.com

fld_app_module

Systemmodul
Tillåtna värden:

web — Webbplats
svc — Webbservice för webbplatsen
intgr — Integrations-webbservice
bo — Admin (BackOffice)

web

fld_website_name

Namn på webbplatsen i IIS

På en server kan flera system vara installerade, eller till och med flera instanser av en modul.

web-main

fld_server_name

Servernamn

web1.domain.com

fld_log_file_name

Sökväg till loggfilen på servern

C:inetpublogsLogFiles
W3SVC1u_ex190711.log

Det här gör det möjligt att effektivt bygga diagram i Grafana. Till exempel, att se förfrågningar från frontend av ett visst system. Det liknar en webbplatsräknare i Yandex.Metrika.

Här är lite statistik om databasanvändning under två månader.

Antal poster uppdelade efter system och deras komponenter

SELECT
    fld_app_name,
    fld_app_module,
    count(fld_app_name) AS rows_count
FROM log_web
GROUP BY
    fld_app_name,
    fld_app_module
    WITH TOTALS
ORDER BY
    fld_app_name ASC,
    rows_count DESC
 
┌─fld_app_name─────┬─fld_app_module─┬─rows_count─┐
│ site1.domain.ru  │ web            │     131441 │
│ site2.domain.ru  │ web            │    1751081 │
│ site3.domain.ru  │ web            │  106887543 │
│ site3.domain.ru  │ svc            │   44908603 │
│ site3.domain.ru  │ intgr          │    9813911 │
│ site4.domain.ru  │ web            │     772095 │
│ site5.domain.ru  │ web            │   17037221 │
│ site5.domain.ru  │ intgr          │     838559 │
│ site5.domain.ru  │ bo             │       7404 │
│ site6.domain.ru  │ web            │     595877 │
│ site7.domain.ru  │ web            │   27778858 │
└──────────────────┴────────────────┴────────────┘
 
Totals:
┌─fld_app_name─┬─fld_app_module─┬─rows_count─┐
│              │                │  210522593 │
└──────────────┴────────────────┴────────────┘
 
11 rows in set. Elapsed: 4.874 sec. Processed 210.52 million rows, 421.67 MB (43.19 million rows/s., 86.51 MB/s.)

Dataomfång på disk

SELECT
    formatReadableSize(sum(data_uncompressed_bytes)) AS uncompressed,
    formatReadableSize(sum(data_compressed_bytes)) AS compressed,
    sum(rows) AS total_rows
FROM system.parts
WHERE table = 'log_web'
 
┌─uncompressed─┬─compressed─┬─total_rows─┐
│ 54.50 GiB    │ 4.86 GiB   │  211427094 │
└──────────────┴────────────┴────────────┘
 
1 rows in set. Elapsed: 0.035 sec.

Kompressionen av data i kolumner

VÄLJ
    namn,
    formatReadableSize(data_uncompressed_bytes) SOM okomprimerad,
    formatReadableSize(data_compressed_bytes) SOM komprimerad,
    data_uncompressed_bytes / data_compressed_bytes SOM komprimeringsförhållande
FRÅN system.columns
DÄR tabell = 'log_web'
 
┌─namn────────────────────┬─okomprimerad─┬─komprimerad─┬─────komprimeringsförhållande─┐
│ logdatum                │ 401.53 MiB   │ 1.80 MiB    │ 223.16665968777315 │
│ logdatumtid            │ 803.06 MiB   │ 35.91 MiB   │ 22.363966401202305 │
│ fld_log_file_name      │ 220.66 MiB   │ 2.60 MiB    │ 84.99905736932571 │
│ fld_server_name        │ 201.54 MiB   │ 50.63 MiB   │ 3.980924816977078 │
│ fld_app_name           │ 201.17 MiB   │ 969.17 KiB  │ 212.55518183686877 │
│ fld_app_module         │ 201.17 MiB   │ 968.60 KiB  │ 212.67805817411906 │
│ fld_website_name       │ 201.54 MiB   │ 1.24 MiB    │ 162.7204926761546 │
│ serverIP               │ 201.54 MiB   │ 50.25 MiB   │ 4.010824061219731 │
│ metod                  │ 201.53 MiB   │ 43.64 MiB   │ 4.617721053304486 │
│ uriStem                │ 5.13 GiB     │ 832.51 MiB  │ 6.311522291936919 │
│ uriQuery               │ 2.58 GiB     │ 501.06 MiB  │ 5.269731450124478 │
│ port                   │ 803.06 MiB   │ 3.98 MiB    │ 201.91673864241824 │
│ användarnamn           │ 318.08 MiB   │ 26.93 MiB   │ 11.812513794583598 │
│ klientIP               │ 2.35 GiB     │ 82.59 MiB   │ 29.132328640073343 │
│ klientRealIP           │ 2.49 GiB     │ 465.05 MiB  │ 5.478382297052563 │
│ användarAgent          │ 18.34 GiB    │ 764.08 MiB  │ 24.57905114484208 │
│ referens               │ 14.71 GiB    │ 1.37 GiB    │ 10.736792723669906 │
│ svar                   │ 803.06 MiB   │ 83.81 MiB   │ 9.582334090987247 │
│ delat svar             │ 399.87 MiB   │ 1.83 MiB    │ 218.4831068635027 │
│ win32svar             │ 407.86 MiB   │ 7.41 MiB    │ 55.050315514606815 │
│ tidsåtgång             │ 1.57 GiB     │ 402.06 MiB  │ 3.9947395692010637 │
│ uriQuery__utm_medium   │ 208.17 MiB   │ 12.29 MiB   │ 16.936148912472955 │
│ uriQuery__utm_source   │ 215.18 MiB   │ 13.00 MiB   │ 16.548367623199912 │
│ uriQuery__utm_campaign │ 381.46 MiB   │ 37.94 MiB   │ 10.055156353418509 │
│ uriQuery__utm_term     │ 231.82 MiB   │ 10.78 MiB   │ 21.502540454070672 │
│ uriQuery__utm_content  │ 441.34 MiB   │ 87.60 MiB   │ 5.038260760449327 │
│ uriQuery__yclid        │ 216.88 MiB   │ 16.58 MiB   │ 13.07721335008116 │
│ uriQuery__region       │ 204.35 MiB   │ 9.49 MiB    │ 21.52661903446796 │
└────────────────────────┴──────────────┴────────────┴────────────────────┘
 
28 rader i uppsättning. Förfluten tid: 0.005 sek.

Beskrivning av använda komponenter

FileBeat. Överföring av filloggar

Denna komponent övervakar ändringar i loggfiler på disken och skickar information till LogStash. Installationen görs på alla servrar där loggfiler skrives (vanligtvis IIS). Arbetar i tail-läge (dvs skickar endast tillagda poster i filen). Men kan även konfigureras för att överföra hela filer. Detta är praktiskt när du behöver ladda upp data från föregående månader. Sätt bara loggfilen i mappen så läser den automatiskt hela filen.

När tjänsten stängs av slutar data att överföras vidare till lagringsutrymmet.

Ett exempel på konfigurationen ser ut som följer:

filebeat.yml

filebeat.inputs:
- type: log
  enabled: true
  paths:
    - C:/inetpub/logs/LogFiles/W3SVC1/*.log
  exclude_files: ['.gz$','.zip$']
  tail_files: true
  ignore_older: 24h
  fields:
    fld_server_name: "site1.domain.ru"
    fld_app_name: "site1.domain.ru"
    fld_app_module: "web"
    fld_website_name: "web-main"
 
- type: log
  enabled: true
  paths:
    - C:/inetpub/logs/LogFiles/__Import/access_log-*
  exclude_files: ['.gz$','.zip$']
  tail_files: false
  fields:
    fld_server_name: "site2.domain.ru"
    fld_app_name: "site2.domain.ru"
    fld_app_module: "web"
    fld_website_name: "web-main"
    fld_logformat: "logformat__apache"
 
 
filebeat.config.modules:
  path: ${path.config}/modules.d/*.yml
  reload.enabled: false
  reload.period: 2s
 
output.logstash:
  hosts: ["log.domain.com:5044"]
 
  ssl.enabled: true
  ssl.certificate_authorities: ["C:/filebeat/certs/ca.pem", "C:/filebeat/certs/ca-issuing.pem"]
  ssl.certificate: "C:/filebeat/certs/site1.domain.ru.cer"
  ssl.key: "C:/filebeat/certs/site1.domain.ru.key"
 
#================================ Processorer =====================================
 
processors:
  - add_host_metadata: ~
  - add_cloud_metadata: ~

LogStash. Logsamlaren

Den här komponenten är avsedd att ta emot loggar från FileBeat (antingen via RabbitMQ-kö), parsning och batchinmatning i ClickHouse-databasen.

För insättning i ClickHouse används Logstash-output-clickhouse-plugin. Logstash-plugin har en mekanism för att återförsöka förfrågningar, men vid normal avstängning är det bättre att stänga själva tjänsten. Vid avstängning kommer meddelanden att samlas i RabbitMQ-kö, så om avstängningen är långvarig är det bättre att stänga av Filebeat på servrarna. I schemat där RabbitMQ inte används (i det lokala nätverket skickar Filebeat loggar direkt till Logstash) fungerar Filebeat fullt acceptabelt och säkert, så för dem går avsaknaden av output utan konsekvenser.

Ett exempel på konfigurationen ser ut som följer:

log_web__filebeat_clickhouse.conf

input {
 
    beats {
        port => 5044
        type => 'iis'
        ssl => true
        ssl_certificate_authorities => ["/etc/logstash/certs/ca.cer", "/etc/logstash/certs/ca-issuing.cer"]
        ssl_certificate => "/etc/logstash/certs/server.cer"
        ssl_key => "/etc/logstash/certs/server-pkcs8.key"
        ssl_verify_mode => "peer"
 
            add_field => {
                "fld_server_name" => "%{[fields][fld_server_name]}"
                "fld_app_name" => "%{[fields][fld_app_name]}"
                "fld_app_module" => "%{[fields][fld_app_module]}"
                "fld_website_name" => "%{[fields][fld_website_name]}"
                "fld_log_file_name" => "%{source}"
                "fld_logformat" => "%{[fields][fld_logformat]}"
            }
    }
 
    rabbitmq {
        host => "queue.domain.com"
        port => 5671
        user => "q-reader"
        password => "password"
        queue => "web_log"
        heartbeat => 30
        durable => true
        ssl => true
        #ssl_certificate_path => "/etc/logstash/certs/server.p12"
        #ssl_certificate_password => "password"
 
        add_field => {
            "fld_server_name" => "%{[fields][fld_server_name]}"
            "fld_app_name" => "%{[fields][fld_app_name]}"
            "fld_app_module" => "%{[fields][fld_app_module]}"
            "fld_website_name" => "%{[fields][fld_website_name]}"
            "fld_log_file_name" => "%{source}"
            "fld_logformat" => "%{[fields][fld_logformat]}"
        }
    }
 
}
 
filter { 
 
      if [message] =~ "^#" {
        drop {}
      }
 
      if [fld_logformat] == "logformat__iis_with_xrealip" {
     
          grok {
            match => ["message", "%{TIMESTAMP_ISO8601:log_timestamp} %{IP:serverIP} %{WORD:method} %{NOTSPACE:uriStem} %{NOTSPACE:uriQuery} %{NUMBER:port} %{NOTSPACE:username} %{IPORHOST:clientIP} %{NOTSPACE:userAgent} %{NOTSPACE:referer} %{NUMBER:response} %{NUMBER:subresponse} %{NUMBER:win32response} %{NUMBER:timetaken} %{NOTSPACE:xrealIP} %{NOTSPACE:xforwarderfor}"]
          }
      } else {
   
          grok {
             match => ["message", "%{TIMESTAMP_ISO8601:log_timestamp} %{IP:serverIP} %{WORD:method} %{NOTSPACE:uriStem} %{NOTSPACE:uriQuery} %{NUMBER:port} %{NOTSPACE:username} %{IPORHOST:clientIP} %{NOTSPACE:userAgent} %{NOTSPACE:referer} %{NUMBER:response} %{NUMBER:subresponse} %{NUMBER:win32response} %{NUMBER:timetaken}"]
          }
 
      }
 
      date {
        match => [ "log_timestamp", "YYYY-MM-dd HH:mm:ss" ]
          timezone => "Etc/UTC"
        remove_field => [ "log_timestamp", "@timestamp" ]
        target => [ "log_timestamp2" ]
      }
 
        ruby {
            code => "tstamp = event.get('log_timestamp2').to_i
                        event.set('logdatetime', Time.at(tstamp).strftime('%Y-%m-%d %H:%M:%S'))
                        event.set('logdate', Time.at(tstamp).strftime('%Y-%m-%d'))"
        }
 
      if [bytesSent] {
        ruby {
          code => "event['kilobytesSent'] = event['bytesSent'].to_i / 1024.0"
        }
      }
 
 
      if [bytesReceived] {
        ruby {
          code => "event['kilobytesReceived'] = event['bytesReceived'].to_i / 1024.0"
        }
      }
 
   
        ruby {
            code => "event.set('clientRealIP', event.get('clientIP'))"
        }
        if [xrealIP] {
            ruby {
                code => "event.set('clientRealIP', event.get('xrealIP'))"
            }
        }
        if [xforwarderfor] {
            ruby {
                code => "event.set('clientRealIP', event.get('xforwarderfor'))"
            }
        }
 
      mutate {
        convert => ["bytesSent", "integer"]
        convert => ["bytesReceived", "integer"]
        convert => ["timetaken", "integer"] 
        convert => ["port", "integer"]
 
        add_field => {
            "clientHostname" => "%{clientIP}"
        }
      }
 
        useragent {
            source => "useragent"
            prefix => "browser"
        }
 
        kv {
            source => "uriQuery"
            prefix => "uriQuery__"
            allow_duplicate_values => false
            field_split => "&"
            include_keys => [ "utm_medium", "utm_source", "utm_campaign", "utm_term", "utm_content", "yclid", "region" ]
        }
 
        mutate {
            join => { "uriQuery__utm_source" => "," }
            join => { "uriQuery__utm_medium" => "," }
            join => { "uriQuery__utm_campaign" => "," }
            join => { "uriQuery__utm_term" => "," }
            join => { "uriQuery__utm_content" => "," }
            join => { "uriQuery__yclid" => "," }
            join => { "uriQuery__region" => "," }
        }
 
}
 
output { 
  #stdout {codec => rubydebug}
    clickhouse {
      headers => ["Authorization", "Basic abcdsfks..."]
      http_hosts => ["http://127.0.0.1:8123"]
      save_dir => "/etc/logstash/tmp"
      table => "log_web"
      request_tolerance => 1
      flush_size => 10000
      idle_flush_time => 1
        mutations => {
            "fld_log_file_name" => "fld_log_file_name"
            "fld_server_name" => "fld_server_name"
            "fld_app_name" => "fld_app_name"
            "fld_app_module" => "fld_app_module"
            "fld_website_name" => "fld_website_name"
 
            "logdatetime" => "logdatetime"
            "logdate" => "logdate"
            "serverIP" => "serverIP"
            "method" => "method"
            "uriStem" => "uriStem"
            "uriQuery" => "uriQuery"
            "port" => "port"
            "username" => "username"
            "clientIP" => "clientIP"
            "clientRealIP" => "clientRealIP"
            "userAgent" => "userAgent"
            "referer" => "referer"
            "response" => "response"
            "subresponse" => "subresponse"
            "win32response" => "win32response"
            "timetaken" => "timetaken"
             
            "uriQuery__utm_medium" => "uriQuery__utm_medium"
            "uriQuery__utm_source" => "uriQuery__utm_source"
            "uriQuery__utm_campaign" => "uriQuery__utm_campaign"
            "uriQuery__utm_term" => "uriQuery__utm_term"
            "uriQuery__utm_content" => "uriQuery__utm_content"
            "uriQuery__yclid" => "uriQuery__yclid"
            "uriQuery__region" => "uriQuery__region"
        }
    }
 
}

pipelines.yml

# This file is where you define your pipelines. You can define multiple.
# For more information on multiple pipelines, see the documentation:
#   https://www.elastic.co/guide/en/logstash/current/multiple-pipelines.html
 
- pipeline.id: log_web__filebeat_clickhouse
  path.config: "/etc/logstash/log_web__filebeat_clickhouse.conf"

ClickHouse. Logg förvaring

Loggar från alla system sparas i en och samma tabell (se i början av artikeln). Den är avsedd för lagring av förfrågningsinformation: alla parametrar är liknande för olika format, till exempel IIS-loggar, apache-loggar och nginx-loggar. För applikationsloggar, där till exempel fel, informationsmeddelanden och varningar registreras, kommer det att finnas en separat tabell med motsvarande struktur (just nu under utveckling).

Vid utformningen av tabellen är det mycket viktigt att bestämma primärnyckeln (som kommer att användas för att sortera data vid lagring). Detta påverkar graden av datakomprimering och hastigheten på förfrågningar. I vårt exempel är nyckeln
ORDER BY (fld_app_name, fld_app_module, logdatetime)
Det vill säga baserat på systemnamnet, komponentnamnet för systemet och händelsedatumet. Ursprungligen var händelsedatumet först. Efter att ha flyttat det till sista platsen blev förfrågningarna ungefär dubbelt så snabba. Att ändra primärnyckeln kräver att tabellen återskapas och att data laddas om så att ClickHouse kan omordna data på disken. Detta är en tung operation, så det är bäst att noga överväga vad som ska ingå i sorteringsnyckeln i god tid.

Det är också värt att notera att i de senaste versionerna har datatypen LowCardinality introducerats. Med dess användning minskar storleken på de komprimerade data drastiskt för de fält som har låg kardinalitet (få alternativ).

För närvarande används version 19.6, och vi planerar att försöka uppgradera till den senaste versionen. I dem har det dykt upp fantastiska funktioner som Adaptiv granularitet, Skipping indices och DoubleDelta-kodek, till exempel.

Som standard är loggnivån trace inställd vid installation i konfigurationen. Loggar roteras och arkiveras, men expanderar samtidigt till en gigabyte. Om det inte är nödvändigt kan loggnivån sättas till warning, vilket kraftigt minskar loggens storlek. Logginställningarna anges i filen config.xml:


warning

Några användbara kommandon

Eftersom de ursprungliga installationspaketen är samlade från Debian, måste paket som samlas av Altinity användas för andra versioner av Linux.

Här är instruktioner med länkar till deras repository: https://www.altinity.com/blog/2017/12/18/logstash-with-clickhouse
sudo yum search clickhouse-server
sudo yum install clickhouse-server.noarch

1. kontrollera status
sudo systemctl status clickhouse-server

2. stoppa servern
sudo systemctl stop clickhouse-server

3. starta servern
sudo systemctl start clickhouse-server

Starta för att utföra frågor i flermodusläge (körs efter tecknet ";")
clickhouse-client --multiline
clickhouse-client --multiline --host 127.0.0.1 --password pa55w0rd
clickhouse-client --multiline --host 127.0.0.1 --port 9440 --secure --user default --password pa55w0rd

Logstash ClickHouse-plugin sparar hela batchen i filen /tmp/log_web_failed.json i händelse av ett fel på en rad.
Denna fil kan manuellt korrigeras och laddas upp till databasen manuellt:
clickhouse-client --host 127.0.0.1 --password password --query="INSERT INTO log_web FORMAT JSONEachRow" < /tmp/log_web_failed__fixed.json

sudo mv /etc/logstash/tmp/log_web_failed.json /etc/logstash/tmp/log_web_failed__fixed.json
sudo chown user_dev /etc/logstash/tmp/log_web_failed__fixed.json
sudo clickhouse-client --host 127.0.0.1 --password password --query="INSERT INTO log_web FORMAT JSONEachRow" < /etc/logstash/tmp/log_web_failed__fixed.json
sudo mv /etc/logstash/tmp/log_web_failed__fixed.json /etc/logstash/tmp/log_web_failed__fixed_.json

avsluta kommandoraden
quit;
## TLS Konfiguration
https://www.altinity.com/blog/2019/3/5/clickhouse-networking-part-2

openssl s_client -connect log.domain.com:9440 < /dev/null

LogStash. Log-router från FileBeat till RabbitMQ-kö

Denna komponent används för att vidarebefordra loggar som kommer från FileBeat till RabbitMQ-kön. Här finns två frågor:

Tyvärr har FileBeat ingen output-plugin för att skriva direkt till RabbitMQ. Den funktionen, enligt issue på deras GitHub, planeras inte att implementeras. Det finns en plugin för Kafka, men av vissa skäl kan vi inte använda den hos oss.
Det finns krav för insamling av loggar i DMZ. Utifrån dessa krav måste loggar först placeras i en kö, och sedan läser LogStash externt från kön.

Därför måste en något mer komplicerad schema användas när servrarna är placerade i DMZ. Ett exempel på konfiguration ser ut på följande sätt:

iis_w3c_logs__filebeat_rabbitmq.conf

input {
 
    beats {
        port => 5044
        type => 'iis'
        ssl => true
        ssl_certificate_authorities => ["/etc/pki/tls/certs/app/ca.pem", "/etc/pki/tls/certs/app/ca-issuing.pem"]
        ssl_certificate => "/etc/pki/tls/certs/app/queue.domain.com.cer"
        ssl_key => "/etc/pki/tls/certs/app/queue.domain.com-pkcs8.key"
        ssl_verify_mode => "peer"
    }
 
}
 
output { 
  #stdout {codec => rubydebug}
 
    rabbitmq {
        host => "127.0.0.1"
        port => 5672
        exchange => "monitor.direct"
        exchange_type => "direct"
        key => "%{[fields][fld_app_name]}"
        user => "q-writer"
        password => "password"
        ssl => false
    }
}

RabbitMQ. Meddelandekö

Denna komponent används för att buffra loggposter i DMZ. Inspelningen görs genom kombinationen Filebeat → LogStash. Läsning sker utanför DMZ via LogStash. Vid drift via RabbitMQ bearbetas cirka 4 000 meddelanden per sekund.

Meddelandena routas baserat på systemets namn, det vill säga baserat på konfigurationsdata från FileBeat. Alla meddelanden hamnar i en kö. Om meddelandeköservicen av någon anledning stoppas, leder det inte till meddelandeförlust: FileBeat kommer att få anslutningsfel och tillfälligt pausa sändningen. LogStash, som läser från kön, kommer också att få nätverksfel och vänta på att anslutningen ska återställas. Under tiden kommer data naturligtvis att sluta skrivas till databasen.

Följande instruktioner används för att skapa och konfigurera köer:

sudo /usr/local/bin/rabbitmqadmin/rabbitmqadmin declare exchange --vhost=/ name=monitor.direct type=direct sudo /usr/local/bin/rabbitmqadmin/rabbitmqadmin declare queue --vhost=/ name=web_log durable=true
sudo /usr/local/bin/rabbitmqadmin/rabbitmqadmin --vhost="/" declare binding source="monitor.direct" destination_type="queue" destination="web_log" routing_key="site1.domain.ru"
sudo /usr/local/bin/rabbitmqadmin/rabbitmqadmin --vhost="/" declare binding source="monitor.direct" destination_type="queue" destination="web_log" routing_key="site2.domain.ru"

Grafana. Instrumentpaneler

Denna komponent används för att visualisera övervakningsdata. Det är nödvändigt att installera pluginen ClickHouse datasource for Grafana 4.6+. Vi var tvungna att justera den något för att öka effektiviteten i hanteringen av SQL-filter på instrumentpanelen.

Till exempel använder vi variabler och om de inte är angivna i filtreringsfältet, skulle vi gärna se att det inte genererade ett villkor i WHERE av typen ( uriStem = » AND uriStem != » ). I så fall kommer ClickHouse att läsa kolumnen uriStem. Generellt prövade vi olika alternativ och slutligen justerade vi pluginen (makroet $valueIfEmpty), så att den vid tomt värde returnerade 1, utan att nämna själva kolumnen.

Och nu kan vi använda en sådan fråga för diagrammet

$columns(response, count(*) c) from $table where $adhoc
and $valueIfEmpty($fld_app_name, 1, fld_app_name = '$fld_app_name')
and $valueIfEmpty($fld_app_module, 1, fld_app_module = '$fld_app_module') and $valueIfEmpty($fld_server_name, 1, fld_server_name = '$fld_server_name') and $valueIfEmpty($uriStem, 1, uriStem like '%$uriStem%')
and $valueIfEmpty($clientRealIP, 1, clientRealIP = '$clientRealIP')

som som omvandlas till följande SQL (notera att tomma fält uriStem har omvandlats till bara 1)

VÄLj

t,
groupArray((response, c)) AS groupArr
FRÅN (
VÄLj
(intDiv(toUInt32(logdatetime), 60) * 60) * 1000 AS t, response,
count(*) AS c FRÅN default.log_web
VAR (logdate >= toDate(1565061982)) OCH (logdatetime >= toDateTime(1565061982)) OCH 1 OCH (fld_app_name = 'site1.domain.ru') OCH (fld_app_module = 'web') OCH 1 OCH 1 OCH 1
GRUPPERA EFTER
t, response
ORDNA EFTER
t ASC,
response ASC
)
GRUPPERA EFTER t ORDNA EFTER t ASC

Slutsats

Införandet av ClickHouse-databasen var en betydande händelse på marknaden. Det var svårt att föreställa sig att vi plötsligt fick ett kraftfullt och praktiskt verktyg för arbete med stora datamängder helt gratis. Självklart kommer schemat att bli mer komplext när kraven ökar (som sharding och replikering på flera servrar). Men vid första intrycket är det mycket trevligt att arbeta med denna databas. Det är tydligt att produkten är gjord "för människor".

Jämfört med ElasticSearch beräknas kostnaderna för lagring och bearbetning av loggar minska mellan fem och tio gånger. Med andra ord, om vi behövde konfigurera ett kluster av flera maskiner för den aktuella datavolymen, skulle vi med ClickHouse räcka med en svag maskin. Ja, det finns även mekanismer för datakomprimering på disken i ElasticSearch och andra funktioner som kraftigt kan minska resursförbrukningen, men jämfört med ClickHouse kräver det högre kostnader.

Utan några speciella optimeringar från vår sida, med standardinställningar, fungerar dataladdning och frågor mot databasen med fantastisk hastighet. Vi har för tillfället inte mycket data (ungefär 200 miljoner poster), men själva servern är svag. Detta verktyg kan vi i framtiden även använda för andra ändamål som är orelaterade till logglagring. Till exempel för end-to-end-analys, inom säkerhet, maskininlärning.

Slutligen, lite om för- och nackdelar.

Nackdelar

Laddning av poster i stora partier. Å ena sidan är detta en funktion, men det krävs ändå ytterligare komponenter för buffring av poster. Denna uppgift är inte alltid enkel, men den är ändå lösbar. Och vi skulle vilja förenkla schemat.
Vissa exotiska funktioner eller nya funktioner bryter ofta i nya versioner. Detta väcker oro och minskar viljan att uppgradera till den nya versionen. Till exempel, Kafka-tabellmotorn är en mycket användbar funktion som låter dig läsa händelser direkt från Kafka, utan att implementera konsumenter. Men med tanke på antalet problem på GitHub, är vi osäkra på att använda denna motor i produktion. Men om man undviker hastiga förändringar och använder den grundläggande funktionaliteten, fungerar den stabilt.