🥇ClickHouse adatbázis az emberekért, vagy Idegen technológiák

Alexey Lizunov, a leader in the Competence Center for Remote Service Channels of the IT Directorate at MKB

As an alternative to the ELK stack (ElasticSearch, Logstash, Kibana), we are conducting research on using ClickHouse DB as a data storage solution for logs.

In this article, we would like to share our experience with ClickHouse DB and the preliminary results from the pilot operation. It should be noted that the results are impressive.

Next, we will describe in detail how our system is configured and its components. But first, we would like to discuss this DB in general and why it deserves attention. ClickHouse DB is a high-performance analytical columnar database from Yandex. It is used in Yandex services and originally served as the primary data storage for Yandex.Metrica. It is open-source and free. As a developer, I have always been curious about how they implemented it, given the fantastically large amounts of data. The Yandex.Metrica user interface is very flexible and works quickly. Upon first acquaintance with this DB, the impression is: 'Finally! Done for the people!' Starting from the installation process to sending queries.

This DB has a very low entry threshold. Even a developer of average qualification can install it in a few minutes and start using it. Everything works smoothly. Even people who are not very familiar with Linux can quickly manage the installation and perform basic operations. Previously, when hearing about Big Data, Hadoop, Google BigTable, HDFS, an average developer might have thought it involved some terabytes or petabytes, believing that only superhumans could configure and develop for these systems. However, with the emergence of ClickHouse DB, we now have a simple and accessible tool with which we can solve previously unattainable tasks. All it takes is one fairly average machine and five minutes for installation. In other words, we have a database like MySQL, but designed for storing billions of records! A kind of super archiver with SQL language. It’s as if people have been handed alien weaponry.

About our log collection system

Az információgyűjtéshez az IIS webalkalmazások standard formátumú naplófájljait használjuk (jelenleg a naplók parsingján is dolgozunk, de a pilot üzemeltetés fázisában a fő célunk az IIS naplók gyűjtése).

Teljes mértékben az ELK stacktől nem tudtunk megszabadulni különböző okok miatt, és továbbra is használjuk a LogStash és Filebeat komponenseit, amelyek jól beváltak és megbízhatóan dolgoznak.

A naplózás általános sémája az alábbi ábrán látható.

A ClickHouse adatbázisba történő adatbejegyzések sajátossága, hogy ritkán (másodpercenként egyszer) nagy adagokban hajtják végre a bejegyzéseket. Ez láthatóan a legproblémásabb rész, amellyel a ClickHouse adatbázissal való első tapasztalat során találkozik az ember: a séma kissé bonyolultabbá válik.
Ebben nagy segítséget nyújtott a LogStash plugin, amely közvetlenül adatokat illeszt be a ClickHouse-ba. Ezt az összetevőt ugyanazon a szerveren kell telepíteni, mint az adatbázis. Így, mondhatni, ezt nem ajánlott megtenni, de gyakorlati szempontból, hogy ne kelljen külön szervereket létrehozni, addig is, amíg ez ugyanazon a szerveren van telepítve. Nem tapasztaltunk leállásokat vagy erőforráskonfliktusokat az adatbázissal. Továbbá fontos megjegyezni, hogy a plugin rendelkezik egy hibakezelő mechanizmussal, amely megpróbálja újra a hibás bejegyzéseket. Hibák esetén a plugin egy adathalmazt ír a lemezre, amelyet nem sikerült beilleszteni (a fájlformátum kényelmes: javítás után könnyen újra beilleszthető a korrigált halmaz a clickhouse-client segítségével).

A használt szoftverek teljes listáját az alábbi táblázat tartalmazza.

A használt szoftverek listája

Név

Leírás

Link a disztribúcióhoz

NGINX

Reverse proxy a portkorlátozás és az azonosítás szervezéséhez

Jelenleg nem alkalmazzák a sémában

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

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

FileBeat

Fájlok naplóinak átadása.

https://www.elastic.co/downloads/beats/filebeat (Windows 64bit disztribúció).

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

LogStash

Naplógyűjtő.

