🥇DB ClickHouse pro lidi, nebo Technologie mimozemšťanů

Alexej Lizunov, vedoucí oddělení centra kompetencí pro vzdálené služby informačních technologií MKB

Jako alternativu k technologickému stacku ELK (ElasticSearch, Logstash, Kibana) provádíme výzkumné práce na využití databáze ClickHouse jako datového úložiště pro logy.

V tomto článku bychom chtěli sdílet naše zkušenosti s používáním databáze ClickHouse a předběžné výsledky z pilotního provozu. Je nutné hned říci, že výsledky byly působivé.

Dále podrobně popíšeme, jak máme systém nastavený a z jakých komponentů se skládá. Ale nyní bych chtěl trochu hovořit o této databázi obecně a proč na ni stojí za to se zaměřit. Databáze ClickHouse je vysoce výkonná analytická sloupcová databáze od Yandexu. Používá se v službách Yandexu a původně to bylo hlavní datové úložiště pro Yandex.Metrika. Je to open-source, zdarma. Z pohledu vývojáře mě vždy zajímalo, jak to mají realizované, jelikož pracují s fantasticky velkými daty. A uživatelské rozhraní Metriky je velmi flexibilní a rychlé. Při prvním setkání s touto databází je dojem: 'Konečně! Uděláno "pro lidi"! Od procesu instalace až po odesílání dotazů.'

Tato databáze má velmi nízkou vstupní bariéru. I průměrně kvalifikovaný vývojář může za pár minut tuto databázi nainstalovat a začít ji používat. Všechno funguje hladce. Dokonce i lidé, kteří nejsou dobře obeznámeni s Linuxem, mohou poměrně rychle zvládnout instalaci a provádět základní operace. Pokud dříve při slově Big Data, Hadoop, Google BigTable, HDFS, měl obyčejný vývojář představy, že jde o nějaké terabajty, petabajty, že konfigurací a vývojem pro tyto systémy se zabývají nějací nadlidé, s příchodem databáze ClickHouse jsme získali jednoduchý, srozumitelný nástroj, se kterým můžeme řešit dosud nedosažitelné úkoly. Stačí průměrný stroj a pět minut na instalaci. Tedy dostali jsme databázi jako MySQL, ale pouze pro ukládání miliard záznamů! Něco jako superarchivátor s jazykem SQL. Je to, jako by lidem předali zbraň mimozemšťanů.

O našem systému sběru logů

Pro sběr informací se používají soubory logů IIS webových aplikací ve standardním formátu (v současnosti také provádíme analýzu logů aplikací, ale hlavním cílem v pilotní fázi je sběr logů IIS).

Zcela se vzdát stacku ELK se nám z různých důvodů nepodařilo, pokračujeme v používání komponent LogStash a Filebeat, které se osvědčily jako spolehlivé a předvídatelné.

Celková schéma logování je znázorněna na obrázku níže:

Specifikou zápisu dat do databáze ClickHouse je různě častá (jednou za sekundu) insertace záznamů ve velkých dávkách. To je zřejmě nejproblematičtější část, se kterou se setkáte při prvním použití databáze ClickHouse: schéma je trochu komplikované.
Tady výrazně pomohl plugin pro LogStash, který přímo vkládá data do ClickHouse. Tento komponent je nasazen na stejném serveru jako samotná databáze. To se obecně nedoporučuje, ale z praktického hlediska, abychom nemuseli vytvářet další servery, dokud je nasazen na stejném serveru. Nebyly pozorovány žádné výpadky ani konflikty zdrojů s databází. Je také třeba poznamenat, že plugin má mechanismus retry v případě chyb. A v případě chyb plugin zapisuje na disk dávku dat, která nebyla vložena (formát souboru je pohodlný: po úpravě lze snadno znovu vložit opravenou dávku pomocí clickhouse-client).

Úplný seznam softwaru, který se používá v schématu, je uveden v tabulce:

Seznam používaného softwaru

Název

Popis

