ClickHouse მონაცემთა ბაზა ადამიანებისთვის, ან Alien Technologies

ალექსეი ლიზუნოვი, MKB-ს საინფორმაციო ტექნოლოგიების დირექტორატის დისტანციური მომსახურების არხების კომპეტენციის ცენტრის ხელმძღვანელი

როგორც ELK სტეკის ალტერნატივა (ElasticSearch, Logstash, Kibana), ჩვენ ვაკეთებთ კვლევას ClickHouse მონაცემთა ბაზის გამოყენებაზე, როგორც მონაცემების შესანახად ჟურნალებისთვის.

ამ სტატიაში გვინდა ვისაუბროთ ClickHouse მონაცემთა ბაზის გამოყენების ჩვენს გამოცდილებაზე და საპილოტე ოპერაციის წინასწარ შედეგებზე. დაუყოვნებლივ უნდა აღინიშნოს, რომ შედეგები შთამბეჭდავი იყო.

შემდეგი, ჩვენ უფრო დეტალურად აღვწერთ, თუ როგორ არის კონფიგურირებული ჩვენი სისტემა და რა კომპონენტებისგან შედგება. მაგრამ ახლა მსურს ცოტა ვისაუბრო ამ მონაცემთა ბაზის მთლიანობაზე და იმაზე, თუ რატომ ღირს ყურადღების მიქცევა. ClickHouse მონაცემთა ბაზა არის Yandex-ის მაღალი ხარისხის ანალიტიკური სვეტოვანი მონაცემთა ბაზა. ის გამოიყენება Yandex-ის სერვისებში, თავდაპირველად ის არის Yandex.Metrica-ს ძირითადი მონაცემთა საცავი. ღია კოდის სისტემა, უფასო. დეველოპერების თვალსაზრისით, მე ყოველთვის მაინტერესებდა როგორ განახორციელეს ეს, რადგან ფანტასტიკურად დიდი მონაცემებია. და თავად Metrica-ს მომხმარებლის ინტერფეისი ძალიან მოქნილი და სწრაფია. ამ მონაცემთა ბაზის პირველი გაცნობისას შთაბეჭდილება რჩება: „კარგი, ბოლოს და ბოლოს! შექმნილი ხალხისთვის! ინსტალაციის პროცესიდან დაწყებული და მოთხოვნების გაგზავნით დამთავრებული.

ამ მონაცემთა ბაზას აქვს ძალიან დაბალი შესვლის ბარიერი. საშუალო დონის დეველოპერსაც კი შეუძლია დააინსტალიროს ეს მონაცემთა ბაზა რამდენიმე წუთში და დაიწყოს მისი გამოყენება. ყველაფერი გარკვევით მუშაობს. იმ ადამიანებსაც კი, რომლებიც ახალია Linux-ში, შეუძლიათ სწრაფად გაუმკლავდნენ ინსტალაციას და შეასრულონ უმარტივესი ოპერაციები. თუ ადრე, სიტყვებით Big Data, Hadoop, Google BigTable, HDFS, ჩვეულებრივ დეველოპერს ჰქონდა წარმოდგენა, რომ ეს იყო რამდენიმე ტერაბაიტი, პეტაბაიტი, რომ ზოგიერთი ზეადამიანი დაკავებული იყო ამ სისტემების პარამეტრებში და განვითარებაში, მაშინ ClickHouse-ის მოსვლასთან ერთად. მონაცემთა ბაზაში, ჩვენ მივიღეთ მარტივი, გასაგები ინსტრუმენტი, რომლითაც შეგიძლიათ ამოხსნათ ადრე მიუწვდომელი ამოცანების სპექტრი. ინსტალაციას მხოლოდ ერთი საკმაოდ საშუალო მანქანა და ხუთი წუთი სჭირდება. ანუ, ჩვენ მივიღეთ ისეთი მონაცემთა ბაზა, როგორიცაა, მაგალითად, MySql, მაგრამ მხოლოდ მილიარდობით ჩანაწერის შესანახად! გარკვეული სუპერ-არქივერი SQL ენით. თითქოს ხალხს გადასცეს უცხოპლანეტელების იარაღი.

ჩვენი ხე-ტყის სისტემის შესახებ

