{"id":93294,"date":"2020-09-05T07:42:58","date_gmt":"2020-09-05T05:42:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi"},"modified":"2020-09-05T07:42:58","modified_gmt":"2020-09-05T05:42:58","slug":"logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","title":{"rendered":"Logging in Kubernetes: come raccogliere, memorizzare, analizzare e gestire i log","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Analizzeremo le basi del logging in Docker e Kubernetes, e poi esamineremo due strumenti che possono essere utilizzati tranquillamente in produzione: Grafana Loki e il stack EFK (Elasticsearch + Fluent Bit + Kibana).<\/p>\n

<\/p>\n

Il materiale dell'articolo \u00e8 un riassunto di una lezione aperta della scuola \"Slurm\".<\/a><\/noindex>. Se hai desiderio e, soprattutto, necessit\u00e0 produttiva, puoi seguire un corso completo su Monitoraggio e logging dell'infrastruttura in Kubernetes.<\/a><\/noindex>.<\/em><\/p>\n

<\/p>\n

\"Logging<\/p>\n

<\/a><\/noindex><\/p>\n

Logging in Docker.<\/h2>\n

<\/p>\n

A livello di Kubernetes, le applicazioni sono eseguite nei pod, ma a un livello inferiore funzionano di solito in Docker. Pertanto, \u00e8 necessario configurare il logging in modo da raccogliere i log dai container. I container vengono avviati da Docker \u2014 quindi \u00e8 fondamentale capire come \u00e8 strutturato il logging a livello di Docker.<\/p>\n

<\/p>\n

Spero che ogni lettore sappia: i log dell'applicazione devono essere scritti in stdout\/stderr e non all'interno del container. I log sono aggregati dal Docker Daemon, e lui lavora precisamente con i log che vengono inviati a stdout\/stderr. Inoltre, scrivere i log all'interno del container comporta dei problemi: il container si gonfia a causa del log in crescita (poich\u00e9 probabilmente non c'\u00e8 Logrotate nel container), e Docker Daemon non \u00e8 a conoscenza di questo log.<\/p>\n

<\/p>\n

Docker ha diversi driver di log o plugin per la raccolta dei log dei container. Nella versione gratuita di Docker Community Edition (CE) ci sono meno driver di log rispetto alla versione commerciale Docker Enterprise Edition (EE).<\/p>\n

<\/p>\n

\"Logging<\/p>\n

<\/p>\n

Non ho mai utilizzato Docker EE nella pratica: in Southbridge cerchiamo di attenerci a soluzioni Open Source, e la maggior parte delle funzionalit\u00e0 aggiuntive di Docker EE non \u00e8 necessaria per i clienti. <\/p>\n

<\/p>\n

Driver di log in Docker CE:<\/p>\n

<\/p>\n

local<\/strong> \u2014 scrittura dei log in file interni del Docker Daemon;
\njson-file<\/strong> \u2014 creazione di un json-log nella cartella di ogni container;
\njournald<\/strong> \u2014 invio dei log a journald.<\/p>\n

<\/p>\n

Le impostazioni di logging in Docker si trovano nel file daemon.json. <\/p>\n

<\/p>\n

Nel campo \u201clog-driver\u201d si indica il plugin, e nel campo \u201clog-opts\u201d le sue impostazioni. Nell'esempio sopra \u00e8 indicato il plugin \u201cjson-file\u201d, con una limitazione sulle dimensioni del log \u2014 \u201cmax-size\u201d: \u201c10m\u201d; limitazione sul numero di file (impostazioni di rotazione) \u2014 \u201cmax-file\u201d: \u201c3\u201d; cos\u00ec come i valori che verranno allegati ai log.<\/p>\n

<\/p>\n

\"Logging<\/p>\n

<\/p>\n

Alcune impostazioni del driver di log possono essere impostate tramite l'utilit\u00e0 da riga di comando. \u00c8 comodo se \u00e8 necessario avviare un container separato con un driver di log diverso. <\/p>\n

<\/p>\n

Ecco come appare lo schema di logging in Docker:<\/p>\n

<\/p>\n

\"Logging<\/p>\n

<\/p>\n