Odkaz na distribuční balíček

NGINX

Reverse-proxy pro omezení přístupu podle portů a organizaci autorizace

V současnosti se v schématu nepoužívá

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

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

FileBeat

Přenášení souborových logů.

https://www.elastic.co/downloads/beats/filebeat (distribuční balíček pro Windows 64bit).

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

LogStash

Sběrač logů.

Používá se pro sběr logů od FileBeat, a také pro sběr logů z fronty RabbitMQ (pro servery, které se nacházejí v DMZ.)

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

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

Logstash-output-clickhouse

Plugin Logstash pro přenos logů do databáze ClickHouse v dávkách

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

Úložiště logů 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

Poznámka. Od srpna 2018 existují v repozitáři Yandexu "normální" sestavení rpm pro RHEL, takže je možné je zkusit použít. V době instalace jsme používali balíčky sestavené Altinity.

Grafana

Vizualizace logů. Nastavení dashboardů

https://grafana.com/

https://grafana.com/grafana/download

Redhat & Centos (64 Bit) – poslední verze

ClickHouse datasource for Grafana 4.6+

Plugin pro Grafanu se zdrojem dat ClickHouse

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

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

LogStash

Router logů od FileBeat do fronty RabbitMQ.

Poznámka. Bohužel FileBeat nemá output přímo do RabbitMQ, proto je zapotřebí mezičlánek v podobě Logstash

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

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

RabbitMQ

Fronta zpráv. To je buffer zápisů logů v 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 (Potřebné pro RabbitMQ)

Erlang prostředí. Je požadováno pro fungování RabbitMQ

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

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

Konfigurace serveru s databází ClickHouse je uvedena v následující tabulce:

Název

Hodnota

Poznámka

Konfigurace

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

Je nutné věnovat pozornost radám pro provoz databáze ClickHouse (https://clickhouse.yandex/docs/ru/operations/tips/)

Systémový software

OS: Red Hat Enterprise Linux Server (Maipo)

JRE (Java 8)

Jak je vidět, toto je běžná pracovní stanice.

Struktura tabulky pro ukládání logů vypadá následovně:

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;

Používáme výchozí hodnoty pro partitioning (podle měsíců) a granularitu indexu. Všechna pole jsou prakticky odpovídající záznamům logu IIS pro zaznamenávání http-žádostí. Zvlášť upozorníme na jednotlivé pole pro ukládání utm-štítků (ty jsou parsovány v rámci fáze vkládání do tabulky z pole dotazu).

Do tabulky byly také přidány některé systémové pole pro ukládání informací o systémech, komponentách, serverech. Popis těchto polí najdete níže v tabulce. V jedné tabulce uchováváme logy pro několik systémů.

Název

Popis

Příklad

fld_app_name

Název aplikace/systému
Povolené hodnoty:

site1.domain.com Vnější web 1
site2.domain.com Vnější web 2
internal-site1.domain.local Interní web 1

site1.domain.com

fld_app_module

Modul systému
Povolené hodnoty:

web — Webová stránka
svc — Webová služba webu
intgr — Webová integrační služba
bo — Administrační rozhraní (BackOffice)

web

fld_website_name

Název webu v IIS

Na jednom serveru může být nasazeno více systémů, nebo dokonce více instance jednoho modulu systému

web-main

fld_server_name

Název serveru

web1.domain.com

fld_log_file_name

Cesta k souboru logu na serveru

C:inetpublogsLogFiles
W3SVC1u_ex190711.log

To umožňuje efektivně vytvářet grafy v Grafana. Například pro sledování dotazů z frontendu konkrétního systému. Je to podobné jako počítadlo návštěvnosti v Yandex.Metrice.

Zde jsou některé statistiky o používání databáze za dva měsíce.

Počet záznamů podle systémů a jejich komponentů

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.)

Objem dat na disku

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.

Míra komprese dat ve sloupcích