ინფორმაციის შესაგროვებლად გამოიყენება სტანდარტული ფორმატის ვებ აპლიკაციების IIS ჟურნალის ფაილები (ამჟამად ჩვენ ასევე ვაანალიზებთ აპლიკაციების ჟურნალებს, მაგრამ საპილოტე ეტაპზე მთავარი მიზანია IIS ჟურნალების შეგროვება).

სხვადასხვა მიზეზის გამო, ჩვენ ვერ შევძელით ELK სტეკის სრულად მიტოვება და ვაგრძელებთ LogStash და Filebeat კომპონენტების გამოყენებას, რომლებმაც კარგად დაამტკიცა თავი და მუშაობს საკმაოდ საიმედოდ და პროგნოზირებად.

ჭრის ზოგადი სქემა ნაჩვენებია ქვემოთ მოცემულ ფიგურაში:

ClickHouse მონაცემთა ბაზაში მონაცემების ჩაწერის მახასიათებელია ჩანაწერების იშვიათად (წამში ერთხელ) ჩასმა დიდ პარტიებში. ეს, როგორც ჩანს, ყველაზე „პრობლემური“ ნაწილია, რომელსაც წააწყდებით, როდესაც პირველად განიცდით ClickHouse მონაცემთა ბაზასთან მუშაობას: სქემა ცოტა უფრო რთული ხდება.
LogStash-ის მოდული, რომელიც პირდაპირ ათავსებს მონაცემებს ClickHouse-ში, აქ ძალიან დაეხმარა. ეს კომპონენტი განლაგებულია იმავე სერვერზე, როგორც თავად მონაცემთა ბაზა. ასე რომ, ზოგადად რომ ვთქვათ, არ არის რეკომენდებული ამის გაკეთება, მაგრამ პრაქტიკული თვალსაზრისით, ისე, რომ არ შეიქმნას ცალკე სერვერები, როდესაც ის განლაგებულია იმავე სერვერზე. ჩვენ არ დაფიქსირებულა რაიმე წარუმატებლობა ან რესურსის კონფლიქტი მონაცემთა ბაზასთან. გარდა ამისა, უნდა აღინიშნოს, რომ დანამატს აქვს ხელახალი ცდის მექანიზმი შეცდომის შემთხვევაში. და შეცდომების შემთხვევაში, დანამატი წერს დისკზე მონაცემების პარტიას, რომლის ჩასმაც შეუძლებელია (ფაილის ფორმატი მოსახერხებელია: რედაქტირების შემდეგ, თქვენ შეგიძლიათ მარტივად ჩასვათ შესწორებული პარტია clickhouse-client-ის გამოყენებით).

სქემაში გამოყენებული პროგრამული უზრუნველყოფის სრული სია მოცემულია ცხრილში:

გამოყენებული პროგრამული უზრუნველყოფის სია

სახელი

აღწერა

სადისტრიბუციო ბმული

NGINX

საპირისპირო პროქსი პორტების წვდომის შეზღუდვისა და ავტორიზაციის ორგანიზებისთვის

ამჟამად არ გამოიყენება სქემაში

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

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

FileBeat

ფაილების ჟურნალების გადაცემა.

https://www.elastic.co/downloads/beats/filebeat (გამანაწილებელი ნაკრები Windows 64-ბიტისთვის).

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

logstash

ჟურნალის შემგროვებელი.

გამოიყენება ჟურნალების შესაგროვებლად FileBeat-დან, აგრეთვე ჟურნალების შესაგროვებლად RabbitMQ რიგიდან (სერვერებისთვის, რომლებიც DMZ-შია.)

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

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

Logstash-output-clickhouse

Loagstash მოდული, ჟურნალების ClickHouse მონაცემთა ბაზაში ჯგუფურად გადასატანად

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

ჟურნალის შენახვა 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

Შენიშვნა. 2018 წლის აგვისტოდან, Yandex-ის საცავში გამოჩნდა RHEL-ის „ნორმალური“ rpm-ის ნაგებობები, ასე რომ თქვენ შეგიძლიათ სცადოთ მათი გამოყენება. ინსტალაციის დროს ჩვენ ვიყენებდით Altinity-ის მიერ აშენებულ პაკეტებს.

გრაფანა

