{"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\/da\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","title":{"rendered":"Logning i Kubernetes: hvordan man indsamler, opbevarer, parser og behandler logs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Vi gennemg\u00e5r grundl\u00e6ggende logning i Docker og Kubernetes og ser derefter p\u00e5 to v\u00e6rkt\u00f8jer, der kan anvendes i produktionen: Grafana Loki og EFK-stakken (Elasticsearch + Fluent Bit + Kibana).<\/p>\n

<\/p>\n

Materialet i artiklen er et uddrag fra den \u00e5bne forel\u00e6sning fra skolen \"Slyrm\"<\/a><\/noindex>. Hvis der er interesse, og endnu mere volumen skal der til, kan man tage et fuldt kursus \u2014 tilmeld dig kursuset om Overv\u00e5gning og logning af infrastruktur i Kubernetes<\/a><\/noindex>.<\/em><\/p>\n

<\/p>\n

\"Logning<\/p>\n

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

Logning i Docker<\/h2>\n

<\/p>\n

P\u00e5 Kubernetes-niveauet k\u00f8res applikationer i pods, men p\u00e5 et lavere niveau fungerer de stadig typisk i Docker. Derfor skal logning konfigureres s\u00e5ledes, at logs indsamles fra containere. Containere startes af Docker \u2014 derfor skal man forst\u00e5, hvordan logning fungerer p\u00e5 Docker-niveauet.<\/p>\n

<\/p>\n

Jeg h\u00e5ber, at hver l\u00e6ser ved: applikationens logs skal skrives til stdout\/stderr, og ikke ind i containeren. Logs aggregeres af Docker Daemon, og den arbejder kun med de logs, der sendes til stdout\/stderr. Derudover kan det at skrive logs ind i containeren f\u00f8re til problemer: containeren bliver tung af de voksende logs (da der formentlig ikke er nogen Logrotate i containeren), og Docker Daemon har ikke kendskab til denne log.<\/p>\n

<\/p>\n

Docker har flere logdrivere eller plugins til at samle logs fra containere. I den gratis Docker Community Edition (CE) er der f\u00e6rre logdrivere end i den kommercielle Docker Enterprise Edition (EE).<\/p>\n

<\/p>\n

\"Logning<\/p>\n

<\/p>\n

Jeg har aldrig brugt Docker EE i praksis: hos Southbridge fors\u00f8ger vi at holde os til Open Source-l\u00f8sninger, og de fleste af de ekstra funktioner i Docker EE er ikke n\u00f8dvendige for kunderne. <\/p>\n

<\/p>\n

Logdrivere i Docker CE:<\/p>\n

<\/p>\n

local<\/strong> \u2014 registrering af logs i Docker Daemons interne filer;
\njson-file<\/strong> \u2014 oprettelse af json-log i hver containers mappe;
\njournald<\/strong> \u2014 sending logs til journald.<\/p>\n

<\/p>\n

Indstillingerne for logning i Docker findes i filen daemon.json. <\/p>\n

<\/p>\n

I feltet \"log-driver\" angiver man pluginet, og i feltet \"log-opts\" angiver man dets indstillinger. I eksemplet ovenfor er pluginet \"json-file\" angivet, logst\u00f8rrelsesgr\u00e6nsen er \"max-size\": \"10m\"; gr\u00e6nsen for antallet af filer (roteringsindstillinger) er \"max-file\": \"3\"; samt v\u00e6rdier, der vil blive knyttet til logs.<\/p>\n

<\/p>\n

\"Logning<\/p>\n

<\/p>\n

Nogle indstillinger for logdrivere kan angives via kommandolinjev\u00e6rkt\u00f8jet. Dette er praktisk, hvis en bestemt container skal startes med en anden logdriver. <\/p>\n

<\/p>\n

S\u00e5dan ser logningsskemaet i Docker ud:<\/p>\n

<\/p>\n

\"Logning<\/p>\n

<\/p>\n

Hvordan skemaet fungerer: log-driveren, for eksempel json-file, opretter filer. Log-samlere (Rsyslog, Fluentd, Logagent og andre) indsamler disse filer og sender dem til opbevaring i Elastic, Sematext eller andre lagringssteder.<\/p>\n

<\/p>\n

Funktioner ved logning i Kubernetes<\/h2>\n

<\/p>\n

Forenklet ser logningsskemaet i Kubernetes s\u00e5ledes ud: der er en pod, i hvilken der k\u00f8rer en container, containeren sender logs til stdout\/stderr. Derefter opretter Docker en fil og registrerer loggene, som derefter kan roteres.<\/p>\n

<\/p>\n

\"Logning<\/p>\n

<\/p>\n

Lad os se p\u00e5 funktionerne ved logning i Kubernetes.<\/p>\n

<\/p>\n

Bevare loggene mellem deployment<\/strong>. Det er et obligatorisk krav for korrekt ops\u00e6tning af logning. Hvis man ikke gemmer logs mellem deployment, vil logs fra den tidligere version af applikationen blive overskrevet ved udgivelsen af en ny version, og genstart af containeren vil ogs\u00e5 medf\u00f8re tab af logs. Kubernetes har en n\u00f8gle \u2014previous, som g\u00f8r det muligt at se logs fra applikationen f\u00f8r den seneste genstart af Pod'en, men ikke dybere.<\/p>\n

<\/p>\n

Aggregere logs fra alle instanser<\/strong>. Hvis mikrotjenesterne hostes i skyen, er det cloud-udbyderen, der st\u00e5r for systemoverv\u00e5gningen. Hvis mikrotjenesterne k\u00f8rer p\u00e5 egen hardware, skal man ud over logs fra containerne ogs\u00e5 samle systemlogs.<\/p>\n

<\/p>\n

Tidligere var der ikke gode v\u00e6rkt\u00f8jer til at indsamle logs fra b\u00e5de systemet og mikrotjenesterne. Som regel indsamlede et v\u00e6rkt\u00f8j systemlogs (for eksempel Rsyslog), mens et andet indsamlede logs fra Docker (for eksempel journal-bit med log-driver-konfigurationen indstillet til journald). Man pr\u00f8vede at bruge journal-bit \u2014 til at indsamle logs fra b\u00e5de containerne (i log-driveren fra Docker angive, at logs skal skrives til journald) og fra systemet (i CentOS 7 er der allerede systemd og journald). L\u00f8sningen er funktionel, men ikke perfekt. Hvis der er mange logs, begynder journal-bit at lagge, og beskeder g\u00e5r tabt.<\/p>\n

<\/p>\n

Eksperimenterne fortsatte \u2014 og der blev fundet en anden metode. I CentOS 7 bliver de prim\u00e6re systemlogs (messages, audit, secure) duplikeret i var-logs i filform. I Docker kan man ogs\u00e5 konfigurere loggene til at blive gemt i json-filer. Derfor kan disse filer fra CentOS 7 og Docker samles sammen.<\/p>\n

<\/p>\n

Over tid blev l\u00f8sningen ELK Stack popul\u00e6r. Det er en kombination af flere v\u00e6rkt\u00f8jer: Elasticsearch, Logstash og Kibana.<\/p>\n

<\/p>\n

Elasticsearch gemmer logs fra containerne, Logstash indsamler logs fra instanser, Kibana muligg\u00f8r behandling af de indsamlede logs og opbygning af grafer baseret p\u00e5 dem. I nogen tid blev ELK Stack aktivt brugt, men efter min mening er dens tid ved at v\u00e6re forbi. Jeg vil senere forklare hvorfor.<\/p>\n

<\/p>\n

Tilf\u00f8je metadata<\/strong>. Pods, apps og containere kan k\u00f8re hvor som helst. Desuden kan en applikation have flere instanser. Logfilerne bliver logget i et format, og vi skal forst\u00e5, hvilken replik det er, hvilken Pod der skriver, og hvilket namespace den befinder sig i. Derfor skal metadata tilf\u00f8jes til logfilerne.<\/p>\n

<\/p>\n

Parse logfiler<\/strong>. Det er sjovt, men omkostningerne til at underst\u00f8tte loggings- og overv\u00e5gningssystemet kan overstige omkostningerne til den prim\u00e6re applikation. N\u00e5r du har ti- og hundrede tusinde logs per sekund, virker det som en selvf\u00f8lge, men man skal stadig kende gr\u00e6nsen. En m\u00e5de at finde den gr\u00e6nse p\u00e5 er at parse logfiler. <\/p>\n

<\/p>\n

Som regel er det ikke n\u00f8dvendigt at samle og gemme alle logs, man b\u00f8r kun sende en del til gemmes, for eksempel logs med status 'warning' eller 'error'. Hvis det handler om logs fra nginx eller ingress-kontrollere, kan man kun sende dem til opbevaring, hvis statusen adskiller sig fra 200. Men det er ikke et universelt r\u00e5d: hvis du p\u00e5 en eller anden m\u00e5de bygger analyser baseret p\u00e5 logs fra Nginx, er det \u00e5benlyst, at de skal samles. <\/p>\n

<\/p>\n

Det anbefales ikke at filtrere logs tankel\u00f8st, fordi de filtrerede data muligvis ikke er tilstr\u00e6kkelige til normal analyse. P\u00e5 den anden side kan det v\u00e6re, at analysen b\u00f8r udf\u00f8res ikke p\u00e5 log-niveau, men p\u00e5 niveauet for metrics. S\u00e5 vil man ikke beh\u00f8ve at gemme hundredtusinder af linjer med kode 200. En tilgang er at f\u00e5 information om trafik og fejl fra metrics fra ingress-kontrollere. <\/p>\n

<\/p>\n

Generelt skal man t\u00e6nke grundigt over, hvad man \u00f8nsker at gemme, og hvor l\u00e6nge, fordi ellers kan man ende i en situation, hvor logningssystemet optager flere ressourcer end det prim\u00e6re projekt.<\/p>\n

<\/p>\n

Der er endnu ingen standardl\u00f8sning for logging<\/strong>. I mods\u00e6tning til overv\u00e5gning, hvor der er \u00e9n mest almindeligt anvendte l\u00f8sning, Prometheus, eksisterer der ingen standard for logging. <\/p>\n

<\/p>\n

I denne lektion vil vi se p\u00e5 to v\u00e6rkt\u00f8jer: et popul\u00e6rt og et andet, der vinder frem. Derudover findes der andre, men vi vil ikke ber\u00f8re dem i denne artikel.<\/p>\n

<\/p>\n

Tager man h\u00f8jde for alle de n\u00e6vnte aspekter, kan logging i Kubernetes nu fremvises i s\u00e5dan en skitse:<\/p>\n

<\/p>\n

\"Logning<\/p>\n

<\/p>\n

Containerens log er tilbage, rotation, men der tilf\u00f8jes en agent-samler, der henter logs og sender dem til opbevaring (i skitsen - til Logging Backend). Agenten k\u00f8rer p\u00e5 hver node og er normalt startet i Kubernetes.<\/p>\n

<\/p>\n

Lad os nu se p\u00e5 redskaberne til logf\u00f8ring.<\/p>\n

<\/p>\n

Grafana Loki<\/h2>\n

<\/p>\n

Grafana Loki<\/a><\/noindex> er relativt nyt, men er allerede blevet ret kendt. Dets fordele inkluderer: nem installation, lav ressourcetr\u00e6k og ingen n\u00f8dvendighed for at installere Elasticsearch, da det gemmer data i en TSDB (tidsseriedatabase). I den tidligere artikel skrev jeg, at Prometheus gemmer data i s\u00e5dan en database, og det er et af de mange ligheder mellem de to produkter. Udviklerne h\u00e6vder endda, at Loki er \"Prometheus for logverdenen.\"<\/p>\n

<\/p>\n

En kort bem\u00e6rkning om TSDB for dem, der ikke har l\u00e6st det. den forrige artikel<\/a><\/noindex>: TSDB h\u00e5ndterer opbevaring af store m\u00e6ngder data og tidsserier godt, men er ikke designet til langvarig opbevaring. Hvis du af en eller anden grund skal opbevare logs i mere end to uger, er det bedre at konfigurere deres overf\u00f8rsel til en anden database.<\/p>\n

<\/p>\n

En anden fordel ved Loki er, at Grafana bruges til visualisering af data. Meget praktisk: i Grafana ser vi data til overv\u00e5gning, og ved at tilslutte Loki kan vi ogs\u00e5 se logs. Gennem logs kan man opbygge grafer.<\/p>\n

<\/p>\n

Arkitekturen af Loki ser nogenlunde s\u00e5dan ud: <\/p>\n

<\/p>\n

\"Logning<\/p>\n

<\/p>\n

Ved hj\u00e6lp af DaemonSet deployeres en agent \u2013 Promtail eller Fluent Bit \u2013 p\u00e5 alle servere i klyngen. Agenten indsamler logs. Loki henter disse og opbevarer dem i TSDB. Metadata tilf\u00f8jes straks til logs, hvilket er praktisk: man kan filtrere efter Pods, namespaces, container-navne og endda labels.<\/p>\n

<\/p>\n

Vejledning til installation af Loki<\/a><\/noindex><\/p>\n

<\/p>\n

Loki fungerer i det velkendte Grafana-interface. Loki har endda sit eget foresp\u00f8rgselssprog, der hedder LogQL \u2013 navngivet og syntaktisk ligesom PromQL i Prometheus. I Loki's interface er der hints med foresp\u00f8rgsler, s\u00e5 man beh\u00f8ver ikke at l\u00e6re dem udenad.<\/p>\n

<\/p>\n

Dokumentation til sproget LogQL<\/a><\/noindex><\/p>\n

<\/p>\n

\"Logning
\nLoki i Grafana-interface<\/em><\/p>\n

<\/p>\n

Ved at bruge filtre kan man i Loki finde koder (\u201c400\u201d, \u201c404\u201d og enhver anden); se logs fra hele noden; eller filtrere alle logs, hvor ordet \u201cerror\u201d forekommer. Hvis man klikker p\u00e5 en log, \u00e5bnes et kort med alle oplysninger om begivenheden.<\/p>\n

<\/p>\n

Loki har de n\u00f8dvendige v\u00e6rkt\u00f8jer til at tr\u00e6kke de \u00f8nskede logs, selvom jeg \u00e6rligt talt kunne have \u00f8nsket flere tekniske funktioner. Loki udvikler sig aktivt og vinder popularitet. <\/p>\n

<\/p>\n

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

<\/p>\n

EFK Stack er et mere klassisk, men stadig popul\u00e6rt logf\u00f8ring v\u00e6rkt\u00f8j. <\/p>\n

<\/p>\n

I begyndelsen af artiklen blev ELK-stakken (Elasticsearch + Logstash + Kibana) n\u00e6vnt, men denne stak er blevet for\u00e6ldet p\u00e5 grund af den ikke s\u00e6rlig effektive og samtidig ressourcekr\u00e6vende Logstash. I stedet er der blevet brugt den lettere og mere effektive Fluentd, og efter et stykke tid kom der ogs\u00e5 hj\u00e6lp til den. Fluent Bit<\/a><\/noindex> \u2014 en endnu lettere og endnu mere effektiv indsamler-agent. <\/p>\n

<\/p>\n

Hvis man skal tro udviklerne, s\u00e5 er Fluent Bit mere end 100 gange bedre med hensyn til ydeevne end Fluentd: \u00abder, hvor Fluentd bruger 20 MB RAM, vil Fluent Bit bruge 150 KB\u00bb \u2014 et direkte citat fra dokumentationen. I lyset af dette er Fluent Bit blevet brugt oftere.<\/p>\n

<\/p>\n

Fluent Bit har f\u00e6rre funktioner end Fluentd, men de grundl\u00e6ggende behov d\u00e6kkes, s\u00e5 vi bruger hovedsageligt Fluent Bit.<\/p>\n

<\/p>\n

Arbejdsschemaet for EFK-stakken: agenten indsamler logs fra alle pods (normalt en DaemonSet, der k\u00f8rer p\u00e5 alle servere i klyngen) og sender dem til lageret (Elasticsearch, PostgreSQL eller Kafka). Kibana forbinder til lageret og henter alle de n\u00f8dvendige oplysninger derfra.<\/p>\n

<\/p>\n

\"Logning<\/p>\n

<\/p>\n

Kibana<\/a><\/noindex> pr\u00e6senterer oplysningerne i et brugervenligt webinterface. Der er diagrammer, filtre og meget mere.<\/p>\n

<\/p>\n

\"Logning<\/p>\n

<\/p>\n

P\u00e5 baggrund af logs kan man oprette hele dashboards.<\/p>\n

<\/p>\n

\"Logning<\/p>\n

<\/p>\n

Mulighederne i Fluent Bit<\/h2>\n

<\/p>\n

Da Fluent Bit som regel er mindre kendt end Logstash, vil vi se n\u00e6rmere p\u00e5 det. Fluent Bit kan logisk opdeles i 6 moduler, hvor nogle moduler kan have plugins, som udvider mulighederne for Fluent Bit.<\/p>\n

<\/p>\n

\"Logning<\/p>\n

<\/p>\n

Input-modulet<\/strong> indsamler logs fra filer, systemd-tjenester og endda fra tcp-socket (man skal blot angive endpoint, og Fluent Bit vil begynde at hente data derfra). Disse funktioner er tilstr\u00e6kkelige til at indsamle logs fra b\u00e5de systemet og containere.<\/p>\n

<\/p>\n

I produktionen bruger vi oftest plugins tail<\/a><\/noindex> (man kan pege den p\u00e5 en mappe med logs) og systemd<\/a><\/noindex> (man kan angive, fra hvilke tjenester der skal indsamles logs).<\/p>\n

<\/p>\n

Parser-modulet<\/strong> normaliserer logs. Som standard repr\u00e6senterer Nginx-logs en streng. Ved hj\u00e6lp af en plugin kan man omdanne denne streng til JSON: definere felter og deres v\u00e6rdier. At arbejde med JSON er meget nemmere end med streng-logs, fordi der er mere fleksible sorteringsmuligheder.<\/p>\n

<\/p>\n

Filter-modulet<\/strong>. P\u00e5 dette niveau filtreres un\u00f8dvendige logs fra. For eksempel sendes kun logs med v\u00e6rdien \"warn\" eller med bestemte labels til opbevaring. De udvalgte logs g\u00e5r ind i bufferen.<\/p>\n

<\/p>\n

Buffer-modulet<\/strong>. Fluent Bit har to typer buffere: hukommelsesbuffer og diskbuffer. Buffered er et midlertidigt lager til logs, der er n\u00f8dvendigt i tilf\u00e6lde af fejl eller nedbrud. Alle \u00f8nsker at spare p\u00e5 RAM, s\u00e5 man v\u00e6lger normalt diskbufferen. Men det er vigtigt at overveje, at logs stadig skrives til hukommelsen, f\u00f8r de g\u00e5r til disken.<\/p>\n

<\/p>\n

Routing\/Output-modul<\/strong> indeholder regler og adresser for sending af logs. Som n\u00e6vnt kan logs sendes til Elasticsearch, PostgreSQL eller f.eks. Kafka. <\/p>\n

<\/p>\n

Interessant nok kan logs fra Fluent Bit sendes til Fluentd. Da den f\u00f8rste er lettere og mindre funktionel, kan man samle logs og sende dem til Fluentd, hvor de derefter kan behandles yderligere og sendes til lagringssystemer ved hj\u00e6lp af ekstra plugins.<\/p>\n

<\/p>\n

Hvis du planl\u00e6gger at bruge Elasticsearch\u2026<\/p>\n

Til sidst to r\u00e5d til dem, der planl\u00e6gger at bruge Elasticsearch som loglager i produktion. <\/p>\n

    \n
  1. Indstil alarmer ved hj\u00e6lp af ElastAlert<\/a><\/noindex>. Dette program udtr\u00e6kker vigtige meddelelser fra den samlede logstr\u00f8m og opretter alarmer via e-mail eller en anden kanal. Dog er der for nylig kommet den triste nyhed om, at projektet kan stoppe med at eksistere<\/a><\/noindex><\/em>.<\/li>\n
  2. Rot\u00e9r logs ved hj\u00e6lp af applikationen Curator<\/a><\/noindex> eller ved at tilg\u00e5 Elasticsearch API. Elastic tager for alvor skridt til at styre livscyklussen af indekser uden tredjeparts v\u00e6rkt\u00f8jer. Generelt set giver det ikke mening at opbevare logs i lang tid: Det er usandsynligt, at nogen log vil v\u00e6re n\u00f8dvendigt efter to uger \u2014 hvis den er virkelig kritisk, vil den helt sikkert v\u00e6re blevet h\u00e5ndteret inden for to uger. I v\u00e6rste fald kan gamle logs arkiveres og opbevares et sted til langtidslagring. Jeg har h\u00f8rt om specifikke logs, der if\u00f8lge loven skal opbevares i op til 5 \u00e5r. Personligt har jeg ikke oplevet det, men jeg ville ikke sammenligne disse logs med almindelige logs, og jeg ville muligvis endda opbevare dem separat.<\/li>\n<\/ol>\n

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

    Forts\u00e6ttelsen f\u00f8lger\u2026<\/p>\n

    <\/p>\n

    Forfatter: Marsel Ibraev, certificeret Kubernetes-administrator, praktiserende ingeni\u00f8r i firmaet Southbridge<\/a><\/noindex>, taler og kursusudvikler Sl\u00f8rm<\/a><\/noindex>.<\/em><\/p>\n

    Kilde: 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\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 i Kubernetes: hvordan man indsamler, opbevarer, parser og behandler logfiler | ProHoster","description":"Lad os gennemg\u00e5 grundene til logf\u00f8ring i Docker og Kubernetes, og derefter se p\u00e5 to v\u00e6rkt\u00f8jer, der trygt kan bruges i produktionen: Grafana Loki og EFK-stakken (Elasticsearch + Fluent Bit + Kibana)..","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/logirovanie-v-kubernetes-kak-sobirat-hranit-parsit-i-obrabatyvat-logi","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/93294","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=93294"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/93294\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/93295"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=93294"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=93294"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=93294"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}