Invio dei log json di Nginx tramite Vector a Clickhouse ed Elasticsearch

Invio dei log json di Nginx tramite Vector a Clickhouse ed Elasticsearch

Vector, destinata alla raccolta, trasformazione e invio di dati di log, metriche ed eventi.

β†’Β Github

Scritta in Rust, Γ¨ caratterizzata da alte prestazioni e da un basso consumo di memoria rispetto ai concorrenti. Inoltre, grande attenzione Γ¨ dedicata alle funzionalitΓ  legate alla correttezza, in particolare alla possibilitΓ  di salvare eventi non inviati in un buffer su disco e alla rotazione dei file.

Architettonicamente, Vector Γ¨ un router di eventi che riceve messaggi da uno o piΓΉ fonti, applicando facoltativamente delle trasformazioni, e li invia a uno o piΓΉ sink.

Vector Γ¨ un sostituto di filebeat e logstash, puΓ² svolgere entrambi i ruoli (ricevere e inviare log), maggiori dettagli nella loro sito.

Se in Logstash la catena Γ¨ costruita come input β†’ filter β†’ output, in Vector Γ¨ sources β†’ transforms β†’ sinks

Esempi possono essere consultati nella documentazione.

Questa istruzione Γ¨ una rielaborazione dell'istruzione di Vyacheslav Rakhinskiy. Nelle istruzioni originali Γ¨ prevista la gestione di geoip. Durante i miei test con geoip dalla rete interna, vector ha restituito un errore.

Aug 05 06:25:31.889 DEBUG transform{name=nginx_parse_rename_fields type=rename_fields}: vector::transforms::rename_fields: Field non esisteva field=Β«geoip.country_nameΒ» rate_limit_secs=30

Se qualcuno ha bisogno di gestire geoip, puΓ² fare riferimento alle istruzioni originali di Vyacheslav Rakhinskiy.

Configureremo la combinazione Nginx (Access logs) β†’ Vector (Client | Filebeat) β†’ Vector (Server | Logstash) β†’ separatamente in Clickhouse e separatamente in Elasticsearch. Installeremo 4 server. Anche se Γ¨ possibile farlo con 3 server.

Invio dei log json di Nginx tramite Vector a Clickhouse ed Elasticsearch

Lo schema è più o meno così.

Disattiviamo Selinux su tutti i vostri server

sed -i 's\/^SELINUX=.*\/SELINUX=disabled\/g' \/etc\/selinux\/config\nreboot

Installiamo un emulatore di server HTTP + utility su tutti i server

Utilizzeremo come emulatore di server HTTP nodejs-stub-server di Maxim Ignatenko

Nodejs-stub-server non ha rpm. Qui creiamo un rpm. Il rpm verrΓ  creato utilizzando Fedora Copr

Aggiungiamo il repository antonpatsev\/nodejs-stub-server

yum -y install yum-plugin-copr epel-release\nyes | yum copr enable antonpatsev\/nodejs-stub-server

Installiamo nodejs-stub-server, Apache benchmark e il multiplexer terminale screen su tutti i server

yum -y install stub_http_server screen mc httpd-tools screen

Ho corretto nel file \/var\/lib\/stub_http_server\/stub_http_server.js il tempo di risposta di stub_http_server per avere piΓΉ log.

var max_sleep = 10;

Avviamo stub_http_server.

systemctl start stub_http_server\nsystemctl enable stub_http_server

Installazione di Clickhouse sul 3Β° server

ClickHouse utilizza un insieme di istruzioni SSE 4.2, pertanto, se non diversamente specificato, il supporto nel processore utilizzato diventa un requisito aggiuntivo per il sistema. Ecco il comando per verificare se il processore attuale supporta SSE 4.2:

grep -q sse4_2 \/proc\/cpuinfo && echo "SSE 4.2 supported" || echo "SSE 4.2 not supported"