Come funziona lo schema: il log driver, ad esempio json-file, crea dei file. I raccoglitori di log (Rsyslog, Fluentd, Logagent e altri) raccolgono questi file e li inviano per l'archiviazione in Elastic, Sematext o altri storage.<\/p>\n

<\/p>\n

Caratteristiche del logging in Kubernetes<\/h2>\n

<\/p>\n

In termini semplici, lo schema di logging in Kubernetes appare cos\u00ec: c'\u00e8 un pod, all'interno c'\u00e8 un container, il container invia i log a stdout\/stderr. Successivamente, Docker crea un file e registra i log, che possono essere ruotati.<\/p>\n

<\/p>\n

\"Logging<\/p>\n

<\/p>\n

Consideriamo le peculiarit\u00e0 del logging in Kubernetes.<\/p>\n

<\/p>\n

Conservare i log tra i deployment<\/strong>. \u00c8 una condizione indispensabile per una corretta configurazione del logging. Se non si conservano i log tra i deployment, con l'uscita di una nuova versione dell'applicazione i log precedenti verranno sovrascritti, e il riavvio del container comporter\u00e0 anch'esso la perdita dei log. Kubernetes ha un'opzione \u2014previous, che consente di visualizzare i log dell'applicazione fino all'ultimo riavvio del Pod, ma non oltre.<\/p>\n

<\/p>\n

Aggregare i log da tutte le istanze<\/strong>. Se i microservizi sono ospitati nel cloud, il provider cloud si occupa del controllo del sistema. Se i microservizi sono su hardware proprio, oltre ai log dei container, \u00e8 necessario raccogliere anche i log del sistema.<\/p>\n

<\/p>\n

In passato non c'erano strumenti comodi per raccogliere i log sia dal sistema che dai microservizi. Di solito, un strumento raccoglieva i log di sistema (ad esempio, Rsyslog), mentre un altro raccolse i log da Docker (ad esempio, journal-bit configurando il log driver di Docker su journald). Abbiamo provato a usare journal-bit per raccogliere i log sia dai container (nel log driver di Docker specificare che devono essere scritti in journald), che dal sistema (in CentOS 7 ci sono gi\u00e0 systemd e journald). La soluzione funziona, ma non \u00e8 ideale. Quando ci sono troppi log, journal-bit inizia a laggare e i messaggi si perdono.<\/p>\n

<\/p>\n

Gli esperimenti sono continuati e abbiamo trovato un altro modo. In CentOS 7 i principali log di sistema (messages, audit, secure) vengono duplicati nella var-log sotto forma di file. Anche in Docker \u00e8 possibile configurare il salvataggio dei log in file json. Di conseguenza, questi file di CentOS 7 e Docker possono essere raccolti insieme.<\/p>\n

<\/p>\n

Col tempo, \u00e8 diventata popolare la soluzione ELK Stack. Questa \u00e8 una combinazione di diversi strumenti: Elasticsearch, Logstash e Kibana.<\/p>\n

<\/p>\n

Elasticsearch memorizza i log dai container, Logstash raccoglie i log dalle istanze, Kibana consente di elaborare i log ricevuti e di costruire grafici su di essi. Per un certo periodo, si \u00e8 utilizzato attivamente ELK Stack, ma, a mio avviso, il suo tempo sta passando. Pi\u00f9 avanti parler\u00f2 del perch\u00e9.<\/p>\n

<\/p>\n

Aggiungere metadati<\/strong>. I pod, le applicazioni e i contenitori possono essere avviati ovunque. Inoltre, un'applicazione pu\u00f2 avere pi\u00f9 istanze. I log sono registrati in un formato unico e noi dobbiamo capire quale replica si tratta, quale Pod l'ha scritto e in quale namespace si trova. \u00c8 per questo che ai log \u00e8 necessario aggiungere metadati.<\/p>\n

<\/p>\n

Parse i log<\/strong>. \u00c8 divertente, ma i costi per il supporto del sistema di log e monitoraggio possono superare le spese per l'applicazione principale. Quando ricevi decine e centinaia di migliaia di log al secondo, sembra ovvio, ma \u00e8 comunque necessario conoscere il limite. Uno dei modi per trovare questo limite \u00e8 il parsing dei log. <\/p>\n

<\/p>\n