ჟურნალის ვიზუალიზაცია. დაფების დაყენება

https://grafana.com/

https://grafana.com/grafana/download

Redhat & Centos (64 ბიტი) - უახლესი ვერსია

ClickHouse მონაცემთა წყარო Grafana 4.6+-ისთვის

მოდული Grafana-სთვის ClickHouse მონაცემთა წყაროთი

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

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

logstash

ჩაწერეთ როუტერი FileBeat-დან RabbitMQ რიგში.

Შენიშვნა. სამწუხაროდ, FileBeat-ს არ აქვს გამომავალი პირდაპირ RabbitMQ, ამიტომ საჭიროა შუალედური ბმული Logstash-ის სახით

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

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

კურდღელი MQ

შეტყობინების რიგი. ეს არის ჟურნალის ბუფერი 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 (აუცილებელია RabbitMQ)

გაშვების დრო. საჭიროა RabbitMQ მუშაობისთვის

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

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

სერვერის კონფიგურაცია ClickHouse მონაცემთა ბაზაში წარმოდგენილია შემდეგ ცხრილში:

სახელი

ღირებულება

შენიშვნა

კონფიგურაცია

HDD: 40 გბ
ოპერატიული მეხსიერება: 8GB
პროცესორი: Core 2 2Ghz

აუცილებელია ყურადღება მიაქციოთ ClickHouse მონაცემთა ბაზის მუშაობის რჩევებს (https://clickhouse.yandex/docs/ru/operations/tips/)

ზოგადი სისტემის პროგრამული უზრუნველყოფა

ოპერაციული სისტემა: Red Hat Enterprise Linux სერვერი (Maipo)

JRE (Java 8)

 

როგორც ხედავთ, ეს არის ჩვეულებრივი სამუშაო სადგური.

მორების შესანახი ცხრილის სტრუქტურა ასეთია:

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;

ჩვენ ვიყენებთ ნაგულისხმევ დაყოფას (თვეში) და ინდექსის გრანულარობას. ყველა ველი პრაქტიკულად შეესაბამება IIS ჟურნალის ჩანაწერებს http მოთხოვნების შესვლისთვის. ცალკე აღვნიშნავთ, რომ არსებობს ცალკეული ველები utm-ტეგების შესანახად (ისინი ანალიზდება ცხრილში ჩასმის ეტაპზე შეკითხვის სტრიქონის ველიდან).

ასევე, ცხრილს დაემატა რამდენიმე სისტემის ველი სისტემების, კომპონენტების, სერვერების შესახებ ინფორმაციის შესანახად. იხილეთ ქვემოთ მოცემული ცხრილი ამ ველების აღწერისთვის. ერთ ცხრილში ჩვენ ვინახავთ ჟურნალებს რამდენიმე სისტემისთვის.

სახელი

აღწერა

მაგალითი

fld_app_name

აპლიკაციის/სისტემის სახელი
მოქმედი მნიშვნელობები:

• site1.domain.com გარე საიტი 1
• site2.domain.com გარე საიტი 2
• interior-site1.domain.local შიდა საიტი 1

site1.domain.com

fld_app_module

სისტემის მოდული
მოქმედი მნიშვნელობები:

• ვებ – საიტი
• svc - ვებ საიტის სერვისი
• intgr - ინტეგრაციის ვებ სერვისი
• bo - ადმინისტრატორი (BackOffice)

ვებ

fld_website_name

საიტის სახელი IIS-ში

რამდენიმე სისტემა შეიძლება განთავსდეს ერთ სერვერზე, ან თუნდაც ერთი სისტემის მოდულის რამდენიმე მაგალითი

ვებ მთავარი

fld_server_name

Სერვერის სახელი

web1.domain.com

fld_log_file_name

გზა სერვერზე ჟურნალის ფაილისკენ

C:inetpublogsLogFiles
W3SVC1u_ex190711.log

ეს საშუალებას გაძლევთ ეფექტურად შექმნათ გრაფიკები Grafana-ში. მაგალითად, ნახეთ მოთხოვნები კონკრეტული სისტემის წინა ნაწილიდან. ეს ჰგავს საიტის მრიცხველს Yandex.Metrica-ში.

აქ მოცემულია რამდენიმე სტატისტიკა მონაცემთა ბაზის გამოყენების შესახებ ორი თვის განმავლობაში.

სისტემების და მათი კომპონენტების მიხედვით დაყოფილი ჩანაწერების რაოდენობა

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

დისკზე არსებული მონაცემების რაოდენობა

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.

მონაცემთა შეკუმშვის ხარისხი სვეტებში

SELECT
    name,
    formatReadableSize(data_uncompressed_bytes) AS uncompressed,
    formatReadableSize(data_compressed_bytes) AS compressed,
    data_uncompressed_bytes / data_compressed_bytes AS compress_ratio
FROM system.columns
WHERE table = 'log_web'
 
┌─name───────────────────┬─uncompressed─┬─compressed─┬─────compress_ratio─┐
│ 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 rows in set. Elapsed: 0.005 sec.

გამოყენებული კომპონენტების აღწერა

FileBeat. ფაილების ჟურნალების გადატანა

ეს კომპონენტი თვალყურს ადევნებს დისკზე ჟურნალის ფაილების ცვლილებებს და ინფორმაციას გადასცემს LogStash-ს. დაინსტალირებულია ყველა სერვერზე, სადაც იწერება ჟურნალის ფაილები (ჩვეულებრივ IIS). მუშაობს კუდის რეჟიმში (ანუ გადასცემს მხოლოდ დამატებულ ჩანაწერებს ფაილში). მაგრამ ცალკე, მისი კონფიგურაცია შესაძლებელია მთელი ფაილების გადასატანად. ეს სასარგებლოა, როდესაც გჭირდებათ წინა თვეების მონაცემების ჩამოტვირთვა. უბრალოდ ჩადეთ ჟურნალის ფაილი საქაღალდეში და ის წაიკითხავს მას მთლიანად.

როდესაც სერვისი შეჩერებულია, მონაცემები აღარ გადადის საცავში.

კონფიგურაციის მაგალითი ასე გამოიყურება:

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. ჟურნალის კოლექტორი

ეს კომპონენტი შექმნილია იმისთვის, რომ მიიღოს ჟურნალის ჩანაწერები FileBeat-დან (ან RabbitMQ რიგის მეშვეობით), აანალიზოს და ჩასვას პარტიები ClickHouse მონაცემთა ბაზაში.

ClickHouse-ში ჩასართავად გამოიყენება Logstash-output-clickhouse მოდული. Logstash მოდულს აქვს მოთხოვნის განმეორებითი ცდის მექანიზმი, მაგრამ რეგულარული გამორთვით, უმჯობესია თავად შეწყვიტოთ სერვისი. როდესაც შეჩერდება, შეტყობინებები დაგროვდება RabbitMQ რიგში, ასე რომ, თუ გაჩერება დიდი ხნის განმავლობაშია, მაშინ უმჯობესია შეაჩეროთ Filebeats სერვერებზე. სქემაში, სადაც RabbitMQ არ გამოიყენება (ლოკალურ ქსელში, Filebeat პირდაპირ აგზავნის ჟურნალებს Logstash-ში), Filebeats მუშაობს საკმაოდ მისაღები და უსაფრთხოდ, ამიტომ მათთვის გამომავალი მიუწვდომლობა გადის შედეგების გარეშე.

კონფიგურაციის მაგალითი ასე გამოიყურება:

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"
        }
    }
 
}