Használják a FileBeat naplók gyűjtésére, valamint a RabbitMQ sorból származó naplók gyűjtésére (a DMZ-ben található szerverek számára).

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

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

Logstash-output-clickhouse

A Logstash plugin a naplók nagyadagokban való átvitelére a ClickHouse adatbázisba.

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

clickhousedb_fdw

Naplóarchívum 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

Megjegyzés: 2018 augusztusától a Yandex repozitóriumában megjelentek a „normális” rpm csomagok a RHEL-hez, így érdemes kipróbálni őket. Telepítéskor az Altinity által készített csomagokat használtuk.

Grafanába

A naplók vizualizálása. Dashbordok beállítása

https://grafana.com/

https://grafana.com/grafana/download

Redhat & Centos (64 bit) – legújabb verzió

ClickHouse adatforrás a Grafana 4.6+ verzióhoz

Grafana plugin a ClickHouse adatforrással

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

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

LogStash

A filebeat log router to RabbitMQ.

Note. Unfortunately, Filebeat does not have direct output to RabbitMQ, so an intermediate link in the form of Logstash is required.

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

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

RabbitMQ

Message queue. This is a buffer for log entries in the 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 (Required for RabbitMQ)

Erlang Runtime. Required for RabbitMQ operation.

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

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

The server configuration with ClickHouse DB is presented in the following table:

Név

Value

Megjegyzés

Konfiguráció

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

It is important to pay attention to the recommendations for using ClickHouse DB (https://clickhouse.yandex/docs/ru/operations/tips/)

System Software

OS: Red Hat Enterprise Linux Server (Maipo)

JRE (Java 8)

As you can see, this is a regular workstation.

The structure of the table for storing logs is as follows:

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;

We use default values for partitioning (by months) and index granularity. All fields largely correspond to IIS log records for HTTP request logging. Notably, separate fields are designated for storing UTM tags (they are parsed during the insertion stage from the query string field).

Also, several system fields have been added to the table to store information about systems, components, and servers. Details of these fields are provided below in the table. In one table, we store logs for several systems.

Név

Leírás

támadásra

fld_app_name

Application/System Name
Allowed values:

site1.domain.com External site 1
site2.domain.com External site 2
internal-site1.domain.local Internal site 1

site1.domain.com

fld_app_module

System Module
Allowed values:

web — Website
svc — Website web service
intgr — Integration web service
bo — Admin panel (BackOffice)

szolgáltatás szeretne hozzáférni egy

fld_website_name

Website Name in IIS

Multiple systems, or even several instances of a single system module, can be deployed on one server.

web-main

fld_server_name

Server Name

web1.domain.com

fld_log_file_name

Path to the log file on the server

C:inetpublogsLogFiles
W3SVC1u_ex190711.log

Ez lehetővé teszi a grafikonok hatékony felépítését a Grafanában. Például a konkrét rendszer front-endjéből származó lekérdezések megtekintését. Ez hasonlít a Yandex.Metrica weboldal-olvasójához.

Itt van néhány statisztika az adatbázis használatáról az elmúlt két hónapban.

Rekordok száma rendszerek és azok komponensei szerint

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.hu  │ web            │     131441 │
│ site2.domain.hu  │ web            │    1751081 │
│ site3.domain.hu  │ web            │  106887543 │
│ site3.domain.hu  │ svc            │   44908603 │
│ site3.domain.hu  │ intgr          │    9813911 │
│ site4.domain.hu  │ web            │     772095 │
│ site5.domain.hu  │ web            │   17037221 │
│ site5.domain.hu  │ intgr          │     838559 │
│ site5.domain.hu  │ bo             │       7404 │
│ site6.domain.hu  │ web            │     595877 │
│ site7.domain.hu  │ 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.)

Az adatok mérete a lemezen

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.

Az adatok tömörítési aránya az oszlopokban

VÁLASZ
    név,
    formázottOlvashatóMéret(data_uncompressed_bytes) AS kiNemTömörített,
    formázottOlvashatóMéret(data_compressed_bytes) AS tömörített,
    data_uncompressed_bytes / data_compressed_bytes AS tömörítési_arány