In generale, non \u00e8 necessario raccogliere e memorizzare tutti i log, ma \u00e8 sufficiente inviarne solo alcuni per la memorizzazione, ad esempio, i log con stato \u00abwarning\u00bb o \u00aberror\u00bb. Se si tratta di log di nginx o controller ingress, si possono memorizzare solo quelli il cui stato \u00e8 diverso da 200. Ma questo non \u00e8 un consiglio universale: se stai costruendo in qualche modo un'analisi basata sui log di Nginx, \u00e8 ovvio che vale la pena raccoglierli. <\/p>\n

<\/p>\n

Non si consiglia di filtrare i log senza riflettere, perch\u00e9 i dati filtrati potrebbero non essere sufficienti per un'analisi adeguata. D'altra parte, forse \u00e8 necessario condurre l'analisi non a livello di log, ma a livello di raccolta delle metriche. In tal modo non ci sar\u00e0 bisogno di memorizzare centinaia di migliaia di righe con codice 200. Uno degli approcci consiste nell'ottenere informazioni sul traffico e sugli errori dalle metriche dei controller ingress. <\/p>\n

<\/p>\n

In generale, qui \u00e8 necessario riflettere attentamente: cosa vuoi memorizzare e per quanto tempo, altrimenti si presenter\u00e0 una situazione in cui il sistema di log consumer\u00e0 pi\u00f9 risorse del progetto principale.<\/p>\n

<\/p>\n

Attualmente non esiste una soluzione standard per la registrazione<\/strong>. A differenza del monitoraggio, dove esiste una soluzione predominante chiamata Prometheus, nella registrazione non c'\u00e8 uno standard. <\/p>\n

<\/p>\n

Nell'ambito di questa lezione esamineremo due strumenti: uno popolare e l'altro in aumento di popolarit\u00e0. Oltre a questi, ce ne sono altri, ma in questo articolo non ne parleremo.<\/p>\n

<\/p>\n

Tenendo conto di tutte le caratteristiche sopra esaminate, la registrazione in Kubernetes pu\u00f2 ora essere rappresentata con il seguente schema:<\/p>\n

<\/p>\n

\"Logging<\/p>\n

<\/p>\n

Rimane il log del contenitore, la rotazione, ma appare un agente-raccoglitore che raccoglie i log e li invia per la memorizzazione (nello schema \u2014 nel Logging Backend). L'agente opera su ciascun nodo e, in genere, \u00e8 avviato in Kubernetes.<\/p>\n

<\/p>\n

Ora consideriamo gli strumenti per il logging.<\/p>\n

<\/p>\n

Grafana Loki<\/h2>\n

<\/p>\n

Grafana Loki<\/a><\/noindex> \u00c8 comparso di recente, ma \u00e8 gi\u00e0 diventato piuttosto noto. I suoi vantaggi: \u00e8 facile da installare, consuma poche risorse e non richiede l'installazione di Elasticsearch, poich\u00e9 memorizza i dati in un TSDB (time series database). Nell'articolo precedente ho scritto che Prometheus memorizza i dati in tale database, e questo \u00e8 uno dei numerosi punti in comune tra i due prodotti. Gli sviluppatori affermano addirittura che Loki \u00e8 \"Prometheus per il mondo del logging\".<\/p>\n

<\/p>\n

Una breve digressione sul TSDB per chi non ha letto. l'articolo precedente<\/a><\/noindex>: Il TSDB gestisce bene l'archiviazione di grandi quantit\u00e0 di dati di serie temporali, ma non \u00e8 concepito per una conservazione prolungata. Se per qualche motivo hai bisogno di conservare i log per pi\u00f9 di due settimane, \u00e8 meglio configurare il loro invio a un'altra Banca Dati.<\/p>\n

<\/p>\n

Un altro vantaggio di Loki \u00e8 l'uso di Grafana per la visualizzazione dei dati. \u00c8 molto conveniente: in Grafana guardiamo i dati di monitoraggio e collegando Loki possiamo anche vedere i log. Dai log \u00e8 possibile creare grafici.<\/p>\n

<\/p>\n

L'architettura di Loki appare pi\u00f9 o meno cos\u00ec: <\/p>\n

<\/p>\n