VYBERTE
    název,
    formatReadableSize(data_uncompressed_bytes) JAKO nepotlačené,
    formatReadableSize(data_compressed_bytes) JAKO stlačené,
    data_uncompressed_bytes / data_compressed_bytes JAKO poměr_stlačení
Z TABULKY system.columns
KDE tabulka = 'log_web'
 
┌─název───────────────────┬─nepotlačené─┬─stlačené─┬─────poměr_stlačení─┐
│ logdate                │ 401.53 MiB   │ 1.80 MiB   │ 223.16665968777315 │
│ logdatetime            │ 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 │
│ method                 │ 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 │
│ username               │ 318.08 MiB   │ 26.93 MiB  │ 11.812513794583598 │
│ clientIP               │ 2.35 GiB     │ 82.59 MiB  │ 29.132328640073343 │
│ clientRealIP           │ 2.49 GiB     │ 465.05 MiB │  5.478382297052563 │
│ userAgent              │ 18.34 GiB    │ 764.08 MiB │  24.57905114484208 │
│ referer                │ 14.71 GiB    │ 1.37 GiB   │ 10.736792723669906 │
│ response               │ 803.06 MiB   │ 83.81 MiB  │  9.582334090987247 │
│ subresponse            │ 399.87 MiB   │ 1.83 MiB   │  218.4831068635027 │
│ win32response          │ 407.86 MiB   │ 7.41 MiB   │ 55.050315514606815 │
│ timetaken              │ 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 řádků v setu. Uplynulý čas: 0.005 sekundy.

Popis použitých komponentů

FileBeat. Přenos souborových logů

Tato komponenta sleduje změny v souborových logech na disku a přenáší informace do LogStash. Je nainstalována na všech serverech, kde se zapisují soubory s logy (obvykle IIS). Pracuje v režimu tail (tj. přenáší pouze nové záznamy do souboru). Lze ji ale nastavit také na přenos celých souborů. To je užitečné, když potřebujete nahrát data za předchozí měsíce. Stačí umístit soubor s logem do složky a ona ho přečte celý.

Při zastavení služby se data přestanou přenášet do úložiště.

Příklad konfigurace vypadá následujícím způsobem:

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"
 
#================================ Processors =====================================
 
processors:
  - add_host_metadata: ~
  - add_cloud_metadata: ~

LogStash. Sběrač logů

Tato komponenta je určena pro příjem záznamů logů od FileBeat (buď přes frontu RabbitMQ), parsování a hromadné vkládání do databáze ClickHouse.

Pro vkládání do ClickHouse se používá plug-in Logstash-output-clickhouse. Plug-in Logstash má mechanismus pro opakování požadavků, ale při běžném zastavení je nejlepší zastavit i samotnou službu. Při zastavení se budou hromadit zprávy ve froně RabbitMQ, takže pokud se zastavení protáhne, je lepší zastavit Filebeat na serverech. V scénáři, kde se RabbitMQ nepoužívá (v lokální síti Filebeat přímo posílá logy do Logstash), fungují Filebeat dostatečně a bezpečně, takže nedostupnost výstupu pro ně probíhá bez následků.

Příklad konfigurace vypadá následujícím způsobem:

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. Úložiště protokolů

Logy ze všech systémů jsou ukládány do jedné tabulky (viz začátek článku). Je určena pro uchovávání informací o požadavcích: všechny parametry jsou podobné pro různé formáty, například logy IIS, logy apache a nginx. Pro logy aplikací, ve kterých jsou zaznamenávány například chyby, informační zprávy a varování, bude k dispozici samostatná tabulka s odpovídající strukturou (nyní ve fázi návrhu).

Při návrhu tabulky je velmi důležité určit primární klíč (podle kterého budou data tříděna při ukládání). Od toho závisí míra komprese dat a rychlost dotazů. V našem příkladu je klíčem
ORDER BY (fld_app_name, fld_app_module, logdatetime)
T. j. podle názvu systému, názvu komponenty systému a data události. Původně byla data události na prvním místě. Po přesunutí na poslední místo se dotazy začaly provádět zhruba dvakrát rychleji. Změna primárního klíče vyžaduje přestavbu tabulky a opětovné nahrání dat, aby ClickHouse přeřadil data na disku. To je náročná operace, takže je žádoucí dopředu dobře promyslet, co by mělo být zahrnuto do klíče pro třídění.