FROM system.columns
WHERE table = 'log_web'
 
┌─név────────────────────┬─kiNemTömörített─┬─tömörített─┬─────tömörítési_arány─┐
│ 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 sor található az eredményben. Elapsed: 0.005 sec.

A felhasznált összetevők leírása

FileBeat. Fájlnaplók továbbítása

Ez az összetevő figyelemmel kíséri a lemeznaplók fájljaiban bekövetkező változásokat, és az információkat átkonvertálja a LogStash-be. Minden olyan szerveren telepítve van, ahol naplófájlok készülnek (általában IIS). Tail módban működik (azaz csak az újonnan hozzáadott bejegyzéseket továbbítja a fájlba). De külön is beállítható teljes fájlok továbbítására. Ez kényelmes, ha az előző hónapok adatait kell betölteni. Egyszerűen helyezze a naplófájlt egy mappába, és az automatikusan teljes egészében elolvassa.

A szolgáltatás leállításakor az adatok továbbitása leáll a tárolóba.

A konfiguráció például a következőképpen néz ki:

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.hu"
    fld_app_name: "site1.domain.hu"
    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.hu"
    fld_app_name: "site2.domain.hu"
    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.hu.cer"
  ssl.key: "C:/filebeat/certs/site1.domain.hu.key"
 
#================================ Processors =====================================
 
processors:
  - add_host_metadata: ~
  - add_cloud_metadata: ~

LogStash. Naplógyűjtő

Ez az összetevő a FileBeat-től (vagy a RabbitMQ soron keresztül) érkező naplóbejegyzések fogadására, elemzésére és tömeges adatbázisba történő beszúrásra szolgál ClickHouse-ba.

A ClickHouse-ba való beszúráshoz a Logstash-output-clickhouse bővítményt használjuk. A Logstash bővítmény rendelkezik kérésretry mechanizmussal, de normál leállítás esetén jobb, ha magát a szolgáltatást is leállítjuk. Leállításkor üzenetek halmozódnak fel a RabbitMQ sorban, ezért ha a leállás hosszú ideig tart, akkor jobban teszi, ha leállítja a Filebeat-eket a szervereken. Abban a sémában, ahol nem használunk RabbitMQ-t (a helyi hálózaton a Filebeat közvetlenül küldi a naplókat a Logstash-ba), a Filebeat-ek megfelelöen és biztonságosan működnek, ezért számukra a kimenet elérhetetlensége következmények nélkül múlik el.

A konfiguráció például a következőképpen néz ki:

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. Naplózási tároló

Minden rendszer naplója egy táblába kerül mentésre (lásd a cikk elején). Ez a táblázat a kérésinformációk tárolására szolgál: minden paraméter hasonló a különböző formátumokhoz, például IIS, Apache és Nginx naplók esetében. Az alkalmazások naplóihoz, amelyek például hibákat, információs üzeneteket, figyelmeztetéseket rögzítenek, külön táblázat lesz létrehozva a megfelelő struktúrával (jelenleg tervezés alatt áll).

A táblázat tervezése során nagyon fontos meghatározni az elsődleges kulcsot (amely alapján az adatok rendezésre kerülnek a tároláskor). Ez hatással van az adatok tömörítésének mértékére és a lekérdezések sebességére. Példánkban a kulcs a következő:
ORDER BY (fld_app_name, fld_app_module, logdatetime)
Tehát a rendszer neve, a rendszer komponensének neve és az esemény időpontja szerint. Kezdetben az esemény időpontja volt az első helyen. Miután ezt az utolsó helyre költöztettük, a lekérdezések körülbelül kétszer gyorsabban futottak. Az elsődleges kulcs módosítása újra kell létrehozni a táblát és újra kell tölteni az adatokat, hogy a ClickHouse újrarendezze az adatokat a lemezen. Ez egy nehéz művelet, ezért érdemes előre gondolkodni arról, hogy mi tartozik a rendezési kulcsba.