\"Logging<\/p>\n

<\/p>\n

Tramite un DaemonSet su tutti i server del cluster viene distribuito un agente \u2014 Promtail o Fluent Bit. L'agente raccoglie i log. Loki li preleva e li memorizza nel TSDB. I log vengono aggiornati con metadati, il che \u00e8 comodo: \u00e8 possibile filtrare per Pods, namespaces, nomi dei contenitori e persino etichette.<\/p>\n

<\/p>\n

Istruzioni per l'installazione di Loki.<\/a><\/noindex><\/p>\n

<\/p>\n

Loki funziona in un'interfaccia conosciuta di Grafana. Loki ha anche un proprio linguaggio di query, chiamato LogQL, che per nome e sintassi \u00e8 simile al PromQL di Prometheus. Nell'interfaccia di Loki ci sono suggerimenti per le query, quindi non \u00e8 necessario conoscerle a memoria.<\/p>\n

<\/p>\n

Documentazione sul linguaggio LogQL.<\/a><\/noindex><\/p>\n

<\/p>\n

\"Logging
\nLoki nell'interfaccia di Grafana.<\/em><\/p>\n

<\/p>\n

Utilizzando i filtri, in Loki \u00e8 possibile trovare codici (\u201c400\u201d, \u201c404\u201d e qualsiasi altro); visualizzare i log da tutta la node; filtrare tutti i log contenenti la parola \u201cerror\u201d. Cliccando su un log, si apre una scheda con tutte le informazioni relative all'evento.<\/p>\n

<\/p>\n

In Loki ci sono strumenti sufficienti che permettono di estrarre i log necessari, anche se a dire il vero potrebbero essercene di pi\u00f9 a livello tecnico. Attualmente Loki \u00e8 in fase di attiva evoluzione e sta guadagnando popolarit\u00e0. <\/p>\n

<\/p>\n

Elastic + Fluent Bit + Kibana (EFK Stack)<\/h2>\n

<\/p>\n

Il stack EFK \u00e8 uno strumento di logging pi\u00f9 classico e altrettanto popolare. <\/p>\n

<\/p>\n

All'inizio dell'articolo si menzionava ELK (Elasticsearch + Logstash + Kibana), ma questo stack \u00e8 obsoleto a causa di Logstash, non molto performante e che richiede molte risorse. Al suo posto \u00e8 stato utilizzato un agente pi\u00f9 leggero e performante, Fluentd, e dopo un po' di tempo gli \u00e8 stato affiancato Fluent Bit<\/a><\/noindex> \u2014 un agente raccoglitore ancora pi\u00f9 leggero e pi\u00f9 performante. <\/p>\n

<\/p>\n

Se \u00e8 vero ci\u00f2 che dicono gli sviluppatori, Fluent Bit \u00e8 pi\u00f9 di 100 volte migliore in termini di prestazioni rispetto a Fluentd: \u00abl\u00ec dove Fluentd consuma 20 MB di RAM, Fluent Bit ne consuma solo 150 KB\u00bb \u2014 una citazione diretta dalla documentazione. Guardando a questo, Fluent Bit \u00e8 stato utilizzato pi\u00f9 frequentemente.<\/p>\n

<\/p>\n

Fluent Bit ha meno funzionalit\u00e0 rispetto a Fluentd, ma soddisfa le esigenze principali, quindi lo utilizziamo principalmente.<\/p>\n

<\/p>\n

Schema di funzionamento dello stack EFK: l'agente raccoglie i log da tutti i pod (di solito \u00e8 un DaemonSet in esecuzione su tutti i server del cluster) e li invia a una sorgente dati (Elasticsearch, PostgreSQL o Kafka). Kibana si collega alla sorgente dati e trae tutte le informazioni necessarie.<\/p>\n

<\/p>\n

\"Logging<\/p>\n

<\/p>\n

Kibana<\/a><\/noindex> presenta le informazioni in un'interfaccia web comoda. Ci sono grafici, filtri e molte altre cose.<\/p>\n

<\/p>\n

\"Logging<\/p>\n

<\/p>\n

Dai log \u00e8 possibile creare interi dashboard.<\/p>\n

<\/p>\n

\"Logging<\/p>\n