მილსადენები.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. ჟურნალის შენახვა

ყველა სისტემის ჟურნალი ინახება ერთ ცხრილში (იხილეთ სტატიის დასაწყისში). ის განკუთვნილია მოთხოვნის შესახებ ინფორმაციის შესანახად: ყველა პარამეტრი მსგავსია სხვადასხვა ფორმატებისთვის, როგორიცაა IIS ჟურნალები, apache და nginx ჟურნალები. განაცხადის ჟურნალებისთვის, რომლებშიც, მაგალითად, ჩაწერილია შეცდომები, საინფორმაციო შეტყობინებები, გაფრთხილებები, ცალკე ცხრილი იქნება მოწოდებული შესაბამისი სტრუქტურით (ამჟამად დიზაინის ეტაპზეა).

ცხრილის შექმნისას ძალიან მნიშვნელოვანია გადაწყვიტოთ პირველადი გასაღები (რომლითაც მოხდება მონაცემების დახარისხება შენახვისას). მონაცემთა შეკუმშვის ხარისხი და შეკითხვის სიჩქარე ამაზეა დამოკიდებული. ჩვენს მაგალითში მთავარია
შეკვეთა (fld_app_name, fld_app_module, logdatetime)
ანუ სისტემის სახელით, სისტემის კომპონენტის სახელით და მოვლენის თარიღით. თავდაპირველად, ღონისძიების თარიღი პირველი იყო. ბოლო ადგილზე გადატანის შემდეგ, შეკითხვებმა დაიწყო მუშაობა დაახლოებით ორჯერ უფრო სწრაფად. პირველადი გასაღების შეცვლა საჭიროებს ცხრილის ხელახლა შექმნას და მონაცემების ხელახლა ჩატვირთვას, რათა ClickHouse-მა ხელახლა დაახარისხოს მონაცემები დისკზე. ეს მძიმე ოპერაციაა, ამიტომ კარგი იდეაა ბევრი იფიქროთ იმაზე, თუ რა უნდა იყოს შეტანილი დალაგების კლავიშში.