Je také třeba poznamenat, že v posledních verzích se objevil typ dat LowCardinality. Jeho použití výrazně zmenšuje velikost komprimovaných dat pro ta pole, která mají nízkou kardinalitu (málo variant).

Aktuálně používáme verzi 19.6 a plánujeme vyzkoušet aktualizaci na nejnovější verzi. Ty obsahují vynikající funkce, jako jsou Adaptive Granularity, Skipping indices a kodek DoubleDelta.

Při instalaci je v konfiguraci výchozí úroveň protokolování nastavena na trace. Logy jsou rotovány a archivovány, ale zároveň se rozšiřují na gigabyte. Pokud není potřeba, lze nastavit úroveň warning, čímž se velikost logu výrazně sníží. Nastavení protokolování se určuje v souboru config.xml:


warn

Některé užitečné příkazy

Protože se původní instalační balíčky sestavují pro Debian, je nutné pro jiné verze Linuxu používat balíčky sestavené společností Altinity. 
 
Zde je odkaz s instrukcemi a odkazy na jejich repozitář: https://www.altinity.com/blog/2017/12/18/logstash-with-clickhouse
sudo yum search clickhouse-server
sudo yum install clickhouse-server.noarch
  
1. kontrola stavu
sudo systemctl status clickhouse-server
 
2. zastavení serveru
sudo systemctl stop clickhouse-server
 
3. spuštění serveru
sudo systemctl start clickhouse-server
 
Spuštění pro provádění dotazů v multiline režimu (provádějte po znaku ";")
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
 
Plugin ClickHouse pro LogStash v případě chyby v jednom řádku uloží celý balík do souboru /tmp/log_web_failed.json
Tento soubor můžete ručně opravit a zkusit nahrát do DB ručně:
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
 
výstup z příkazového řádku
quit;
## Nastavení TLS
https://www.altinity.com/blog/2019/3/5/clickhouse-networking-part-2
 
openssl s_client -connect log.domain.com:9440 < /dev/null

LogStash. Router logů od FileBeat do fronty RabbitMQ

Tento komponent se používá pro směrování logů pocházejících od FileBeat do fronty RabbitMQ. Zde jsou dva aspekty:

Bohužel, FileBeat nemá output plugin pro přímé zápisy do RabbitMQ. A podle problémů na jejich GitHubu, se tento funkční prvek neplánuje zavést. Existuje plugin pro Kafka, ale z určitých důvodů jej nemůžeme u nás použít.
Existují požadavky na shromažďování logů v DMZ. Na základě nich musí být logy nejprve uloženy do fronty a poté je LogStash čte externě z fronty.

Proto je pro případ umístění serverů v DMZ nutné použít takto mírně komplikovanou schématiku. Příklad konfigurace vypadá následovně:

iis_w3c_logs__filebeat_rabbitmq.conf

vstup {
 
    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"
    }
 
}
 
