{"id":89038,"date":"2020-07-17T19:42:30","date_gmt":"2020-07-17T17:42:30","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/logirovanie-v-kubernetes-efk-protiv-plg"},"modified":"2020-07-17T19:42:30","modified_gmt":"2020-07-17T17:42:30","slug":"logirovanie-v-kubernetes-efk-protiv-plg","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/logirovanie-v-kubernetes-efk-protiv-plg","title":{"rendered":"Logowanie w Kubernetes: EFK przeciwko PLG","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Logowanie<\/p>\n

<\/p>\n

Monitorowanie sta\u0142o si\u0119 bardzo wa\u017cnym elementem rozwijaj\u0105cych si\u0119 rozwi\u0105za\u0144 chmurowych w miar\u0119 wzrostu z\u0142o\u017cono\u015bci system\u00f3w rozproszonych. Jest niezb\u0119dne do zrozumienia ich zachowania. Potrzebne s\u0105 skalowalne narz\u0119dzia, kt\u00f3re b\u0119d\u0105 w stanie zbiera\u0107 dane z wszystkich us\u0142ug \u2014 i zapewni\u0107 specjalistom jedyny interfejs z analiz\u0105 wydajno\u015bci, prezentacj\u0105 b\u0142\u0119d\u00f3w, dost\u0119pno\u015bci\u0105 i logami. <\/p>\n

<\/p>\n

Te same narz\u0119dzia powinny by\u0107 efektywne i wydajne. W tym artykule om\u00f3wimy dwa popularne zestawy technologii: EFK (Elasticsearch) i PLG (Loki) oraz przeanalizujemy ich architektury i r\u00f3\u017cnice.<\/p>\n

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

Zestaw EFK<\/h2>\n

<\/p>\n

By\u0107 mo\u017ce s\u0142ysza\u0142e\u015b o bardzo popularnym ELK lub EFK. Zestaw sk\u0142ada si\u0119 z kilku oddzielnych cz\u0119\u015bci: Elasticsearch (obiektowe magazynowanie), Logstash lub FluentD (zbieranie i agregacja log\u00f3w) oraz Kibana do wizualizacji.<\/p>\n

<\/p>\n

Typowy schemat dzia\u0142ania wygl\u0105da tak:<\/p>\n

<\/p>\n

\"Logowanie<\/p>\n

<\/p>\n

Elasticsearch<\/strong> \u2014 rozproszone obiektowe magazynowanie z wyszukiwaniem i analiz\u0105 w czasie rzeczywistym. Doskona\u0142e rozwi\u0105zanie dla cz\u0119\u015bciowo z\u0142o\u017conych danych, takich jak logi. Informacje s\u0105 przechowywane w postaci dokument\u00f3w JSON, indeksowane w czasie rzeczywistym i rozdzielane po w\u0119z\u0142ach klastra. U\u017cywany jest indeks odwr\u00f3cony, kt\u00f3ry zawiera wszystkie unikalne s\u0142owa i powi\u0105zane z nimi dokumenty do wyszukiwania pe\u0142notekstowego, kt\u00f3re z kolei opiera si\u0119 na silniku wyszukiwania Apache Lucene.<\/p>\n

<\/p>\n

FluentD<\/strong> \u2014 to zbieracz danych, kt\u00f3ry wykonuje unifikacj\u0119 danych podczas ich zbierania i konsumowania. Stara si\u0119 uporz\u0105dkowa\u0107 dane w JSON, w miar\u0119 mo\u017cliwo\u015bci. Jego architektura jest rozszerzalna, istnieje wi\u0119cej ni\u017c setek r\u00f3\u017cnych rozszerze\u0144<\/a><\/noindex>, wspieranych przez spo\u0142eczno\u015b\u0107, na wszelkie okazje.<\/p>\n

<\/p>\n

Kibana<\/strong> \u2014 narz\u0119dzie wizualizacji danych dla Elasticsearch z r\u00f3\u017cnymi dodatkowymi mo\u017cliwo\u015bciami, takimi jak analiza szereg\u00f3w czasowych, grafami, uczeniem maszynowym i innymi.<\/p>\n

<\/p>\n

Architektura Elasticsearch<\/h3>\n

<\/p>\n

Dane klastra Elasticsearch s\u0105 przechowywane rozproszone na wszystkich jego w\u0119z\u0142ach. Klastr sk\u0142ada si\u0119 z kilku w\u0119z\u0142\u00f3w w celu zwi\u0119kszenia dost\u0119pno\u015bci i odporno\u015bci. Ka\u017cdy w\u0119ze\u0142 mo\u017ce pe\u0142ni\u0107 wszystkie role klastra, ale w du\u017cych, skalowalnych wdro\u017ceniach w\u0119z\u0142om zazwyczaj przypisywane s\u0105 oddzielne zadania.<\/p>\n

<\/p>\n

Typy w\u0119z\u0142\u00f3w klastra:<\/p>\n

<\/p>\n