Per prima cosa, Γ¨ necessario collegare il repository ufficiale:

sudo yum install -y yum-utils\nsudo rpm --import https:\/\/repo.clickhouse.tech\/CLICKHOUSE-KEY.GPG\nsudo yum-config-manager --add-repo https:\/\/repo.clickhouse.tech\/rpm\/stable\/x86_64

Per installare i pacchetti Γ¨ necessario eseguire i seguenti comandi:

sudo yum install -y clickhouse-server clickhouse-client

Permettiamo a clickhouse-server di ascoltare la scheda di rete nel file \/etc\/clickhouse-server\/config.xml

0.0.0.0

Modifichiamo il livello di logging da trace a debug

debug

Le impostazioni di compressione sono standard:

min_compress_block_size  65536\nmax_compress_block_size  1048576

Per attivare la compressione Zstd, si consiglia di non modificare la configurazione, ma di utilizzare meglio DDL.

Invio dei log json di Nginx tramite Vector a Clickhouse ed Elasticsearch

Non ho trovato come applicare la compressione zstd tramite DDL su Google. Quindi l'ho lasciato così com'è.

Colleghi, chi utilizza la compressione zstd in Clickhouseβ€”per favore, condividete le istruzioni.

Per avviare il server come demone, eseguire:

service clickhouse-server start

Ora passiamo alla configurazione di Clickhouse

Accediamo a Clickhouse

clickhouse-client -h 172.26.10.109 -m

172.26.10.109β€”IP del server dove Γ¨ installato Clickhouse.

Creiamo il database vector

CREATE DATABASE vector;

Verifichiamo che il database esista.

show databases;

Creiamo la tabella vector.logs.

/* Π­Ρ‚ΠΎ Ρ‚Π°Π±Π»ΠΈΡ†Π° Π³Π΄Π΅ хранятся Π»ΠΎΠ³ΠΈ ΠΊΠ°ΠΊ Π΅ΡΡ‚ΡŒ */

CREATE TABLE vector.logs
(
    `node_name` String,
    `timestamp` DateTime,
    `server_name` String,
    `user_id` String,
    `request_full` String,
    `request_user_agent` String,
    `request_http_host` String,
    `request_uri` String,
    `request_scheme` String,
    `request_method` String,
    `request_length` UInt64,
    `request_time` Float32,
    `request_referrer` String,
    `response_status` UInt16,
    `response_body_bytes_sent` UInt64,
    `response_content_type` String,
    `remote_addr` IPv4,
    `remote_port` UInt32,
    `remote_user` String,
    `upstream_addr` IPv4,
    `upstream_port` UInt32,
    `upstream_bytes_received` UInt64,
    `upstream_bytes_sent` UInt64,
    `upstream_cache_status` String,
    `upstream_connect_time` Float32,
    `upstream_header_time` Float32,
    `upstream_response_length` UInt64,
    `upstream_response_time` Float32,
    `upstream_status` UInt16,
    `upstream_content_type` String,
    INDEX idx_http_host request_http_host TYPE set(0) GRANULARITY 1
)
ENGINE = MergeTree()
PARTITION BY toYYYYMMDD(timestamp)
ORDER BY timestamp
TTL timestamp + toIntervalMonth(1)
SETTINGS index_granularity = 8192;

Verifichiamo che le tabelle siano state create. Avviamo clickhouse-client e facciamo una richiesta.

Passiamo al database vector.

use vector;

Ok.

0 righe nel set. Tempo trascorso: 0.001 sec.

Controlliamo le tabelle.

show tables;

β”Œβ”€name────────────────┐
β”‚ logs                β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Installazione di Elasticsearch sul quarto server per inviare gli stessi dati a Elasticsearch per il confronto con Clickhouse

Aggiungiamo la chiave rpm pubblica

rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch

Creiamo 2 repository:

/etc/yum.repos.d/elasticsearch.repo

