{"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, archiviare, analizzare e gestire i log","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

<\/p>\n

Il materiale dell'articolo \u00e8 un riassunto di una lezione aperta della scuola \"Slyrm\"<\/a><\/noindex>. Se c'\u00e8 interesse e, soprattutto, necessit\u00e0 produttiva, si pu\u00f2 seguire un corso completo \u2014 iscriviti al corso su Monitoraggio e logging delle infrastrutture 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 comunque normalmente in Docker. Pertanto, \u00e8 necessario configurare il logging in modo da raccogliere i log dai contenitori. I contenitori sono avviati da Docker, quindi dobbiamo capire come funziona il logging a livello di Docker.<\/p>\n

<\/p>\n

Spero che ogni lettore sappia: i log delle applicazioni devono essere scritti in stdout\/stderr, e non all'interno del container. I log vengono aggregati dal Docker Daemon, che lavora proprio con quei log inviati a stdout\/stderr. Inoltre, registrare i log all'interno del container porta a problemi: il container cresce a causa del log in aumento (poich\u00e9 probabilmente non c'\u00e8 alcun Logrotate nel container) e il 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 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 usato Docker EE nella pratica: in Southbridge cerchiamo di attenerci a soluzioni Open Source, e per i clienti gran parte delle funzionalit\u00e0 aggiuntive di Docker EE non \u00e8 necessaria. <\/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 specifica il plugin e nel campo \u201clog-opts\u201d le sue impostazioni. Nell'esempio sopra \u00e8 indicato il plugin \u201cjson-file\u201d, dove il limite delle dimensioni del log \u00e8 \u201cmax-size\u201d: \u201c10m\u201d; il limite del numero di file (impostazioni di rotazione) \u00e8 \u201cmax-file\u201d: \u201c3\u201d; e anche i valori che saranno allegati ai log.<\/p>\n

<\/p>\n

\"Logging<\/p>\n

<\/p>\n

Alcune impostazioni del log-driver possono essere fornite tramite l'utilit\u00e0 da riga di comando. Questo \u00e8 utile se un contenitore specifico deve essere avviato con un log-driver 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 file. I raccoglitori di log (Rsyslog, Fluentd, Logagent e altri) raccolgono questi file e li inviano per l'archiviazione in Elastic, Sematext o altre soluzioni di storage.<\/p>\n

<\/p>\n

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

<\/p>\n

In modo semplificato, lo schema di logging in Kubernetes appare cos\u00ec: c'\u00e8 un pod, in cui \u00e8 avviato un contenitore, e il contenitore invia i log in stdout\/stderr. Poi Docker crea un file e registra i log, che poi possono essere ruotati.<\/p>\n

<\/p>\n

\"Logging<\/p>\n

<\/p>\n

Esaminiamo le caratteristiche del logging in Kubernetes.<\/p>\n

<\/p>\n

Conservare i log tra i deploy<\/strong>. Questo \u00e8 un requisito fondamentale per una corretta configurazione del logging. Se non si conservano i log tra i deployment, i log della versione precedente dell'applicazione verranno sovrascritti con l'uscita di una nuova versione, e il riavvio del container comporter\u00e0 anche la perdita dei log. Kubernetes ha una flag —previous, che consente di visualizzare i log dell'applicazione prima dell'ultimo riavvio del Pod, ma non pi\u00f9 a fondo.<\/p>\n

<\/p>\n

Aggregare i log da tutte le istanze<\/strong>. Se i microservizi sono ospitati nel cloud, il fornitore di cloud si occupa del monitoraggio del sistema. Se i microservizi sono sul proprio hardware, oltre ai log dei contenitori, \u00e8 necessario raccogliere anche i log di 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 raccoglieva i log da Docker (ad esempio, journal-bit con la configurazione del log-driver Docker su journald). Hanno provato a utilizzare journal-bit per raccogliere i log sia dai contenitori (specificando nel log-driver Docker che i log devono essere scritti in journald) che dal sistema (in CentOS 7 sono gi\u00e0 presenti systemd e journald). La soluzione funziona, ma non \u00e8 ideale. Se ci sono molti log, journal-bit inizia a laggare e i messaggi si perdono.<\/p>\n

<\/p>\n

Gli esperimenti sono continuati \u2014 e \u00e8 stata trovata un'altra soluzione. In CentOS 7 i log di sistema principali (messages, audit, secure) vengono duplicati in var-log come file. In Docker \u00e8 anche possibile configurare il salvataggio dei log in file json. Pertanto, questi file di CentOS 7 e Docker possono essere raccolti insieme.<\/p>\n

<\/p>\n

Con il 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 contenitori, Logstash raccoglie i log dalle istanze, Kibana consente di elaborare i log ricevuti e di creare grafici. Per un certo periodo, l'ELK Stack \u00e8 stato utilizzato attivamente, ma, a mio avviso, il suo tempo sta passando. Pi\u00f9 avanti spiegher\u00f2 il perch\u00e9.<\/p>\n

<\/p>\n

Aggiungere metadati<\/strong>. I pod, le applicazioni, i contenitori possono essere eseguiti ovunque. Inoltre, un'applicazione pu\u00f2 avere pi\u00f9 istanze. I log sono registrati in un formato uniforme, ma dobbiamo capire quale replica specifica \u00e8, quale Pod sta scrivendo, in quale namespace si trova. Ecco perch\u00e9 \u00e8 necessario aggiungere metadati ai log.<\/p>\n

<\/p>\n

Analizzare i log<\/strong>. \u00c8 curioso, ma i costi per il supporto del sistema di logging e monitoraggio possono superare quelli dell'applicazione principale. Quando hai decine e centinaia di migliaia di log al secondo, sembra inevitabile, ma \u00e8 importante conoscere i limiti. Un modo per trovare questi limiti \u00e8 l'analisi dei log. <\/p>\n

<\/p>\n

Di norma, non \u00e8 necessario raccogliere e conservare tutti i log; \u00e8 sufficiente inviare per la conservazione solo una parte, ad esempio i log con stato 'warning' o 'error'. Se si tratta di log nginx o ingress controller, si possono inviare per la conservazione solo quelli il cui stato \u00e8 diverso da 200. Ma questo non \u00e8 un consiglio universale: se stai costruendo in qualche modo un'analisi sui log di Nginx, vale sicuramente la pena raccoglierli. <\/p>\n

<\/p>\n

Non si consiglia di filtrare i log in modo indiscriminato, poich\u00e9 i dati filtrati potrebbero non essere sufficienti per un'analisi adeguata. D'altro canto, potrebbe essere opportuno condurre l'analisi non a livello di log, ma a livello di raccolta delle metriche. In questo caso, non sar\u00e0 necessario conservare centinaia di migliaia di righe con codice 200. Uno dei metodi \u00e8 ottenere informazioni su traffico ed errori dalle metriche degli ingress controller. <\/p>\n

<\/p>\n

In generale, \u00e8 importante riflettere attentamente su cosa si desidera memorizzare e per quanto tempo, poich\u00e9 altrimenti si rischia di trovarsi in una situazione in cui il sistema di registrazione consuma pi\u00f9 risorse del progetto principale.<\/p>\n

<\/p>\n

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

<\/p>\n

In questa lezione esamineremo due strumenti: uno popolare e l'altro in crescente diffusione. Ce ne sono altri, ma non li considereremo in questo articolo.<\/p>\n

<\/p>\n

Tenendo conto di tutte le caratteristiche sopra menzionate, la registrazione in Kubernetes pu\u00f2 ora essere rappresentata in questo modo:<\/p>\n

<\/p>\n

\"Logging<\/p>\n

<\/p>\n

Resta il registro del container e il sistema di rotazione, ma appare un agente di raccolta che raccoglie i log e li invia per la memorizzazione (nello schema \u2014 nel Logging Backend). L'agente opera su ogni nodo ed \u00e8 generalmente avviato in Kubernetes.<\/p>\n

<\/p>\n

Ora esaminiamo gli strumenti per la registrazione.<\/p>\n

<\/p>\n

Grafana Loki<\/h2>\n

<\/p>\n

Grafana Loki<\/a><\/noindex> \u00e8 apparso di recente, ma \u00e8 gi\u00e0 diventato piuttosto noto. I suoi vantaggi: facile da installare, consuma poche risorse, non richiede l'installazione di Elasticsearch, in quanto memorizza i dati in un TSDB (database delle serie temporali). Nel mio articolo precedente, ho scritto che questo tipo di database memorizza dati in Prometheus, ed \u00e8 una delle numerose somiglianze tra i due prodotti. Gli sviluppatori affermano addirittura che Loki \u00e8 \"Prometheus per il mondo del logging\".<\/p>\n

<\/p>\n

Una breve digressione su TSDB per chi non ha letto l'articolo precedente<\/a><\/noindex>: il TSDB gestisce bene la memorizzazione di grandi volumi di dati e delle serie temporali, ma non \u00e8 progettato per la conservazione a lungo termine. 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 base di dati.<\/p>\n

<\/p>\n

Un altro vantaggio di Loki \u00e8 che per la visualizzazione dei dati viene utilizzato Grafana. Molto comodo: in Grafana possiamo visualizzare i dati di monitoraggio e, collegando Loki, possiamo anche visualizzare i log. \u00c8 possibile costruire grafici dai log.<\/p>\n

<\/p>\n

L'architettura di Loki appare all'incirca cos\u00ec: <\/p>\n

<\/p>\n

\"Logging<\/p>\n

<\/p>\n

Con DaemonSet, un agente \u2014 Promtail o Fluent Bit \u2014 viene distribuito su tutti i server del cluster. L'agente raccoglie i log. Loki li riceve e li memorizza nel suo TSDB. Ai log vengono immediatamente aggiunti dei metadati, il che \u00e8 comodo: si pu\u00f2 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 con l'interfaccia familiare di Grafana. Loki ha anche il suo linguaggio di query, chiamato LogQL, che per nome e sintassi ricorda PromQL in Prometheus. Nell'interfaccia di Loki ci sono suggerimenti per le query, quindi non \u00e8 necessario conoscerle a memoria.<\/p>\n

<\/p>\n

Documentazione del 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 (\"400\", \"404\" e qualsiasi altro); visualizzare i log di tutto il nodo; filtrare tutti i log che contengono la parola \"error\". Cliccando su un log, si aprir\u00e0 una scheda con tutte le informazioni sull'evento.<\/p>\n

<\/p>\n

In Loki ci sono strumenti sufficienti che consentono di estrarre i log necessari, anche se onestamente potrebbero essere pi\u00f9 numerosi elettronicamente. Attualmente, Loki si sta sviluppando attivamente e sta guadagnando popolarit\u00e0. <\/p>\n

<\/p>\n

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

<\/p>\n

Lo stack EFK \u00e8 uno strumento di logging pi\u00f9 classico, non meno popolare. <\/p>\n

<\/p>\n

All'inizio dell'articolo si parlava di ELK (Elasticsearch + Logstash + Kibana), ma questo stack \u00e8 diventato obsoleto a causa di un Logstash non molto performante e anche molto esoso in termini di risorse. Al suo posto, si \u00e8 iniziato a utilizzare il pi\u00f9 leggero e performante Fluentd, e dopo un po' di tempo gli \u00e8 stato affiancato Fluent Bit<\/a><\/noindex> \u2014 un agente di raccolta ancora pi\u00f9 leggero e performante. <\/p>\n

<\/p>\n

Se si crede agli sviluppatori, Fluent Bit \u00e8 oltre 100 volte pi\u00f9 performante di Fluentd: \"dove Fluentd consuma 20 MB di RAM, Fluent Bit consuma 150 KB\" \u2014 citazione diretta dalla documentazione. Guardando a questi dati, si \u00e8 iniziato a utilizzare Fluent Bit pi\u00f9 spesso.<\/p>\n

<\/p>\n

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

<\/p>\n

Schema di funzionamento dello stack EFK: l'agente raccoglie i log da tutti i pod (di solito un DaemonSet eseguito su tutti i server del cluster) e invia i dati a uno storage (Elasticsearch, PostgreSQL o Kafka). Kibana si connette allo storage e recupera tutte le informazioni necessarie.<\/p>\n

<\/p>\n

\"Logging<\/p>\n

<\/p>\n

Kibana<\/a><\/noindex> visualizza le informazioni in un'interfaccia web comoda. Ci sono grafici, filtri e molto altro.<\/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 si parla generalmente meno rispetto a Logstash, esaminiamo questo strumento in modo pi\u00f9 dettagliato. Fluent Bit pu\u00f2 essere logicamente suddiviso in 6 moduli, e alcuni di questi moduli possono essere dotati di plugin che estendono le funzionalit\u00e0 di Fluent Bit.<\/p>\n

<\/p>\n

\"Logging<\/p>\n

<\/p>\n

Modulo Input<\/strong> raccoglie i log da file, servizi systemd e anche da tcp-socket (\u00e8 sufficiente specificare l'endpoint e Fluent Bit inizier\u00e0 a connettersi). Queste funzionalit\u00e0 sono sufficienti per raccogliere log sia dal sistema che dai contenitori.<\/p>\n

<\/p>\n

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

<\/p>\n

Modulo Parser<\/strong> formalizza i log in un formato comune. Per impostazione predefinita, i log di Nginx sono una singola stringa. Con l'aiuto di un plugin, tale stringa pu\u00f2 essere trasformata in JSON: \u00e8 possibile definire campi e valori. Lavorare con il JSON \u00e8 molto pi\u00f9 semplice rispetto ai log in formato stringa, poich\u00e9 offre maggiore flessibilit\u00e0 nella sorteggiatura.<\/p>\n

<\/p>\n

Modulo Filter<\/strong>. A questo livello si filtrano i log non necessari. Ad esempio, vengono memorizzati solo i log con il valore \"warning\" o con specifici label. I log selezionati vengono inviati al buffer.<\/p>\n

<\/p>\n

Modulo Buffer<\/strong>. Fluent Bit ha due tipi di buffer: buffer di memoria e buffer su disco. Un buffer \u00e8 un'area di memorizzazione temporanea per i log, utilizzata in caso di errori o malfunzionamenti. Tutti vogliono risparmiare sulla RAM, quindi di solito si sceglie il buffer su disco. Ma bisogna considerare che prima di andare 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, attraverso di esso \u00e8 possibile raccogliere log e inviarli a Fluentd, dove possono essere ulteriormente elaborati e inviati a storage utilizzando plugin aggiuntivi.<\/p>\n

<\/p>\n

Se pianificate di usare Elasticsearch\u2026<\/p>\n

Ultimo consiglio per coloro che intendono utilizzare Elasticsearch come storage di log in produzione. <\/p>\n

    \n
  1. Configurate le notifiche utilizzando ElastAlert<\/a><\/noindex>. Questo programma estrae i messaggi importanti dal flusso generale di log e crea avvisi via email o su un altro canale. Tuttavia, recentemente \u00e8 stata pubblicata una triste notizia riguardante il fatto che il progetto potrebbe presto cessare di esistere.<\/a><\/noindex><\/em>.<\/li>\n
  2. Ruota i log utilizzando l'applicazione Curator<\/a><\/noindex> o tramite chiamate all'API di Elasticsearch. Elastic, in effetti, sta compiendo notevoli passi avanti nella gestione della vita degli indici senza utilizzare strumenti esterni. In generale, non ha senso conservare i log a lungo: \u00e8 improbabile che un log sia utile dopo due settimane \u2014 se \u00e8 veramente critico, verr\u00e0 gestito entro quel termine. In caso estremo, i log pi\u00f9 vecchi possono essere archiviati e inviati da qualche parte per la conservazione a lungo termine. Ho sentito parlare di log speciali che, per legge, devono essere conservati fino a 5 anni. Personalmente non ho mai avuto a che fare con questo, ma non equiparerei tali informazioni a log normali e probabilmente li conserverei separatamente.<\/li>\n<\/ol>\n

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

    Continua…<\/p>\n

    <\/p>\n

    Autore: Marsel Ibraev, amministratore certificato Kubernetes, ingegnere praticante presso Southbridge<\/a><\/noindex>, relatore e sviluppatore di corsi Sleurm<\/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, memorizzare, analizzare e gestire i log | ProHoster","description":"Esploreremo le basi della registrazione in Docker e Kubernetes, per poi esaminare due strumenti che possono essere utilizzati con fiducia in produzione: Grafana Loki e il stack EFK (Elasticsearch + Fluent Bit + Kibana). Il materiale dell'articolo \u00e8 un riassunto di una lezione aperta della scuola \u201cSl\u0451rm\u201d. Se avete interesse e soprattutto necessit\u00e0 produttiva, potete seguire un corso completo su","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). \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","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"},"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}]}}