<\/p>\n

Funzionalit\u00e0 di Fluent Bit<\/h2>\n

<\/p>\n

Poich\u00e9 di Fluent Bit, di solito, si sa meno rispetto a Logstash, esaminiamolo un po' pi\u00f9 nel dettaglio. Fluent Bit pu\u00f2 essere logicamente suddiviso in 6 moduli, a cui \u00e8 possibile aggiungere plugin che espandono le funzionalit\u00e0 di Fluent Bit.<\/p>\n

<\/p>\n

\"Logging<\/p>\n

<\/p>\n

Modulo Input<\/strong> raccoglie log da file, servizi systemd e persino da socket TCP (basta indicare l'endpoint e Fluent Bit inizier\u00e0 a collegarsi). Queste funzionalit\u00e0 sono sufficienti per raccogliere log sia dal sistema che dai container.<\/p>\n

<\/p>\n

In produzione utilizziamo pi\u00f9 spesso i plugin tail<\/a><\/noindex> (pu\u00f2 essere diretto su una cartella con log) e systemd<\/a><\/noindex> (pu\u00f2 essere indicato da quali servizi raccogliere log).<\/p>\n

<\/p>\n

Modulo Parser<\/strong> porta i log a una forma uniforme. Per impostazione predefinita, i log di Nginx sono una stringa. Con l'aiuto di un plugin, questa stringa pu\u00f2 essere convertita in JSON: definendo i campi e i loro valori. Con JSON \u00e8 molto pi\u00f9 facile lavorare rispetto a un log basato su stringhe, perch\u00e9 offre possibilit\u00e0 di ordinamento pi\u00f9 flessibili.<\/p>\n

<\/p>\n

Modulo Filter<\/strong>. A questo livello vengono filtrati i log non necessari. Ad esempio, vengono inviati a memorizzazione solo log con valore \u201cwarning\u201d o con determinate etichette. I log filtrati finiscono in un buffer.<\/p>\n

<\/p>\n

Modulo Buffer<\/strong>. Fluent Bit ha due tipi di buffer: buffer di memoria e buffer su disco. Il buffer \u00e8 uno spazio di archiviazione temporaneo per i log, necessario in caso di errori o guasti. Tutti vogliono risparmiare sulla RAM, quindi di solito si opta per il buffer su disco. Ma \u00e8 importante considerare che, prima di essere scritti su disco, i log vengono comunque scaricati in memoria.<\/p>\n

<\/p>\n

Modulo Routing\/Output<\/strong> contiene le regole e gli indirizzi per l'invio dei log. Come gi\u00e0 detto, i log possono essere inviati a Elasticsearch, PostgreSQL o, ad esempio, Kafka. <\/p>\n

<\/p>\n

\u00c8 interessante notare che da Fluent Bit i log possono essere inviati a Fluentd. Poich\u00e9 il primo \u00e8 pi\u00f9 leggero e meno funzionale, tramite esso si possono raccogliere i log e inviarli a Fluentd, dove possono essere ulteriormente elaborati e inviati agli archivi con l'ausilio di plugin aggiuntivi.<\/p>\n

<\/p>\n

Se prevedi di utilizzare Elasticsearch\u2026<\/p>\n

Infine, due consigli per chi intende utilizzare Elasticsearch in produzione come archivio di log. <\/p>\n

    \n
  1. Imposta avvisi tramite ElastAlert<\/a><\/noindex>. Questo programma estrae dai log unici messaggi importanti e genera alert via email o su un altro canale. Tuttavia, non molto tempo fa \u00e8 emersa una triste notizia secondo cui il progetto potrebbe presto cessare di esistere.<\/a><\/noindex><\/em>.<\/li>\n
  2. Ruota i log utilizzando l'applicazione Curator<\/a><\/noindex> oppure interagendo con l'API di Elasticsearch. Di per s\u00e9, Elastic sta ora facendo passi significativi nella gestione della vita degli indici senza strumenti di terze parti. In generale, non ha senso mantenere i log a lungo: \u00e8 improbabile che un log sia necessario dopo due settimane; se \u00e8 veramente critico, sar\u00e0 certamente stato gestito entro quel periodo. In caso estremo, i log vecchi possono essere archiviati e inviati in un luogo per la conservazione a lungo termine. Ho sentito parlare di log particolari che, per legge, devono essere conservati fino a 5 anni. Personalmente non mi sono mai trovato in una situazione simile, ma non considererei queste informazioni equivalenti ai log normali e probabilmente li conservarei separatamente.<\/li>\n<\/ol>\n

    \n<\/p><\/blockquote>\n

    Continua…<\/p>\n

    <\/p>\n

    Autore: Marsel Abraev, amministratore certificato Kubernetes, ingegnere praticante presso Southbridge<\/a><\/noindex>, relatore e sviluppatore di corsi Slerm<\/a><\/noindex>.<\/em><\/p>\n

    Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u0420\u0430\u0437\u0431\u0435\u0440\u0451\u043c \u043e\u0441\u043d\u043e\u0432\u044b \u043b\u043e\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 Docker \u0438 Kubernetes, \u0430 \u0437\u0430\u0442\u0435\u043c \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0434\u0432\u0430 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u0430, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043e\u0436\u043d\u043e \u0441\u043c\u0435\u043b\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u0435\u043d\u0435: Grafana Loki \u0438 \u0441\u0442\u0435\u043a EFK (Elasticsearch + Fluent Bit + Kibana). \u041c\u0430\u0442\u0435\u0440\u0438\u0430\u043b \u0441\u0442\u0430\u0442\u044c\u0438 \u2014 \u0432\u044b\u0436\u0438\u043c\u043a\u0430 \u0438\u0437 \u043e\u0442\u043a\u0440\u044b\u0442\u043e\u0439 \u043b\u0435\u043a\u0446\u0438\u0438 \u0448\u043a\u043e\u043b\u044b \u00ab\u0421\u043b\u0451\u0440\u043c\u00bb. \u0415\u0441\u043b\u0438 \u0435\u0441\u0442\u044c \u0436\u0435\u043b\u0430\u043d\u0438\u0435 \u0438 \u0442\u0435\u043c \u0431\u043e\u043b\u0435\u0435 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0441\u0442\u0432\u0435\u043d\u043d\u0430\u044f \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e\u0441\u0442\u044c \u043c\u043e\u0436\u043d\u043e \u043f\u0440\u043e\u0439\u0442\u0438 \u043f\u043e\u043b\u043d\u043e\u0435 \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u0435 \u2014 \u0437\u0430\u043f\u0438\u0441\u044b\u0432\u0430\u0439\u0442\u0435\u0441\u044c \u043d\u0430 \u043a\u0443\u0440\u0441 \u043f\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":93295,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-93294","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Registrazione in Kubernetes: come raccogliere, archiviare, analizzare e elaborare log | ProHoster","description":"Esamineremo le basi della registrazione in Docker e Kubernetes, e poi considereremo due strumenti che si possono tranquillamente utilizzare in produzione: Grafana Loki e lo stack EFK (Elasticsearch + Fluent Bit + Kibana)..","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041b\u043e\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0432 Kubernetes: \u043a\u0430\u043a \u0441\u043e\u0431\u0438\u0440\u0430\u0442\u044c, \u0445\u0440\u0430\u043d\u0438\u0442\u044c, \u043f\u0430\u0440\u0441\u0438\u0442\u044c \u0438 \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0442\u044c \u043b\u043e\u0433\u0438 | ProHoster","og:description":"\u0420\u0430\u0437\u0431\u0435\u0440\u0451\u043c \u043e\u0441\u043d\u043e\u0432\u044b \u043b\u043e\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0432 Docker \u0438 Kubernetes, \u0430 \u0437\u0430\u0442\u0435\u043c \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0434\u0432\u0430 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u0430, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043e\u0436\u043d\u043e \u0441\u043c\u0435\u043b\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u0435\u043d\u0435: Grafana Loki \u0438 \u0441\u0442\u0435\u043a EFK (Elasticsearch + Fluent Bit + Kibana)..","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-09-05T05:42:58+00:00","article:modified_time":"2020-09-05T05:42:58+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"93294","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 11:50:29","updated":"2022-09-27 18:43:48","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/93294","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=93294"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/93294\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/93295"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=93294"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=93294"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=93294"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}