[elasticsearch]
name=Elasticsearch repository for 7.x packages
baseurl=https://artifacts.elastic.co/packages/7.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=0
autorefresh=1
type=rpm-md

/etc/yum.repos.d/kibana.repo

[kibana-7.x]
name=Kibana repository for 7.x packages
baseurl=https://artifacts.elastic.co/packages/7.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md

Installeremo Elasticsearch e Kibana

yum install -y kibana elasticsearch

PoichΓ© sarΓ  in un'istanza, Γ¨ necessario aggiungere al file /etc/elasticsearch/elasticsearch.yml:

discovery.type: single-node

Per consentire a vector di inviare dati a Elasticsearch da un altro server, modifichiamo network.host.

network.host: 0.0.0.0

Per connettersi a Kibana, modifichiamo il parametro server.host nel file /etc/kibana/kibana.yml

server.host: "0.0.0.0"

Avviamo e abilitiamo l'avvio automatico di Elasticsearch

systemctl enable elasticsearch
systemctl start elasticsearch

e Kibana

systemctl enable kibana
systemctl start kibana

Configurazione di Elasticsearch per la modalitΓ  single-node 1 shard, 0 replica. Probabilmente avrete un cluster di un gran numero di server e non sarΓ  necessario farlo.

Per futuri indici, aggiorniamo il modello predefinito:

curl -X PUT http://localhost:9200/_template/default -H 'Content-Type: application/json' -d '{"index_patterns": ["*"],"order": -1,"settings": {"number_of_shards": "1","number_of_replicas": "0"}}' 

Installazione Vector come sostituto di Logstash su 2 server

yum install -y https://packages.timber.io/vector/0.9.X/vector-x86_64.rpm mc httpd-tools screen

Configuriamo Vector come sostituto di Logstash. Modifichiamo il file /etc/vector/vector.toml

# /etc/vector/vector.toml

data_dir = "/var/lib/vector"

[sources.nginx_input_vector]
  # General
  type                          = "vector"
  address                       = "0.0.0.0:9876"
  shutdown_timeout_secs         = 30

[transforms.nginx_parse_json]
  inputs                        = [ "nginx_input_vector" ]
  type                          = "json_parser"

[transforms.nginx_parse_add_defaults]
  inputs                        = [ "nginx_parse_json" ]
  type                          = "lua"
  version                       = "2"

  hooks.process = """
  function (event, emit)

    function split_first(s, delimiter)
      result = {};
      for match in (s..delimiter):gmatch("(.-)"..delimiter) do
          table.insert(result, match);
      end
      return result[1];
    end

    function split_last(s, delimiter)
      result = {};
      for match in (s..delimiter):gmatch("(.-)"..delimiter) do
          table.insert(result, match);
      end
      return result[#result];
    end

    event.log.upstream_addr             = split_first(split_last(event.log.upstream_addr, ', '), ':')
    event.log.upstream_bytes_received   = split_last(event.log.upstream_bytes_received, ', ')
    event.log.upstream_bytes_sent       = split_last(event.log.upstream_bytes_sent, ', ')
    event.log.upstream_connect_time     = split_last(event.log.upstream_connect_time, ', ')
    event.log.upstream_header_time      = split_last(event.log.upstream_header_time, ', ')
    event.log.upstream_response_length  = split_last(event.log.upstream_response_length, ', ')
    event.log.upstream_response_time    = split_last(event.log.upstream_response_time, ', ')
    event.log.upstream_status           = split_last(event.log.upstream_status, ', ')

    if event.log.upstream_addr == "" then
        event.log.upstream_addr = "127.0.0.1"
    end

    if (event.log.upstream_bytes_received == "-" or event.log.upstream_bytes_received == "") then
        event.log.upstream_bytes_received = "0"
    end

    if (event.log.upstream_bytes_sent == "-" or event.log.upstream_bytes_sent == "") then
        event.log.upstream_bytes_sent = "0"
    end

    if event.log.upstream_cache_status == "" then
        event.log.upstream_cache_status = "DISABLED"
    end

    if (event.log.upstream_connect_time == "-" or event.log.upstream_connect_time == "") then
        event.log.upstream_connect_time = "0"
    end

    if (event.log.upstream_header_time == "-" or event.log.upstream_header_time == "") then
        event.log.upstream_header_time = "0"
    end

    if (event.log.upstream_response_length == "-" or event.log.upstream_response_length == "") then
        event.log.upstream_response_length = "0"
    end

    if (event.log.upstream_response_time == "-" or event.log.upstream_response_time == "") then
        event.log.upstream_response_time = "0"
    end

    if (event.log.upstream_status == "-" or event.log.upstream_status == "") then
        event.log.upstream_status = "0"
    end

    emit(event)

  end
  """