ასევე უნდა აღინიშნოს, რომ LowCardinality მონაცემთა ტიპი გამოჩნდა შედარებით უახლეს ვერსიებში. მისი გამოყენებისას, შეკუმშული მონაცემების ზომა მკვეთრად მცირდება იმ ველებისთვის, რომლებსაც აქვთ დაბალი კარდინალურობა (რამდენიმე ვარიანტი).

ვერსია 19.6 ამჟამად გამოიყენება და ჩვენ ვგეგმავთ სცადოთ განახლება უახლეს ვერსიაზე. მათ აქვთ ისეთი მშვენიერი ფუნქციები, როგორიცაა ადაპტური გრანულარობა, გამოტოვების ინდექსები და DoubleDelta კოდეკი, მაგალითად.

ნაგულისხმევად, ინსტალაციის დროს, ჟურნალის დონე დაყენებულია კვალზე. ჟურნალები ბრუნავს და დაარქივებულია, მაგრამ ამავე დროს ისინი აფართოებენ გიგაბაიტამდე. თუ არ არის საჭირო, მაშინ შეგიძლიათ დააყენოთ გაფრთხილების დონე, მაშინ ჟურნალის ზომა მკვეთრად შემცირდება. ჟურნალის პარამეტრი დაყენებულია config.xml ფაილში:

<!-- Possible levels: https://github.com/pocoproject/poco/blob/develop/Foundation/include/Poco/Logger. h#L105 -->
<level>warning</level>

რამდენიმე სასარგებლო ბრძანება

Поскольку оригинальные пакеты установки собираются по Debian, то для других версий Linux необходимо использовать пакеты собранные компанией Altinity.
 
Вот по этой ссылке есть инструкции с ссылками на их репозиторий: https://www.altinity.com/blog/2017/12/18/logstash-with-clickhouse
sudo yum search clickhouse-server
sudo yum install clickhouse-server.noarch
  
1. проверка статуса
sudo systemctl status clickhouse-server
 
2. остановка сервера
sudo systemctl stop clickhouse-server
 
3. запуск сервера
sudo systemctl start clickhouse-server
 
Запуск для выполнения запросов в многострочном режиме (выполнение после знака ";")
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
 
Плагин кликлауза для логстеш в случае ошибки в одной строке сохраняет всю пачку в файл /tmp/log_web_failed.json
Можно вручную исправить этот файл и попробовать залить его в БД вручную:
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
 
выход из командной строки
quit;
## Настройка TLS
https://www.altinity.com/blog/2019/3/5/clickhouse-networking-part-2
 
openssl s_client -connect log.domain.com:9440 < /dev/null

logstash. ჩაწერეთ როუტერი FileBeat-დან RabbitMQ რიგში

ეს კომპონენტი გამოიყენება FileBeat-დან RabbitMQ რიგში მოსულ ჟურნალების გადასატანად. აქ არის ორი წერტილი:

