{"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\/de\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","title":{"rendered":"Protokollierung in Kubernetes: Wie man Protokolle sammelt, speichert, analysiert und verarbeitet","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Lassen Sie uns die Grundlagen des Loggings in Docker und Kubernetes durchgehen und anschlie\u00dfend zwei Werkzeuge betrachten, die sicher im Produktionsumfeld eingesetzt werden k\u00f6nnen: Grafana Loki und den EFK-Stack (Elasticsearch + Fluent Bit + Kibana).<\/p>\n

<\/p>\n

Das Material des Artikels ist eine Zusammenfassung aus einer offenen Vorlesung der Schule \u201eSlurmr\u201c<\/a><\/noindex>. Wenn das Interesse besteht und aufgrund der Produktionsanforderungen ist eine vollst\u00e4ndige Schulung m\u00f6glich \u2013 melden Sie sich f\u00fcr den Kurs an \u00fcber Monitoring und Logging von Infrastrukturen in Kubernetes<\/a><\/noindex>.<\/em><\/p>\n

<\/p>\n

\"Protokollierung<\/p>\n

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

Logging in Docker<\/h2>\n

<\/p>\n

Auf der Kubernetes-Ebene werden Anwendungen in Pods gestartet, aber auf der darunterliegenden Ebene arbeiten sie normalerweise in Docker. Daher muss das Logging so konfiguriert werden, dass Logs von den Containern gesammelt werden. Die Container werden von Docker gestartet \u2013 daher muss man herausfinden, wie das Logging auf Docker-Ebene funktioniert.<\/p>\n

<\/p>\n

Ich hoffe, dass jeder Leser wei\u00df: Anwendungs-Logs sollten in stdout\/stderr geschrieben werden und nicht im Container selbst. Docker Daemon aggregiert die Logs, und er arbeitet nur mit den Logs, die an stdout\/stderr gesendet werden. Au\u00dferdem kann das Schreiben von Logs im Container problematisch sein: Der Container w\u00e4chst mit dem wachsenden Log (da es wahrscheinlich keinen Logrotate im Container gibt), und Docker Daemon ist sich dieses Logs nicht bewusst.<\/p>\n

<\/p>\n

Docker hat mehrere Log-Manager oder Plugins zur Sammlung von Container-Logs. In der kostenlosen Version Docker Community Edition (CE) gibt es weniger Log-Manager als in der kommerziellen Docker Enterprise Edition (EE).<\/p>\n

<\/p>\n

\"Protokollierung<\/p>\n

<\/p>\n

Docker EE habe ich in der Praxis noch nie verwendet: In Southbridge bem\u00fchen wir uns um Open-Source-L\u00f6sungen, und den Kunden fehlen oft die meisten zus\u00e4tzlichen Funktionen von Docker EE. <\/p>\n

<\/p>\n

Log-Manager in Docker CE:<\/p>\n

<\/p>\n

local<\/strong> \u2013 Speicherung von Logs in internen Dateien des Docker Daemon;
\njson-file<\/strong> \u2013 Erstellung eines json-Logs im Ordner jedes Containers;
\njournald<\/strong> \u2013 Versand von Logs an journald.<\/p>\n

<\/p>\n

Die Logging-Einstellungen in Docker befinden sich in der Datei daemon.json. <\/p>\n

<\/p>\n

Im Feld \u201elog-driver\u201c geben Sie das Plugin an, und im Feld \u201elog-opts\u201c \u2013 dessen Einstellungen. Im obigen Beispiel wurde das Plugin \u201ejson-file\u201c angegeben, mit einer Log-Gr\u00f6\u00dfenbegrenzung \u2013 \u201emax-size\u201c: \u201e10m\u201c; begrenzte Anzahl von Dateien (Rotationsparameter) \u2013 \u201emax-file\u201c: \u201e3\u201c; sowie Werte, die an die Logs angeh\u00e4ngt werden.<\/p>\n

<\/p>\n

\"Protokollierung<\/p>\n

<\/p>\n

Einige Einstellungen des Log-Managers k\u00f6nnen \u00fcber die Befehlszeilenanwendung festgelegt werden. Das ist praktisch, wenn ein einzelner Container mit einem anderen Log-Manager gestartet werden muss. <\/p>\n

<\/p>\n

So sieht das Logging-Schema in Docker aus:<\/p>\n

<\/p>\n

\"Protokollierung<\/p>\n

<\/p>\n

So funktioniert das Schema: Der Log-Manager, zum Beispiel json-file, erstellt Dateien. Die Log-Sammler (Rsyslog, Fluentd, Logagent und andere) sammeln diese Dateien und \u00fcbertragen sie zur Speicherung in Elastic, Sematext oder andere Speicher.<\/p>\n

<\/p>\n

Besonderheiten des Loggings in Kubernetes<\/h2>\n

<\/p>\n

Vereinfacht sieht das Logging-Schema in Kubernetes so aus: Es gibt einen Pod, in dem ein Container l\u00e4uft, der Container sendet Logs an stdout\/stderr. Anschlie\u00dfend erstellt Docker eine Datei und schreibt die Logs hinein, die dann rotiert werden k\u00f6nnen.<\/p>\n

<\/p>\n

\"Protokollierung<\/p>\n

<\/p>\n

Betrachten wir die Besonderheiten des Loggings in Kubernetes.<\/p>\n

<\/p>\n

Logs zwischen Deployments speichern<\/strong>. Dies ist eine notwendige Bedingung f\u00fcr eine korrekte Protokollierung. Wenn die Protokolle zwischen den Deployments nicht gespeichert werden, gehen die Protokolle der vorherigen Version beim Ersetzen der Anwendung verloren, und auch das Neustarten des Containers kann zum Verlust der Protokolle f\u00fchren. Kubernetes verf\u00fcgt \u00fcber einen Parameter \u2014previous, mit dem Sie die Protokolle der Anwendung vor dem letzten Neustart des Pods anzeigen k\u00f6nnen, jedoch nicht tiefer.<\/p>\n

<\/p>\n

Logs von allen Instanzen aggregieren<\/strong>. Wenn Mikrodienste in der Cloud gehostet werden, ist der Cloud-Anbieter f\u00fcr die System\u00fcberwachung verantwortlich. Wenn Mikrodienste auf eigener Hardware betrieben werden, m\u00fcssen neben den Logs der Container auch die Systemlogs gesammelt werden.<\/p>\n

<\/p>\n

Fr\u00fcher gab es keine geeigneten Werkzeuge zur Sammlung von Logs sowohl vom System als auch von Mikrodiensten. \u00dcblicherweise sammelte ein Werkzeug die Systemlogs (zum Beispiel Rsyslog), ein anderes die Logs von Docker (zum Beispiel journal-bit mit der Konfiguration des Log-Treibers Docker auf journald). Wir haben versucht, journal-bit zu verwenden - Logs sowohl von Containern (im Log-Treiber Docker angeben, dass die Logs in journald geschrieben werden sollen) als auch vom System (in CentOS 7 gibt es bereits systemd und journald). Die L\u00f6sung funktioniert, ist aber nicht ideal. Wenn es viele Logs gibt, beginnt journal-bit zu laggen, und Nachrichten gehen verloren.<\/p>\n

<\/p>\n

Die Experimente setzten sich fort - und es fand sich ein anderer Weg. In CentOS 7 werden die Haupt-Systemlogs (messages, audit, secure) im var-Log in Form von Dateien dupliziert. Auch in Docker kann man das Speichern von Logs in JSON-Dateien einrichten. Entsprechend k\u00f6nnen diese Dateien aus CentOS 7 und Docker zusammen gesammelt werden.<\/p>\n

<\/p>\n

Mit der Zeit wurde die L\u00f6sung ELK Stack popul\u00e4r. Dies ist eine Kombination mehrerer Werkzeuge: Elasticsearch, Logstash und Kibana.<\/p>\n

<\/p>\n

Elasticsearch speichert die Logs von Containern, Logstash sammelt die Logs von Instanzen, Kibana erm\u00f6glicht die Verarbeitung der gesammelten Logs und das Erstellen von Grafiken. Eine Zeit lang wurde ELK Stack intensiv genutzt, aber meiner Meinung nach ist seine Zeit vorbei. Sp\u00e4ter werde ich erkl\u00e4ren, warum.<\/p>\n

<\/p>\n

Metadaten hinzuf\u00fcgen<\/strong>. Pods, Anwendungen und Container k\u00f6nnen \u00fcberall gestartet werden. Dar\u00fcber hinaus kann eine Anwendung mehrere Instanzen haben. Die Protokolle werden in einem einheitlichen Format aufgezeichnet, und wir m\u00fcssen verstehen, welche Kopie es ist, welcher Pod sie schreibt und in welchem Namespace er sich befindet. Genau aus diesem Grund m\u00fcssen den Protokollen Metadaten hinzugef\u00fcgt werden.<\/p>\n

<\/p>\n

Protokolle analysieren<\/strong>. Lustig, aber die Kosten f\u00fcr die Unterst\u00fctzung eines Protokollierungs- und \u00dcberwachungssystems k\u00f6nnen die Ausgaben f\u00fcr die Hauptanwendung \u00fcbersteigen. Wenn Sie Dutzende und Hunderte von Tausenden von Protokollen pro Sekunde haben, erscheint das logisch, aber man muss trotzdem die Grenze kennen. Eine M\u00f6glichkeit, diese Grenze zu finden, ist die Protokollanalyse. <\/p>\n

<\/p>\n

In der Regel ist es nicht notwendig, alle Protokolle zu sammeln und zu speichern; es sollte nur ein Teil zur Speicherung gesendet werden \u2013 beispielsweise Protokolle mit dem Status \u201eWarnung\u201c oder \u201eFehler\u201c. Wenn es um Protokolle von nginx oder Ingress-Controllern geht, k\u00f6nnen nur die Protokolle zur Speicherung gesendet werden, deren Status von 200 abweicht. Aber das ist kein universeller Rat: Wenn Sie irgendwie eine Analyse der Nginx-Protokolle erstellen, ist es offensichtlich sinnvoll, sie zu sammeln. <\/p>\n

<\/p>\n

Es wird nicht empfohlen, Protokolle gedankenlos zu filtern, da m\u00f6glicherweise nicht gen\u00fcgend gefilterte Daten f\u00fcr eine ordentliche Analyse vorhanden sind. Andererseits k\u00f6nnte die Analyse sinnvoller sein, nicht auf Protokollierungsebene, sondern auf Metrikebene durchzuf\u00fchren. Dann m\u00fcssen nicht Hunderte von Tausenden von Zeilen mit dem Code 200 gespeichert werden. Ein Ansatz besteht darin, Informationen \u00fcber den Traffic und Fehler aus den Metriken der Ingress-Controller zu erhalten. <\/p>\n

<\/p>\n

Insgesamt muss man hier gut \u00fcberlegen, was man speichern m\u00f6chte und wie lange, denn sonst kann es zu einer Situation kommen, in der das Protokollierungssystem mehr Ressourcen beansprucht als das Hauptprojekt.<\/p>\n

<\/p>\n

Es gibt derzeit keine Standardl\u00f6sung f\u00fcr die Protokollierung<\/strong>. Im Gegensatz zur \u00dcberwachung, wo es eine am weitesten verbreitete L\u00f6sung (Prometheus) gibt, gibt es keinen Standard bei der Protokollierung. <\/p>\n

<\/p>\n

In diesem Vortrag werden wir zwei Tools betrachten: eines ist popul\u00e4r, das andere gewinnt an Popularit\u00e4t. Abgesehen davon gibt es noch andere, aber in diesem Artikel werden wir nicht darauf eingehen.<\/p>\n

<\/p>\n

Unter Ber\u00fccksichtigung aller oben genannten Merkmale kann die Protokollierung in Kubernetes nun so dargestellt werden:<\/p>\n

<\/p>\n

\"Protokollierung<\/p>\n

<\/p>\n

Es bleibt das Containerprotokoll, die Rotation, aber es gibt einen Sammler-Agenten, der die Protokolle erfasst und zur Speicherung sendet (in der Abbildung \u2013 in das Logging Backend). Der Agent l\u00e4uft auf jedem Knoten und wird in der Regel in Kubernetes gestartet.<\/p>\n

<\/p>\n

Jetzt betrachten wir die Werkzeuge f\u00fcr das Logging.<\/p>\n

<\/p>\n

\u2014 unserem neuen Log-Aggregationssystem \u2014 das sichergestellt hat, dass alle Ingester sich w\u00e4hrend und nach dem Ausfall ordnungsgem\u00e4\u00df verhalten haben.<\/h2>\n

<\/p>\n

\u2014 unserem neuen Log-Aggregationssystem \u2014 das sichergestellt hat, dass alle Ingester sich w\u00e4hrend und nach dem Ausfall ordnungsgem\u00e4\u00df verhalten haben.<\/a><\/noindex> ist k\u00fcrzlich erschienen, hat sich aber bereits recht bekannt gemacht. Seine Vorteile: leicht zu installieren, verbraucht wenig Ressourcen, erfordert keine Elasticsearch-Installation, da er Daten in einer TSDB (time series database) speichert. In dem fr\u00fcheren Artikel habe ich erw\u00e4hnt, dass Prometheus Daten in einer solchen Datenbank speichert, und das ist eine der zahlreichen \u00c4hnlichkeiten zwischen beiden Produkten. Die Entwickler behaupten sogar, dass Loki \"Prometheus f\u00fcr die Logging-Welt\" ist.<\/p>\n

<\/p>\n

Eine kleine Abweichung zur TSDB f\u00fcr diejenigen, die noch nicht gelesen haben. den vorherigen Artikel<\/a><\/noindex>: TSDB bew\u00e4ltigt hervorragend die Aufgabe, gro\u00dfe Datenmengen und Zeitreihen zu speichern, ist jedoch nicht f\u00fcr die langfristige Speicherung gedacht. Wenn Sie aus irgendeinem Grund Logs l\u00e4nger als zwei Wochen aufbewahren m\u00fcssen, ist es besser, deren \u00dcbertragung in eine andere Datenbank einzurichten.<\/p>\n

<\/p>\n

Ein weiterer Vorteil von Loki ist, dass Grafana zur Visualisierung der Daten verwendet wird. Sehr praktisch: In Grafana sehen wir die \u00dcberwachungsdaten und k\u00f6nnen dort auch, verbunden mit Loki, die Logs ansehen. Aus den Logs k\u00f6nnen Grafiken erstellt werden.<\/p>\n

<\/p>\n

Die Architektur von Loki sieht ungef\u00e4hr so aus: <\/p>\n

<\/p>\n

\"Protokollierung<\/p>\n

<\/p>\n

Mit Hilfe von DaemonSet wird auf allen Servern des Clusters ein Agent - Promtail oder Fluent Bit - bereitgestellt. Der Agent sammelt die Logs. Loki holt sie ab und speichert sie in seiner TSDB. Den Logs werden sofort Metadaten hinzugef\u00fcgt, was praktisch ist: man kann nach Pods, Namespaces, Container-Namen und sogar Labels filtern.<\/p>\n

<\/p>\n

Installationsanleitung f\u00fcr Loki<\/a><\/noindex><\/p>\n

<\/p>\n

Loki funktioniert in der vertrauten Oberfl\u00e4che von Grafana. Loki hat sogar eine eigene Abfragesprache, die LogQL hei\u00dft - benannt nach und im Syntax \u00e4hnlich zu PromQL in Prometheus. In der Loki-Oberfl\u00e4che gibt es Vorschl\u00e4ge f\u00fcr Abfragen, sodass man sie nicht auswendig wissen muss.<\/p>\n

<\/p>\n

Dokumentation zur Sprache LogQL<\/a><\/noindex><\/p>\n

<\/p>\n

\"Protokollierung
\nLoki in der Grafana-Oberfl\u00e4che<\/em><\/p>\n

<\/p>\n

Mit Hilfe von Filtern kann man in Loki Codes finden (\"400\", \"404\" und jeden anderen); die Logs von der gesamten Node einsehen; alle Logs filtern, die das Wort \"error\" enthalten. Wenn man auf das Log klickt, wird eine Karte mit allen Informationen zum Ereignis angezeigt.<\/p>\n

<\/p>\n

In Loki gibt es gen\u00fcgend Werkzeuge, die es erm\u00f6glichen, die gew\u00fcnschten Logs zu extrahieren, obwohl es technisch gesehen ehrlich gesagt auch mehr sein k\u00f6nnten. Momentan entwickelt sich Loki aktiv und gewinnt an Popularit\u00e4t. <\/p>\n

<\/p>\n

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

<\/p>\n

Der EFK-Stack ist ein klassisches, nicht weniger beliebtes Logging-Tool. <\/p>\n

<\/p>\n

Zu Beginn des Artikels wurde ELK (Elasticsearch + Logstash + Kibana) erw\u00e4hnt, jedoch ist dieser Stack aufgrund von Logstash, das nicht sehr leistungsf\u00e4hig und gleichzeitig ressourcenintensiv ist, veraltet. An seiner Stelle wird jetzt der leichtere und leistungsf\u00e4higere Fluentd verwendet, und nach einer gewissen Zeit kam ihm zur Hilfe Fluent Bit<\/a><\/noindex> \u2014 ein noch leichterer und noch leistungsf\u00e4higerer Log-Collector. <\/p>\n

<\/p>\n

Wenn man den Entwicklern Glauben schenken darf, dann ist Fluent Bit mehr als 100 Mal besser in der Leistung als Fluentd: \u201ewo Fluentd 20 MB RAM verbraucht, wird Fluent Bit 150 KB verbrauchen\u201c \u2014 ein w\u00f6rtliches Zitat aus der Dokumentation. In Anbetracht dessen wird Fluent Bit h\u00e4ufiger verwendet.<\/p>\n

<\/p>\n

Fluent Bit hat weniger Funktionen als Fluentd, deckt jedoch die grundlegenden Anforderungen ab, weshalb wir haupts\u00e4chlich Fluent Bit nutzen.<\/p>\n

<\/p>\n

Das Schema der EFK-Architektur: Der Agent sammelt Logs von allen Pods (in der Regel handelt es sich um ein DaemonSet, das auf allen Servern des Clusters l\u00e4uft) und sendet sie an den Speicher (Elasticsearch, PostgreSQL oder Kafka). Kibana verbindet sich mit dem Speicher und ruft alle erforderlichen Informationen ab.<\/p>\n

<\/p>\n

\"Protokollierung<\/p>\n

<\/p>\n

Kibana<\/a><\/noindex> stellt die Informationen in einer benutzerfreundlichen Weboberfl\u00e4che dar. Es gibt Grafiken, Filter und vieles mehr.<\/p>\n

<\/p>\n

\"Protokollierung<\/p>\n

<\/p>\n

Anhand der Logs k\u00f6nnen ganze Dashboards erstellt werden.<\/p>\n

<\/p>\n

\"Protokollierung<\/p>\n

<\/p>\n

Die M\u00f6glichkeiten von Fluent Bit<\/h2>\n

<\/p>\n

Da \u00fcber Fluent Bit in der Regel weniger bekannt ist als \u00fcber Logstash, betrachten wir ihn etwas genauer. Fluent Bit l\u00e4sst sich logisch in 6 Module unterteilen, auf einige Module k\u00f6nnen Plugins aufgesetzt werden, die die Funktionen von Fluent Bit erweitern.<\/p>\n

<\/p>\n

\"Protokollierung<\/p>\n

<\/p>\n

Input-Modul<\/strong> sammelt Logs aus Dateien, systemd-Diensten und sogar aus TCP-Sockets (man muss nur den Endpoint angeben, und Fluent Bit beginnt, dort zu holen). Diese M\u00f6glichkeiten sind ausreichend, um Logs sowohl vom System als auch von Containern zu sammeln.<\/p>\n

<\/p>\n

In der Produktion verwenden wir am h\u00e4ufigsten die Plugins tail<\/a><\/noindex> (man kann es auf einen Ordner mit Logs richten) und systemd<\/a><\/noindex> (man kann ihm sagen, aus welchen Diensten Logs gesammelt werden sollen).<\/p>\n

<\/p>\n

Parser-Modul<\/strong> formatiert die Logs einheitlich. Standardm\u00e4\u00dfig sind Nginx-Logs eine Zeichenkette. Mit Hilfe eines Plugins kann diese Zeichenkette in JSON umgewandelt werden: Felder und deren Werte k\u00f6nnen definiert werden. Mit JSON l\u00e4sst sich viel einfacher arbeiten als mit stringbasierten Logs, da es flexiblere M\u00f6glichkeiten zur Sortierung bietet.<\/p>\n

<\/p>\n

Filter-Modul<\/strong>. Auf dieser Ebene werden unn\u00f6tige Logs herausgefiltert. Zum Beispiel werden nur Logs mit dem Wert \u201ewarning\u201c oder bestimmten Labels zum Speichern gesendet. Die ausgew\u00e4hlten Logs gelangen in einen Puffer.<\/p>\n

<\/p>\n

Buffer-Modul<\/strong>. Fluent Bit hat zwei Arten von Buffern: einen Speicher- und einen Festplattenspeicher. Ein Buffer ist ein vor\u00fcbergehender Speicher f\u00fcr Logs, der im Falle von Fehlern oder Ausf\u00e4llen ben\u00f6tigt wird. Jeder m\u00f6chte RAM sparen, daher w\u00e4hlt man in der Regel den Festplattenspeicher. Es ist jedoch zu beachten, dass Logs vor dem Speichern auf der Festplatte zun\u00e4chst im Speicher abgelegt werden.<\/p>\n

<\/p>\n

Modul Routing\/Output<\/strong> enth\u00e4lt Regeln und Adressen zum Versenden von Logs. Wie bereits erw\u00e4hnt, k\u00f6nnen Logs an Elasticsearch, PostgreSQL oder beispielsweise Kafka gesendet werden. <\/p>\n

<\/p>\n

Interessant ist, dass Logs von Fluent Bit auch an Fluentd gesendet werden k\u00f6nnen. Da das erste leichter und weniger funktional ist, kann man Logs dar\u00fcber sammeln und an Fluentd senden, wo sie dann mit zus\u00e4tzlichen Plugins weiterverarbeitet und in Speicher abgelegt werden.<\/p>\n

<\/p>\n

Wenn Sie vorhaben, Elasticsearch zu verwenden\u2026<\/p>\n

Zuletzt zwei Tipps f\u00fcr diejenigen, die Elasticsearch als Log-Speicher in der Produktion verwenden m\u00f6chten. <\/p>\n

    \n
  1. Richten Sie Benachrichtigungen mit Hilfe von ElastAlert<\/a><\/noindex>ein. Dieses Programm extrahiert wichtige Nachrichten aus dem allgemeinen Log-Stream und erstellt Alarme f\u00fcr E-Mail oder andere Kan\u00e4le. Allerdings gab es vor nicht allzu langer Zeit eine traurige Nachricht, dass das Projekt m\u00f6glicherweise bald eingestellt wird.<\/a><\/noindex><\/em>.<\/li>\n
  2. Rotieren Sie Logs mit Hilfe der Anwendung Curator<\/a><\/noindex> oder durch die API von Elasticsearch. Elastic unternimmt derzeit erhebliche Schritte zur Verwaltung des Lebenszyklus von Indizes ohne Verwendung dritter Werkzeuge. Es macht insgesamt wenig Sinn, Logs lange zu speichern: es ist eher unwahrscheinlich, dass ein Log nach zwei Wochen ben\u00f6tigt wird \u2013 wenn es wirklich kritisch ist, wird es innerhalb von zwei Wochen in jedem Fall bearbeitet. Im \u00e4u\u00dfersten Fall k\u00f6nnen alte Logs archiviert und an einen Ort f\u00fcr die Langzeitaufbewahrung gesendet werden. Ich habe von speziellen Logs geh\u00f6rt, die gesetzlich bis zu 5 Jahre aufbewahrt werden m\u00fcssen. Damit habe ich pers\u00f6nlich keine Erfahrung, aber ich w\u00fcrde solche Informationen nicht mit normalen Logs gleichsetzen und sie m\u00f6glicherweise sogar getrennt aufbewahren.<\/li>\n<\/ol>\n

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

    Fortsetzung folgt\u2026<\/p>\n

    <\/p>\n

    Autor: Marsel Ibraev, zertifizierter Kubernetes-Administrator, praktizierender Ingenieur bei der Firma Southbridge<\/a><\/noindex>, Redner und Entwickler von Kursen Slurm<\/a><\/noindex>.<\/em><\/p>\n

    Quelle: 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\udd47Logging in Kubernetes: wie man Logs sammelt, speichert, analysiert und verarbeitet | ProHoster","description":"Wir werden die Grundlagen des Loggings in Docker und Kubernetes besprechen und dann zwei Werkzeuge betrachten, die man bedenkenlos in der Produktion einsetzen kann: Grafana Loki und den EFK-Stack (Elasticsearch + Fluent Bit + Kibana)..","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/93294","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=93294"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/93294\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/93295"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=93294"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=93294"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=93294"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}