[transforms.nginx_parse_remove_fields]
    inputs                              = [ "nginx_parse_add_defaults" ]
    type                                = "remove_fields"
    fields                              = ["data", "file", "host", "source_type"]

[transforms.nginx_parse_coercer]

    type                                = "coercer"
    inputs                              = ["nginx_parse_remove_fields"]

    types.request_length = "int"
    types.request_time = "float"

    types.response_status = "int"
    types.response_body_bytes_sent = "int"

    types.remote_port = "int"

    types.upstream_bytes_received = "int"
    types.upstream_bytes_send = "int"
    types.upstream_connect_time = "float"
    types.upstream_header_time = "float"
    types.upstream_response_length = "int"
    types.upstream_response_time = "float"
    types.upstream_status = "int"

    types.timestamp = "timestamp"

[sinks.nginx_output_clickhouse]
    inputs   = ["nginx_parse_coercer"]
    type     = "clickhouse"

    database = "vector"
    healthcheck = true
    host = "http://172.26.10.109:8123" #  АдрСс Clickhouse
    table = "logs"

    encoding.timestamp_format = "unix"

    buffer.type = "disk"
    buffer.max_size = 104900000
    buffer.when_full = "block"

    request.in_flight_limit = 20

[sinks.elasticsearch]
    type = "elasticsearch"
    inputs   = ["nginx_parse_coercer"]
    compression = "none"
    healthcheck = true
    # 172.26.10.116 - сСрвСр Π³Π΄Π΅ установСн elasticsearch
    host = "http://172.26.10.116:9200" 
    index = "vector-%Y-%m-%d"

È possibile correggere la sezione transforms.nginx_parse_add_defaults.

Poiché Vyacheslav Rakhinsky utilizza queste configurazioni per un piccolo CDN e lì in upstream_* possono arrivare diversi valori

Ad esempio:

"upstream_addr": "128.66.0.10:443, 128.66.0.11:443, 128.66.0.12:443"
"upstream_bytes_received": "-, -, 123"
"upstream_status": "502, 502, 200"

Se questa non Γ¨ la tua situazione, puoi semplificare questa sezione

Creiamo la configurazione del servizio per systemd /etc/systemd/system/vector.service

# /etc/systemd/system/vector.service

[Unit]
Description=Vector
After=network-online.target
Requires=network-online.target

[Service]
User=vector
Group=vector
ExecStart=/usr/bin/vector
ExecReload=/bin/kill -HUP $MAINPID
Restart=no
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=vector

[Install]
WantedBy=multi-user.target

Dopo aver creato le tabelle, puoi avviare Vector

systemctl enable vector
systemctl start vector

Puoi visualizzare i log di vector in questo modo

journalctl -f -u vector

Nei log devono esserci queste voci

INFO vector::topology::builder: Healthcheck: Passed.
INFO vector::topology::builder: Healthcheck: Passed.

Sul client (Web server) β€” Primo server

Sul server con nginx Γ¨ necessario disattivare ipv6, poichΓ© nella tabella logs in clickhouse viene utilizzato il campo upstream_addr IPv4, dato che non utilizzo ipv6 all'interno della rete. Se non disattivi ipv6, ci saranno errori:

DB::Exception: Valore IPv4 non valido.: (mentre si legge il valore della chiave upstream_addr)

Forse i lettori, dovrebbero aggiungere supporto per ipv6.

Creiamo il file /etc/sysctl.d/98-disable-ipv6.conf

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Applichiamo le impostazioni

sysctl --system

Installiamo nginx.

Ho aggiunto il file di repository nginx /etc/yum.repos.d/nginx.repo

[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true

Installiamo il pacchetto nginx

yum install -y nginx

Per iniziare, dobbiamo configurare il formato dei log in Nginx nel file /etc/nginx/nginx.conf

utente  nginx;
# devi impostare i processi di lavoro in base ai tuoi core CPU, nginx non beneficia dall'impostare piΓΉ di questo
worker_processes auto; # alcune ultime versioni lo calcolano automaticamente

# numero di descrittori di file utilizzati per nginx
# il limite per il numero massimo di FD sul server Γ¨ solitamente impostato dal sistema operativo.
# se non imposti FD, verranno utilizzate le impostazioni del sistema operativo che di default sono 2000
worker_rlimit_nofile 100000;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

# fornisce il contesto del file di configurazione in cui sono specificate le direttive che influenzano l'elaborazione delle connessioni.
events {
    # determina quanti clienti verranno serviti per ogni worker
    # max clients = worker_connections * worker_processes
    # i clienti massimi sono anche limitati dal numero di connessioni socket disponibili sul sistema (~64k)
    worker_connections 4000;

    # ottimizzato per servire molti clienti con ogni thread, essenziale per linux -- per ambiente di test
    use epoll;

    # accetta quante piΓΉ connessioni possibile, potrebbe inondare le connessioni worker se impostato troppo basso -- per ambiente di test
    multi_accept on;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

log_format vector escape=json
    '{'
        '"node_name":"nginx-vector",'
        '"timestamp":"$time_iso8601",'
        '"server_name":"$server_name",'
        '"request_full": "$request",'
        '"request_user_agent":"$http_user_agent",'
        '"request_http_host":"$http_host",'
        '"request_uri":"$request_uri",'
        '"request_scheme": "$scheme",'
        '"request_method":"$request_method",'
        '"request_length":"$request_length",'
        '"request_time": "$request_time",'
        '"request_referrer":"$http_referer",'
        '"response_status": "$status",'
        '"response_body_bytes_sent":"$body_bytes_sent",'
        '"response_content_type":"$sent_http_content_type",'
        '"remote_addr": "$remote_addr",'
        '"remote_port": "$remote_port",'
        '"remote_user": "$remote_user",'
        '"upstream_addr": "$upstream_addr",'
        '"upstream_bytes_received": "$upstream_bytes_received",'
        '"upstream_bytes_sent": "$upstream_bytes_sent",'
        '"upstream_cache_status":"$upstream_cache_status",'
        '"upstream_connect_time":"$upstream_connect_time",'
        '"upstream_header_time":"$upstream_header_time",'
        '"upstream_response_length":"$upstream_response_length",'
        '"upstream_response_time":"$upstream_response_time",'
        '"upstream_status": "$upstream_status",'
        '"upstream_content_type":"$upstream_http_content_type"'
    '}';

    access_log  /var/log/nginx/access.log  main;
    access_log  /var/log/nginx/access.json.log vector;      # Nuovo log in formato json

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

Per non danneggiare la tua configurazione attuale, Nginx consente di avere piΓΉ direttive access_log

access_log  /var/log/nginx/access.log  main;            # Log standard
access_log  /var/log/nginx/access.json.log vector;      # Nuovo log in formato json

Non dimenticare di aggiungere una regola in logrotate per i nuovi log (se il file log non termina con .log)

Rimuoviamo default.conf da /etc/nginx/conf.d/

rm -f /etc/nginx/conf.d/default.conf

Aggiungiamo un virtual host /etc/nginx/conf.d/vhost1.conf

server {
    listen 80;
    server_name vhost1;
    location / {
        proxy_pass http://172.26.10.106:8080;
    }
}

Aggiungiamo un host virtuale /etc/nginx/conf.d/vhost2.conf

server {
    listen 80;
    server_name vhost2;
    location / {
        proxy_pass http://172.26.10.108:8080;
    }
}

Aggiungiamo un host virtuale /etc/nginx/conf.d/vhost3.conf

server {
    listen 80;
    server_name vhost3;
    location / {
        proxy_pass http://172.26.10.109:8080;
    }
}

Aggiungiamo un host virtuale /etc/nginx/conf.d/vhost4.conf

server {
    listen 80;
    server_name vhost4;
    location / {
        proxy_pass http://172.26.10.116:8080;
    }
}

Aggiungiamo al file /etc/hosts gli host virtuali (172.26.10.106 ip del server dove Γ¨ installato nginx) su tutti i server:

172.26.10.106 vhost1
172.26.10.106 vhost2
172.26.10.106 vhost3
172.26.10.106 vhost4

E se tutto Γ¨ pronto, allora

nginx -t 
systemctl restart nginx

Ora installiamo il Vector

yum install -y https://packages.timber.io/vector/0.9.X/vector-x86_64.rpm

Creiamo il file di configurazione per systemd /etc/systemd/system/vector.service

[Unit]
Description=Vector
After=network-online.target
Requires=network-online.target

[Service]
User=vector
Group=vector
ExecStart=/usr/bin/vector
ExecReload=/bin/kill -HUP $MAINPID
Restart=no
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=vector

[Install]
WantedBy=multi-user.target

E configuriamo la sostituzione di Filebeat nella configurazione /etc/vector/vector.toml. L'indirizzo IP 172.26.10.108 Γ¨ l'indirizzo IP del server log (Vector-Server)

data_dir = "/var/lib/vector"

[sources.nginx_file]
  type                          = "file"
  include                       = [ "/var/log/nginx/access.json.log" ]
  start_at_beginning            = false
  fingerprinting.strategy       = "device_and_inode"

[sinks.nginx_output_vector]
  type                          = "vector"
  inputs                        = [ "nginx_file" ]

  address                       = "172.26.10.108:9876"

Non dimenticate di aggiungere l'utente vector al gruppo appropriato in modo che possa leggere i file di log. Ad esempio, nginx in centos crea log con i permessi del gruppo adm.

usermod -a -G adm vector

Avviamo il servizio vector

systemctl enable vector
systemctl start vector

Puoi visualizzare i log di vector in questo modo

journalctl -f -u vector

Nei log deve esserci questa registrazione

INFO vector::topology::builder: Healthcheck: Passed.

Test di carico

Effettueremo il test utilizzando Apache benchmark.

È stato installato il pacchetto httpd-tools su tutti i server

Iniziamo il test utilizzando Apache benchmark da 4 server diversi in screen. Prima avviamo il multiplexer terminale screen, e poi avviamo il test usando Apache benchmark. Come lavorare con screen puoi trovare in abbiamo chiarito il corretto completamento dei programmi che utilizzano il mediastreamer..

Dal 1Β° server

while true; do ab -H "User-Agent: 1server" -c 100 -n 10 -t 10 http://vhost1/; sleep 1; done

Dal 2Β° server

while true; do ab -H "User-Agent: 2server" -c 100 -n 10 -t 10 http://vhost2/; sleep 1; done

Dal 3Β° server

while true; do ab -H "User-Agent: 3server" -c 100 -n 10 -t 10 http://vhost3/; sleep 1; done

Dal 4Β° server

while true; do ab -H "User-Agent: 4server" -c 100 -n 10 -t 10 http://vhost4/; sleep 1; done

Controlliamo i dati in Clickhouse

Accediamo a Clickhouse

clickhouse-client -h 172.26.10.109 -m

Facciamo una richiesta SQL

SELEZIONA * DA vector.logs;

β”Œβ”€nome_nodo────┬───────────timestamp─┬─nome_server─┬─id_utente─┬─richiesta_completa───┬─agente_utente_richiesta─┬─host_http_richiesta─┬─uri_richiesta─┬─schema_richiesta─┬─metodo_richiesta─┬─lunghezza_richiesta─┬─tempo_richiesta─┬─rifertore_richiesta─┬─stato_risposta─┬─byte_corpo_risposta_inviati─┬─tipo_contenuto_risposta─┬───indirizzo_remoto─┬─porta_remota─┬─utente_remoto─┬─indirizzo_upstream─┬─porta_upstream─┬─byte_ricevuti_da_upstream─┬─byte_inviati_a_upstream─┬─stato_cache_upstream─┬─tempo_collegamento_upstream─┬─tempo_intestazione_upstream─┬─lunghezza_risposta_upstream─┬─tempo_risposta_upstream─┬─stato_upstream─┬─tipo_contenuto_upstream─┐
β”‚ nginx-vector β”‚ 2020-08-07 04:32:42 β”‚ vhost1      β”‚         β”‚ GET \/ HTTP\/1.0 β”‚ 1server            β”‚ vhost1            β”‚ \/           β”‚ http           β”‚ GET            β”‚             66 β”‚        0.028 β”‚                  β”‚             404 β”‚                       27 β”‚                       β”‚ 172.26.10.106 β”‚       45886 β”‚             β”‚ 172.26.10.106 β”‚             0 β”‚                     109 β”‚                  97 β”‚ DISABILITATO              β”‚                     0 β”‚                0.025 β”‚                       27 β”‚                  0.029 β”‚             404 β”‚                       β”‚
└──────────────┴─────────────────────┴─────────────┴─────────┴────────────────┴────────────────────┴───────────────────┴─────────────┴────────────────┴────────────────┴────────────────┴──────────────┴──────────────────┴─────────────────┴──────────────────────────┴───────────────────────┴───────────────┴─────────────┴─────────────┴───────────────┴───────────────┴─────────────────────────┴─────────────────────┴───────────────────────┴───────────────────────┴──────────────────────┴──────────────────────────┴────────────────────────┴─────────────────┴───────────────────────

Scopriamo le dimensioni delle tabelle in Clickhouse

seleziona concat(database, '.', table)                         come tabella,
       formattaDimensioneLeggibile(somma(byte))                       come dimensione,
       somma(rows)                                            come righe,
       max(modification_time)                               come ultima_modifica,
       somma(byte)                                           come dimensione_byte,
       any(engine)                                          come motore,
       formattaDimensioneLeggibile(somma(primary_key_bytes_in_memory)) come dimensioni_chiavi_primarie
da system.parts
dove attivo
gruppo per database, tabella
ordine per dimensione_byte desc;

Scopriamo quanto spazio occupano i log in Clickhouse.

Invio dei log json di Nginx tramite Vector a Clickhouse ed Elasticsearch

La dimensione della tabella logs Γ¨ di 857,19 MB.

Invio dei log json di Nginx tramite Vector a Clickhouse ed Elasticsearch

La dimensione degli stessi dati nell'indice di Elasticsearch occupa 4,5 GB.

Se non si specificano i dati nel parametro vector in Clickhouse, occupano 4500/857,19 = 5,24 volte meno rispetto a Elasticsearch.

Nel campo vector la compressione Γ¨ utilizzata per impostazione predefinita.

Chat Telegram su Clickhouse
Chat Telegram su Elasticsearch
Chat Telegram su "Raccolta e analisi dei sistemi messaggi"

Fonte: habr.com

Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server πŸ”₯ Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server | ProHoster