Meg kell jegyezni, hogy a legújabb verziókban megjelent a LowCardinality adat típusa. Ennek használatával drámaian csökkenthető a tömörített adatok mérete az alacsony kardinalitású (kevés opcióval rendelkező) mezők esetében.

Jelenleg a 19.6-os verziót használjuk, és tervezzük, hogy frissítjük a legújabb verzióra. Ezekben csodálatos funkciók jelentek meg, mint például az Adaptív Granularitás, a Kihagyásos indexek és a DoubleDelta kódolás.

Alapértelmezés szerint a telepítés során a konfigurációban a trace szint van beállítva. A naplók forgatódnak és archiválódnak, de közben akár gigabájtokra is bővülhetnek. Ha nincs szükség rá, beállítható a warning szint, amivel a napló mérete jelentősen csökken. A naplózás beállítása a config.xml fájlban történik:

<!-- Lehetséges szintek: https://github.com/pocoproject/poco/blob/develop/Foundation/include/Poco/Logger.h#L105 -->
<level>warning</level>

Néhány hasznos parancs

Mivel az eredeti telepítőcsomagok Debian alapján készülnek, más Linux verziókhoz az Altinity által készült csomagokat kell használni. 

Itt található egy útmutató a repójukra mutató linkekkel: https://www.altinity.com/blog/2017/12/18/logstash-with-clickhouse
sudo yum search clickhouse-server
sudo yum install clickhouse-server.noarch
  
1. az állapot ellenőrzése
sudo systemctl status clickhouse-server
 
2. a szerver leállítása
sudo systemctl stop clickhouse-server
 
3. a szerver indítása
sudo systemctl start clickhouse-server
 
Futtatás a lekérdezések végrehajtására többsoros módban (a ";" utáni végrehajtás)
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
 
A Logstash ClickHouse pluginje hiba esetén az összes csomagot egy fájlba menti: /tmp/log_web_failed.json
Ezt a fájlt manuálisan kijavíthatjuk, és megpróbálhatjuk felölteni a DB-be: 
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
 
kilépés a parancssorból
quit;
## TLS beállítás
https://www.altinity.com/blog/2019/3/5/clickhouse-networking-part-2
 
openssl s_client -connect log.domain.com:9440 < /dev/null

LogStash. A FileBeat log routere RabbitMQ sorba

Ez az összetevő a FileBeat-től érkező logok RabbitMQ sorba történő irányítására szolgál. Két dolog van itt:

Sajnos a FileBeat nem rendelkezik output plugin-nel az adatok közvetlen kiírásához RabbitMQ-ba. A Githubon található hibajegyek alapján ez a funkció nem tervezett. Van plugin Kafka-hoz, de bizonyos okok miatt ezt nem használhatjuk.
Követelmények vannak a logok DMZ-ben történő gyűjtésére. Ezek alapján a logok először egy sorba kerülnek, majd a LogStash kívülről olvassa a sorbejegyzéseket.

Ezért a DMZ-ben elhelyezett szerverek esetében egy kicsit bonyolultabb rendszert kell alkalmazni. A konfiguráció például így néz ki:

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. Üzenetsor

Ez a komponens a DMZ-ben lévő naplóbejegyzések pufferelésére szolgál. A bejegyzés a Filebeat → LogStash kapcsolaton keresztül történik. Az olvasás kívülről, a DMZ-ből a LogStash által történik. A RabbitMQ-n keresztüli használat során körülbelül 4000 üzenetet dolgoz fel másodpercenként.

Az üzenetek irányítása a rendszer neve alapján van beállítva, azaz a FileBeat konfigurációs adatainak alapján. Minden üzenet egy sorba kerül. Ha bármilyen okból leáll a sorozatszolgáltatás, az nem eredményez üzenetvesztést: a FileBeat hibát fog kapni a kapcsolatban, és ideiglenesen leállítja a küldést. A LogStash, ami a sorból olvas, szintén hálózati hibákat fog kapni és várni fog, amíg a kapcsolat helyreáll. Az adatok természetesen nem fognak beíródni az adatbázisba ebben az időszakban.

A következő utasítások a sorok létrehozására és beállítására szolgálnak:

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. Irányítópultok