1. სამწუხაროდ, FileBeat-ს არ აქვს გამომავალი მოდული, რომელიც პირდაპირ RabbitMQ-ზე დასაწერად. და ასეთი ფუნქციონირება, მათი github-ის საკითხის მიხედვით, არ არის დაგეგმილი განხორციელებისთვის. არის კაფკას დანამატი, მაგრამ რატომღაც მას სახლში ვერ ვიყენებთ.
2. DMZ-ში მორების შეგროვების მოთხოვნები არსებობს. მათზე დაყრდნობით, ჟურნალები ჯერ უნდა დაემატოს რიგში და შემდეგ LogStash კითხულობს ჩანაწერებს რიგიდან გარედან.

ამიტომ, იმ შემთხვევისთვის, როდესაც სერვერები განლაგებულია DMZ-ში, უნდა გამოიყენოთ ასეთი ოდნავ რთული სქემა. კონფიგურაციის მაგალითი ასე გამოიყურება:

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. შეტყობინების რიგი

ეს კომპონენტი გამოიყენება ბუფერული ჩანაწერების DMZ-ში. ჩაწერა ხდება Filebeat → LogStash-ის მეშვეობით. კითხვა ხდება DMZ-ის გარედან LogStash-ის საშუალებით. RabboitMQ-ის საშუალებით მუშაობისას მუშავდება დაახლოებით 4 ათასი შეტყობინება წამში.

შეტყობინებების მარშრუტი კონფიგურებულია სისტემის სახელით, ანუ FileBeat-ის კონფიგურაციის მონაცემებზე დაყრდნობით. ყველა შეტყობინება მიდის ერთ რიგში. თუ რაიმე მიზეზით შეჩერებულია რიგის სერვისი, მაშინ ეს არ გამოიწვევს შეტყობინებების დაკარგვას: FileBeats მიიღებს შეცდომებს კავშირის შესახებ და დროებით შეაჩერებს გაგზავნას. და LogStash, რომელიც კითხულობს რიგიდან, ასევე მიიღებს ქსელის შეცდომებს და დაელოდება კავშირის აღდგენას. ამ შემთხვევაში, მონაცემები, რა თქმა უნდა, აღარ ჩაიწერება მონაცემთა ბაზაში.

შემდეგი ინსტრუქციები გამოიყენება რიგების შესაქმნელად და კონფიგურაციისთვის:

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"

გრაფანა. დაფები

ეს კომპონენტი გამოიყენება მონიტორინგის მონაცემების ვიზუალიზაციისთვის. ამ შემთხვევაში, თქვენ უნდა დააინსტალიროთ ClickHouse მონაცემთა წყარო Grafana 4.6+ მოდულისთვის. ჩვენ ცოტა შეგვეხვეწა, რათა გაუმჯობესებულიყო SQL ფილტრების დამუშავების ეფექტურობა დაფაზე.

მაგალითად, ჩვენ ვიყენებთ ცვლადებს და თუ ისინი არ არის მითითებული ფილტრის ველში, მაშინ გვსურს, რომ არ წარმოქმნას პირობა ფორმის WHERE-ში ( uriStem = » AND uriStem != » ). ამ შემთხვევაში, ClickHouse წაიკითხავს uriStem სვეტს. ზოგადად, ჩვენ ვცადეთ სხვადასხვა ვარიანტები და საბოლოოდ ჩავასწორეთ დანამატი ($valueIfEmpty მაკრო) ისე, რომ ცარიელი მნიშვნელობის შემთხვევაში ის აბრუნებს 1-ს, თავად სვეტის ხსენების გარეშე.

ახლა კი შეგიძლიათ გამოიყენოთ ეს მოთხოვნა გრაფიკისთვის

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