výstup { 
  #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. Fronta zpráv

Tento komponent je používán pro vyrovnávání logů v DMZ. Záznamy se provádějí prostřednictvím spojení Filebeat → LogStash. Čtení se provádí z venku DMZ přes LogStash. Při použití přes RabbitMQ se zpracovává přibližně 4 tisíce zpráv za sekundu.

Směrování zpráv je nastaveno podle názvu systému, t.j. na základě dat z konfigurace FileBeat. Všechny zprávy směřují do jedné fronty. Pokud je z nějakého důvodu služba front zastavena, nedojde k žádné ztrátě zpráv: FileBeat obdrží chyby připojení a dočasně pozastaví odesílání. A LogStash, který čte z fronty, také obdrží síťové chyby a počká, až se připojení obnoví. Data samozřejmě přestanou být zapisována do DB.

Následující pokyny slouží k vytvoření a nastavení front:

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. Dashboardy

Tento komponent se používá pro vizualizaci monitorovacích dat. Je třeba nainstalovat plugin ClickHouse datasource for Grafana 4.6+. Museli jsme ho trochu upravit, aby se zvýšila účinnost zpracování SQL filtrů na dashboardu.

Například používáme proměnné, a pokud nejsou zadány v poli filtru, chtěli bychom, aby nevytvářel podmínku v WHERE ve tvaru ( uriStem = » AND uriStem != » ). V takovém případě ClickHouse bude číst sloupec uriStem. Celkově jsme zkoušeli různé varianty a nakonec jsme plugin (makro $valueIfEmpty) upravili tak, aby v případě prázdné hodnoty vrátil 1, bez zmiňování samotného sloupce.

A teď lze použít takový dotaz pro graf.

$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')

který se přetváří na tento SQL (všimněte si, že prázdná pole uriStem byla převedena na 1)

SELECT
t,
groupArray((response, c)) AS groupArr
FROM (
SELECT
(intDiv(toUInt32(logdatetime), 60) * 60) * 1000 AS t, response,
count(*) AS c FROM default.log_web
WHERE (logdate >= toDate(1565061982)) AND (logdatetime >= toDateTime(1565061982)) AND 1 AND (fld_app_name = 'site1.domain.ru') AND (fld_app_module = 'web') AND 1 AND 1 AND 1
GROUP BY
t, response
ORDER BY
t ASC,
response ASC
)
GROUP BY t ORDER BY t ASC

Závěr

Vznik databáze ClickHouse byl významnou událostí na trhu. Bylo těžké si představit, že bychom během okamžiku bezplatně získali mocný a praktický nástroj na práci s velkými daty. Samozřejmě se schéma při zvyšování potřeb (např. shardování a replikace na několik serverů) komplikuje. Ale z prvních dojmů, práce s touto databází je velmi příjemná. Je vidět, že produkt byl vyroben „pro lidi“.

Ve srovnání s ElasticSearch se náklady na ukládání a zpracování logů podle prvních odhadů snižují od pěti do deseti násobku. Jinými slovy, zatímco pro aktuální objem dat bychom museli nastavovat klastr několika strojů, s použitím ClickHouse nám stačí jedna slabší mašina. Ano, samozřejmě, i v ElasticSearch existují mechanismy pro kompresi dat na disku a další funkce, které umožňují výrazně snížit spotřebu zdrojů, ale ve srovnání s ClickHouse to vyžaduje větší náklady.

Bez jakýchkoliv speciálních optimalizací z naší strany, s výchozími nastaveními, je načítání dat a výběry z databáze velmi rychlé. Zatím máme málo dat (asi 200 milionů záznamů), ale server je slabý. Tento nástroj můžeme v budoucnu využívat i k dalším účelům, které nesouvisejí s ukládáním logů. Například pro komplexní analýzu, v oblasti bezpečnosti, strojovém učení.

Na závěr něco o výhodách a nevýhodách.

Nevýhody

Načítání záznamů ve velkých dávkách. Z jedné strany je to funkce, ale přesto je třeba používat další komponenty pro vyrovnávání záznamů. Tato úloha není vždy jednoduchá, ale dá se vyřešit. A rádi bychom zjednodušili schéma.
Některé exotické funkce nebo nové vlastnosti se často v nových verzích rozbíjejí. To vyvolává obavy a snižuje chuť přejít na novou verzi. Například motor tabulek Kafka – velmi užitečná funkce, která umožňuje přímo číst události z Kafky, bez implementace consumerů. Ale podle počtu problémů na GitHubu se zatím obáváme používat tento motor v produkčním prostředí. Nicméně, pokud se nebudeme hýbat příliš daleko a využijeme základní funkce, funguje stabilně.