Ez a komponens a megfigyelési adatok vizualizálására szolgál. Ehhez telepíteni kell a ClickHouse datasource for Grafana 4.6+ plugint. Kicsit módosítanunk kellett rajta, hogy javítsuk az SQL-szűrők feldolgozásának hatékonyságát az irányítópulton.

Például, a változókat használjuk, és ha nincsenek megadva a szűrőmezőben, akkor szeretnénk, ha nem generálna olyan feltételt a WHERE záradékban, mint ( uriStem = » AND uriStem != » ). Ebben az esetben a ClickHouse olvasni fogja az uriStem oszlopot. Összességében különböző lehetőségeket próbáltunk ki, és végül módosítottuk a plugint (makró $valueIfEmpty), hogy üres érték esetén 1-et adjon vissza, anélkül, hogy megemlítené magát az oszlopot.

Most pedig használhatunk egy ilyen lekérdezést a grafikonhoz

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

amely így SQL-re alakul (figyeljen, hogy az üres uriStem mezők egyszerűen 1-re alakultak)

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árás

A ClickHouse adatbázis megjelenése mérföldkőnek számít a piacon. Nehezen képzelhető el, hogy teljesen ingyen, egyik pillanatról a másikra egy erőteljes és gyakorlati eszközhöz jutottunk a nagy adatokkal való munkához. Természetesen a növekvő igényekkel (például több szerverre való sharding és replikáció) a séma bonyolultabbá válik. Az első benyomások alapján azonban rendkívül kellemes dolgozni ezzel az adatbázissal. Nyilvánvaló, hogy ez a termék az emberek számára készült.

Az ElasticSearch-hoz képest a logok tárolásának és feldolgozásának költségei előzetes becslések szerint öt-tízszeresére csökkennek. Más szavakkal, ha a jelenlegi adatmennyiséghez klaszterre lenne szükségünk több gépből, akkor a ClickHouse használatával elegendő lenne egy gyenge teljesítményű gép. Igen, az ElasticSearch-ben is vannak adatok tömörítésére vonatkozó mechanizmusok, és más funkciók, amelyek jelentősen csökkenthetik az erőforrás-fogyasztást, de a ClickHouse-hoz képest ez több költséget igényel.

Mindenféle különleges optimalizálás nélkül, alapbeállítással, az adatok betöltése és a lekérdezések az adatbázisból elképesztő sebességgel működnek. Jelenleg nem sok adatunk van (körülbelül 200 millió rekord), de a szerver gyenge. Ezt az eszközt a jövőben más célokra is felhasználhatjuk, amelyek nem kapcsolódnak a logok tárolásához. Például átfogó analitikára, biztonsági területen, gépi tanulásban.

Kicsit a hátrányokról és előnyökről.

Hátrányok

Rekordok nagyobb csomagokban való betöltése. Ez egyrészt egy funkció, de mindenképpen további komponenseket kell használni a rekordok pufferezéséhez. Ez a feladat nem mindig egyszerű, de mégis megoldható. Szeretném egyszerűsíteni a sémát.
Néhány egzotikus funkció vagy új jellemző gyakran megsérül az új verziókban. Ez aggodalmat kelt, csökkentve az új verzióra való frissítés iránti vágyat. Például a Kafka táblamotor – egy nagyon hasznos funkció, amely lehetővé teszi az események közvetlen olvasását a Kafkából, anélkül, hogy fogyasztókat kellene megvalósítani. De a GitHub-ra feltett problémák száma alapján egyelőre óvatosak vagyunk e motor használatával a termelésben. Azonban, ha nem teszünk hirtelen lépéseket, és használjuk az alapvető funkciót, akkor stabilan működik.

Előnyök

Nem lassul.
Alacsony belépési küszöb.
Nyílt forráskódú.
Ingyenes.
Jól skálázható (töredezés/replicálás "tartalmazva")
A MinComSzváz által ajánlott orosz szoftverek nyilvántartásába tartozik.
Hivatalos támogatás elérhetősége a Yandex-től.

Forrás: habr.com