რაც ითარგმნება ამ SQL-ზე (გაითვალისწინეთ, რომ ცარიელი uriStem ველები გადაკეთდა მხოლოდ 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

დასკვნა

ClickHouse მონაცემთა ბაზის გამოჩენა გახდა საეტაპო მოვლენა ბაზარზე. ძნელი წარმოსადგენია, რომ სრულიად უფასოდ, მყისიერად შევიარაღდით დიდ მონაცემებთან მუშაობის მძლავრი და პრაქტიკული ხელსაწყოთი. რა თქმა უნდა, მზარდი საჭიროებებით (მაგალითად, გაფანტვა და მრავალ სერვერზე რეპლიკაცია), სქემა უფრო გართულდება. მაგრამ პირველი შთაბეჭდილებებით, ამ მონაცემთა ბაზასთან მუშაობა ძალიან სასიამოვნოა. ჩანს, რომ პროდუქტი დამზადებულია "ხალხისთვის".

ElasticSearch-თან შედარებით, ჟურნალების შენახვისა და დამუშავების ღირებულება სავარაუდოდ შემცირდება ხუთ-ათჯერ. სხვა სიტყვებით რომ ვთქვათ, თუ მონაცემთა ამჟამინდელი მოცულობისთვის მოგვიწევს რამდენიმე აპარატის კლასტერის დაყენება, მაშინ ClickHouse-ის გამოყენებისას ჩვენთვის საკმარისია ერთი დაბალი სიმძლავრის მანქანა. დიახ, რა თქმა უნდა, ElasticSearch-ს ასევე აქვს დისკზე მონაცემთა შეკუმშვის მექანიზმები და სხვა ფუნქციები, რომლებსაც შეუძლიათ მნიშვნელოვნად შეამცირონ რესურსების მოხმარება, მაგრამ ClickHouse-თან შედარებით, ეს უფრო ძვირი იქნება.

ჩვენი მხრიდან რაიმე განსაკუთრებული ოპტიმიზაციის გარეშე, ნაგულისხმევ პარამეტრებზე, მონაცემების ჩატვირთვა და მონაცემთა ბაზიდან შერჩევა საოცარი სისწრაფით მუშაობს. ჯერ ბევრი მონაცემი არ გვაქვს (დაახლოებით 200 მილიონი ჩანაწერი), მაგრამ თავად სერვერი სუსტია. ჩვენ შეგვიძლია გამოვიყენოთ ეს ინსტრუმენტი მომავალში სხვა მიზნებისთვის, რომლებიც არ არის დაკავშირებული ჟურნალების შენახვასთან. მაგალითად, ბოლოდან ბოლომდე ანალიტიკისთვის, უსაფრთხოების სფეროში, მანქანათმცოდნეობის სფეროში.

დასასრულს, ცოტათი დადებითი და უარყოფითი მხარეების შესახებ.

Cons

1. ჩანაწერების ჩატვირთვა დიდ პარტიებში. ერთის მხრივ, ეს არის ფუნქცია, მაგრამ თქვენ მაინც უნდა გამოიყენოთ დამატებითი კომპონენტები ბუფერული ჩანაწერებისთვის. ეს ამოცანა ყოველთვის არ არის ადვილი, მაგრამ მაინც გადაჭრადი. და მე მინდა გავამარტივოთ სქემა.
2. ზოგიერთი ეგზოტიკური ფუნქცია ან ახალი ფუნქცია ხშირად იშლება ახალ ვერსიებში. ეს იწვევს შეშფოთებას, ამცირებს ახალ ვერსიაზე განახლების სურვილს. მაგალითად, კაფკას მაგიდის ძრავა არის ძალიან სასარგებლო ფუნქცია, რომელიც საშუალებას გაძლევთ პირდაპირ წაიკითხოთ მოვლენები კაფკადან, მომხმარებლების განხორციელების გარეშე. მაგრამ თუ ვიმსჯელებთ github-ზე არსებული საკითხების რაოდენობის მიხედვით, ჩვენ მაინც ფრთხილად ვართ, რომ არ გამოვიყენოთ ეს ძრავა წარმოებაში. თუმცა, თუ თქვენ არ გააკეთებთ მოულოდნელ ჟესტებს გვერდით და არ იყენებთ ძირითად ფუნქციონირებას, მაშინ ის სტაბილურად მუშაობს.

დადებითი

1. არ ანელებს.
2. დაბალი შესვლის ბარიერი.
3. Საჯარო წყარო.
4. უფასო.
5. კარგად მასშტაბირებს (განაწილება/გამეორება ყუთიდან)
6. შედის კავშირგაბმულობის სამინისტროს მიერ რეკომენდებული რუსული პროგრამული უზრუნველყოფის რეესტრში.
7. Yandex-ის ოფიციალური მხარდაჭერის არსებობა.

წყარო: www.habr.com