Zarządzanie dziennikami Linuksa

najlepszą praktyką rejestrowania jest centralizacja lub agregacja dzienników w jednej lokalizacji, zwłaszcza jeśli masz wiele serwerów lub warstw architektury. Nowoczesne aplikacje często mają wiele warstw infrastruktury, które mogą obejmować mieszankę serwerów lokalnych i usług w chmurze. Próba znalezienia odpowiedniego pliku w celu rozwiązania błędu byłaby niezwykle trudna, a próba korelowania problemów między systemami byłaby jeszcze trudniejsza., Nie ma nic bardziej frustrującego niż stwierdzenie, że żądane informacje nie zostały przechwycone w pliku dziennika lub że plik dziennika, który mógł zawierać odpowiedź, został utracony po ponownym uruchomieniu serwera.

Ta sekcja wyjaśnia, jak korzystać z usług centralizacji do zbierania i centralizacji plików dziennika Linuksa.

korzyści

korzyści z centralizowania dzienników

centralizacja dzienników ułatwia i przyspiesza przeszukiwanie danych dzienników, ponieważ wszystkie dzienniki są dostępne w jednym miejscu., Zamiast zgadywać, który serwer ma właściwy plik, możesz po prostu uzyskać dostęp do repozytorium danych dziennika, aby wyszukać odpowiednie zdarzenia. Centralizacja jest kluczową częścią dużych rozwiązań do zarządzania, ponieważ pozwala im analizować, analizować i indeksować dzienniki przed przechowywaniem ich w jednym miejscu. Dzięki temu rozwiązywanie problemów i rozwiązywanie problemów produkcyjnych jest łatwiejsze i szybsze. Centralizacja oferuje również te korzyści.

• logi są archiwizowane w oddzielnym miejscu, chroniąc je przed przypadkową lub niezamierzoną utratą., Dzięki temu są one również dostępne w przypadku, gdy serwery ulegną awarii lub przestaną odpowiadać.
• nie musisz używać poleceń SSH lub nieefektywnych grep, które mogą wykorzystywać cenne zasoby obliczeniowe do skomplikowanych wyszukiwań.
• możesz zmniejszyć ilość miejsca na dysku używanego przez pliki dziennika.
• Inżynierowie mogą rozwiązywać problemy produkcyjne bez bezpośredniego dostępu do systemów.

chociaż scentralizowane zarządzanie logami jest ogólnie lepszym rozwiązaniem, nadal istnieją pewne zagrożenia, takie jak słaba łączność sieciowa prowadząca do utraty danych lub dzienniki wykorzystujące dużą przepustowość sieci., Omówimy, jak inteligentnie rozwiązać te problemy w poniższych sekcjach.

popularne

popularne narzędzia do centralizacji dzienników

większość systemów Linuksowych już centralizuje dzienniki za pomocą demona syslog. Jak wyjaśniliśmy w sekcji podstawy logowania Linuksa, syslog jest usługą, która zbiera pliki dziennika z usług i aplikacji uruchomionych na hoście. Może zapisać te logi do pliku lub przesłać je na inny serwer za pośrednictwem protokołu syslog., Istnieje kilka implementacji syslog, które możesz użyć, w tym:

• Rsyslog– lekki Demon zainstalowany na większości popularnych dystrybucji Linuksa.
• syslog– ng-drugi najpopularniejszy Demon syslog dla Linuksa.
• logstash-cięższy agent, który może wykonywać bardziej zaawansowane przetwarzanie i parsowanie. Może odczytywać wiadomości syslog za pomocą wtyczki wejściowej syslog i przesyłać je do dowolnej liczby miejsc wyjściowych.
• fluentd-kolejny agent z zaawansowanymi możliwościami przetwarzania. Obsługuje również wprowadzanie syslog za pomocą wtyczki in_syslog.,

Rsyslog jest najpopularniejszą implementacją syslog i jest instalowany domyślnie w wielu dystrybucjach Linuksa. Jeśli potrzebujesz bardziej zaawansowanego filtrowania lub niestandardowych funkcji parsowania, Logstash jest kolejnym najpopularniejszym wyborem. Logstash jest również ściśle zintegrowany z elastycznym stosem, który zapewnia kompletne rozwiązanie do zarządzania logami. W tym przewodniku skupimy się na używaniu rsyslog, ponieważ jest tak szeroko stosowany.

config

Konfiguracja Rsyslog.conf

główny plik konfiguracyjny rsyslog znajduje się pod adresem /etc/rsyslog.conf., Możesz zapisać dodatkowe pliki konfiguracyjne w katalogu / etc / rsyslog.d / katalog. Na przykład w Ubuntu ten katalog zawiera /etc/rsyslog.d/50-default.conf, który nakazuje rsyslog zapisywanie logów systemowych do pliku. Więcej o plikach konfiguracyjnych można przeczytać w dokumentacji rsyslog.

Konfiguracja rsyslog polega na skonfigurowaniu źródeł wejściowych (gdzie rsyslog odbiera logi), a także reguł docelowych, gdzie i jak są zapisywane logi. Rsyslog już zapewnia domyślne wartości dla odbierania zdarzeń syslog, więc zwykle wystarczy dodać serwer centralizacji jako wyjście., Rsyslog używa RainerScript do swojej składni konfiguracji. W tym przykładzie przekazujemy nasze logi na serwer pod adresem central.example.com przez port TCP 514.

action(type="omfwd" protocol="tcp" target="central.example.com" port="514")

alternatywnie możemy wysłać nasze logi do rozwiązania do zarządzania logami. Dostawcy usług zarządzania dziennikami w chmurze, tacy jak SolarWinds ® Loggly®, udostępnią nazwę hosta i port, na który można wysyłać dzienniki, po prostu zmieniając pola targetI port. Podczas konfigurowania rsyslog należy zapoznać się z dokumentacją dostawcy..,

direct

rejestrowanie plików i katalogów

Rsyslog udostępnia moduł imfile, który umożliwia monitorowanie plików dziennika pod kątem nowych zdarzeń. Pozwala to określić plik lub katalog jako źródło dziennika. Rsyslog może monitorować zarówno pojedyncze pliki, jak i całe katalogi.

na przykład chcemy monitorować pliki dziennika utworzone przez serwer Apache. Możemy to zrobić tworząc nowy plik w /etc/rsyslog.d/ o nazwie apache.conf, załadować moduł imfile i dodać pliki dziennika Apache jako wejścia.,

parametr File obsługuje symbole wieloznaczne do monitorowania wielu plików, a także katalogów.

protokół

który protokół: UDP, TCP czy RELP?

istnieją trzy główne protokoły, z których można wybierać podczas przesyłania danych logów: UDP, TCP i RELP.

UDP wysyła wiadomości bez gwarancji dostawy lub potwierdzenia odbioru (ACK). Wykonuje pojedynczą próbę wysłania pakietu, a jeśli dostawa nie powiedzie się, nie próbuje ponownie. Jest znacznie szybszy i zużywa mniej zasobów niż inne protokoły, ale powinien być używany tylko w niezawodnych sieciach, takich jak localhost., UDP nie obsługuje również szyfrowania dzienników.

TCP jest najczęściej używanym protokołem do przesyłania strumieniowego przez Internet, ponieważ wymaga ACK przed wysłaniem następnego pakietu. Jeśli dostawa nie powiedzie się, będzie kontynuowana próba do momentu pomyślnego dostarczenia wiadomości. Jednak TCP wymaga uścisku dłoni i aktywnego połączenia między nadawcą a odbiorcą, który wykorzystuje dodatkowe zasoby sieciowe.

RELP (Reliable Event Logging Protocol) został zaprojektowany specjalnie dla rsyslog i jest prawdopodobnie najbardziej niezawodnym z tych trzech protokołów., Potwierdza otrzymanie danych w warstwie aplikacji i zostanie wysłane ponownie, jeśli wystąpi błąd. Ponieważ jest to mniej powszechne, musisz upewnić się, że miejsce docelowe obsługuje również ten protokół.

Jeśli rsyslog napotka problem podczas przechowywania dzienników, takich jak niedostępne połączenie sieciowe, będzie ustawiał dzienniki w kolejce do momentu przywrócenia połączenia. Kolejki dzienników są domyślnie przechowywane w pamięci. Pamięć jest jednak ograniczona, a jeśli problem nadal występuje, dzienniki mogą przekroczyć pojemność pamięci, co może prowadzić do utraty danych. Aby temu zapobiec, rozważ użycie kolejek dyskowych.,

Ostrzeżenie: możesz utracić dane, jeśli przechowujesz logi tylko w pamięci.

que

niezawodne wysyłanie z kolejkami wspomaganymi dyskiem

Rsyslog może kolejkować logi na dysk, gdy pamięć jest pełna. Kolejki wspomagane dyskami sprawiają, że transport dzienników jest bardziej niezawodny. Oto przykład jak skonfigurować regułę przekazywania logów w rsyslog z kolejką wspomaganą dyskami.

Szyfruj

Szyfruj Logi za pomocą TLS

gdy bezpieczeństwo danych i prywatność są problemem, należy rozważyć szyfrowanie dzienników. Snifferzy i pośrednicy mogą odczytać twoje dane dziennika, jeśli przesyłasz je przez internet w wyraźnym tekście., Powinieneś zaszyfrować swoje dzienniki, jeśli zawierają one informacje prywatne, poufne dane identyfikacyjne lub dane regulowane przez rząd. Demon rsyslog może szyfrować Twoje dzienniki za pomocą protokołu TLS i chronić Twoje dane.

proces włączania szyfrowania TLS zależy od konfiguracji logowania. Ogólnie rzecz biorąc, obejmuje następujące kroki.

1. Utwórz urząd certyfikacji (CA). W katalogu rsyslog /contrib/gnutls znajdują się przykładowe certyfikaty, które są dobre tylko do testowania, ale musisz stworzyć własne do produkcji., Jeśli korzystasz z usługi zarządzania dziennikami, będzie ona dla ciebie gotowa.
2. Wygeneruj certyfikat cyfrowy dla serwera, aby włączyć TLS, lub użyj certyfikatu od dostawcy usług zarządzania logami.
3. Skonfiguruj usługę rsyslog, aby wysyłała zaszyfrowane dane TLS do usługi zarządzania logami.

oto przykładowa konfiguracja rsyslog z szyfrowaniem TLS. Zastąp CERT i DOMAIN_NAME własnymi ustawieniami serwera.,

$DefaultNetstreamDriverCAFile /etc/rsyslog.d/keys/ca.d/CERT.crt$ActionSendStreamDriver gtls$ActionSendStreamDriverMode 1$ActionSendStreamDriverAuthMode x509/name$ActionSendStreamDriverPermittedPeer *.DOMAIN_NAME.com

usługi zarządzania logami, takie jak SolarWinds Loggly często zapewniają własne CAs i certyfikaty, które po prostu musisz odwołać w konfiguracji rsyslog. Na przykład, włączenie TLS za pomocą Loggly wymaga jedynie pobrania certyfikatu Loggly do katalogu / etc / rsyslog.d / katalog, zaktualizuj swoją konfigurację i uruchom ponownie usługę rsyslog.

najpierw pobierz certyfikat.

$ mkdir -pv /etc/rsyslog.d/keys/ca.d$ cd /etc/rsyslog.d/keys/ca.d$ curl -O https://logdog.loggly.com/media/logs-01.loggly.com_sha12.crt

następnie otwórz plik konfiguracyjny/etc/rsyslog.d/22-loggly.conf I dodaj:

na koniec uruchom ponownie rsyslog.,

$ sudo service rsyslog restart

praktyka

najlepsze praktyki logowania aplikacji

oprócz dzienników, które Linux tworzy domyślnie, dobrym pomysłem jest również scentralizowanie dzienników z ważnych aplikacji. Prawie wszystkie aplikacje serwerowe oparte na Linuksie zapisują informacje o swoim statusie w oddzielnych, dedykowanych plikach dziennika. Obejmuje to produkty bazodanowe, takie jak PostgreSQL lub MySQL, Serwery WWW, takie jak nginx lub Apache, zapory sieciowe, usługi drukowania i udostępniania plików, serwery katalogowe i DNS i tak dalej.

pierwszą rzeczą, jaką robią administratorzy po zainstalowaniu aplikacji, jest jej konfiguracja., Aplikacje Linuksowe mają zazwyczajplik conf gdzieś w katalogu / etc. Może być też gdzieś indziej, ale to pierwsze miejsce, gdzie ludzie szukają plików konfiguracyjnych. W zależności od stopnia złożoności lub wielkości aplikacji, liczba możliwych do Ustawienia parametrów może wynosić kilka lub setki. Aby dowiedzieć się więcej, zapoznaj się z dokumentacją aplikacji lub użyj polecenia zlokalizuj, aby samodzielnie znaleźć plik.

# locate postgresql.conf/usr/pgsql-9.4/share/postgresql.conf.sample/var/lib/pgsql/9.4/data/postgresql.conf

Ustawia standardową lokalizację dla plików dziennika

systemy Linux zazwyczaj zapisują swoje pliki dziennika w katalogu/var/log., Działa to dobrze, ale sprawdź, czy aplikacja zapisuje się w określonym katalogu pod /var/log. Jeśli tak, to świetnie. Jeśli nie, możesz utworzyć dedykowany katalog dla aplikacji pod /var/log. Dlaczego? Dzieje się tak dlatego, że inne aplikacje zapisują swoje pliki dziennika pod /var/log I jeśli Twoja aplikacja zapisze więcej niż jeden plik dziennika—być może raz dziennie lub po każdym ponownym uruchomieniu usługi—może być trochę trudno przeszukiwać duży katalog, aby znaleźć żądany plik.,

Jeśli w Twojej sieci działa więcej niż jedna instancja aplikacji, takie podejście jest również przydatne. Pomyśl o sytuacji, w której możesz mieć kilkanaście serwerów internetowych działających w Twojej sieci. Jeśli Twoje logi są przechowywane na centralnym serwerze syslog, skąd wiesz, który plik dziennika zawiera logi serwera? Rejestrując każdy serwer w osobnym katalogu, wiesz dokładnie, gdzie szukać podczas rozwiązywania problemów z jednym serwerem.

używaj statycznej nazwy pliku

wiele aplikacji dodaje dynamiczne dane do nazwy pliku dziennika, takie jak bieżąca data lub znacznik czasu., Jest to przydatne do automatycznego dzielenia dzienników według daty, ale utrudnia usługom takim jak rsyslog znalezienie najnowszego pliku. Lepszym rozwiązaniem jest użycie nie zmieniającej się nazwy pliku dziennika, a następnie użycie logrotate do zastosowania znacznika czasu lub numeru do starszych plików dziennika.

dołączanie i obracanie plików dziennika

aplikacje powinny dołączać do istniejących plików dziennika zamiast nadpisywać je. Pomaga to zapewnić przechwycenie wszystkich linii dziennika i utratę danych, nawet jeśli aplikacja zostanie ponownie uruchomiona. Jednak pliki dziennika mogą być bardzo duże w czasie., Jeśli próbujesz znaleźć przyczynę problemu, możesz przeszukiwać dziesiątki tysięcy linii.

zalecamy dołączenie dzienników do jednego pliku, ale zalecamy również skonfigurowanie aplikacji tak, aby co jakiś czas obracała swoje pliki dziennika. Narzędzia takie jak logrotate mogą to zrobić automatycznie, kopiując bieżący plik dziennika do nowej lokalizacji, nadając mu unikalną nazwę, a następnie obcinając bieżący plik dziennika., Ma to wiele zalet, w tym:

1. dzienniki są podzielone na pliki według daty i godziny, co ułatwia wyszukiwanie dzienników dla określonej daty
2. każdy plik dziennika jest znacznie mniejszy, co ułatwia wyszukiwanie i wysyłanie przez sieć
3. tworzenie kopii zapasowych plików dziennika jest znacznie łatwiejsze, a usuwanie lub Archiwizacja starszych dzienników można zrobić znacznie szybciej

to, jak często obracasz pliki dziennika zależy od liczby generowanych dzienników. Z reguły zacznij od obracania dzienników raz dziennie.

Ustaw zasady przechowywania plików dziennika

jak długo przechowujesz plik dziennika?, To zdecydowanie sprowadza się do wymagań biznesowych. Możesz zostać poproszony o przechowywanie tygodniowych informacji logowania lub może to być wymóg prawny, aby przechowywać dane o wartości 10 lat. Cokolwiek to jest, logi muszą przejść z serwera w tym czy innym czasie.

naszym zdaniem, o ile nie jest to wymagane inaczej, powinieneś przechowywać pliki dziennika online o wartości co najmniej miesiąca, a także kopiować je do dodatkowej lokalizacji (np. serwera logowania). Wszystko, co starsze, może zostać przeniesione na osobny nośnik. Na przykład, jeśli korzystasz z AWS, twoje starsze dzienniki mogą zostać skopiowane do Glacier.,

przechowuj pliki dziennika na oddzielnym dysku

pliki dziennika są zapisywane stale, co może prowadzić do wysokiego wejścia / Wyjścia dysku na zajętych systemach. Najlepszą praktyką jest zamontowanie /var/log na oddzielnym urządzeniu pamięci masowej. Zapobiega to zakłóceniom wydajności aplikacji, zwłaszcza w pamięci dyskowej, w wyniku zapisywania plików dziennika. Zapobiega to również zapełnieniu całego dysku w przypadku, gdy pliki dziennika staną się zbyt duże.

Formatuj swoje wpisy w Dzienniku

Jakie informacje należy zapisać w każdym wpisie dziennika?

To zależy od tego, do czego chcesz użyć dziennika., Czy chcesz użyć go tylko do rozwiązywania problemów, czy chcesz uchwycić wszystko, co się dzieje? Czy jest to wymóg prawny, aby uchwycić to, co każdy użytkownik jest uruchomiony lub oglądany?

Jeśli używasz dzienników do rozwiązywania problemów, zapisuj tylko błędy, ostrzeżenia lub wiadomości krytyczne. Nie ma powodu, aby przechwytywać wiadomości debugowania, na przykład. Aplikacja może domyślnie rejestrować wiadomości debugowania lub inny administrator mógł to włączyć w celu kolejnego ćwiczenia rozwiązywania problemów, ale musisz to wyłączyć, ponieważ zdecydowanie może szybko wypełnić miejsce., Co najmniej rejestruj datę, godzinę, nazwę aplikacji klienta, adres IP źródła lub nazwę hosta klienta, wykonaną akcję i samą wiadomość.

na przykład, rozważmy domyślne zachowanie logowania PostgreSQL. Logi są przechowywane w /var/log/postgresql, a każdy plik zaczyna się od postgresql – po którym następuje Data. Pliki są obracane codziennie, a starsze pliki są dołączane z numerem w zależności od tego, kiedy zostały obrócone. Każdy wiersz dziennika może być poprzedzony polami, takimi jak aktualny znacznik czasu, bieżący użytkownik, nazwa bazy danych, identyfikator sesji i identyfikator transakcji., Możesz zmienić te ustawienia edytując plik konfiguracyjny PostgreSQL (/etc/postgresql/11/main/postgresql.conf w Debianie).

domyślnie każda linia dziennika pokazuje znacznik czasu i identyfikator procesu PostgreSQL, po którym następuje wiadomość dziennika.

Monitoruj pliki dziennika za pomocą Imfile

tradycyjnie najczęstszym sposobem logowania danych przez aplikacje są pliki. Pliki są łatwe do przeszukiwania na jednej maszynie, ale nie skalują się dobrze z większą liczbą serwerów. Dzięki rsyslog możesz monitorować pliki pod kątem zmian i importować nowe zdarzenia do syslog, gdzie możesz następnie przekazywać dzienniki do scentralizowanego serwera., Odbywa się to za pomocą modułu imfile. Aby włączyć moduł, utwórz nowy plik konfiguracyjny w /etc/rsyslog.d/, a następnie dodaj taki plik.

Dodaj swoje strumienie wyjściowe po tej konfiguracji, a rsyslog wyśle logi z podanego pliku do docelowego wyjścia.

Zaloguj się bezpośrednio do gniazda Syslog za pomocą Imuxsock

gniazdo jest podobne do uniksowego uchwytu plików, z tym, że odczytuje dane do pamięci zamiast zapisywać je na dysk. W przypadku syslog, pozwala to wysyłać logi bezpośrednio do syslog bez konieczności wcześniejszego zapisywania ich do pliku.,

to podejście sprawia, że efektywne wykorzystanie zasobów systemowych, jeśli twój serwer jest ograniczony przez We / Wy dysku lub nie potrzebujesz lokalnych dzienników plików. Wadą tego podejścia jest to, że gniazdo ma ograniczony rozmiar kolejki. Jeśli twój Demon syslog przestanie działać lub nie może nadążyć, możesz stracić dane dziennika.

aby włączyć logowanie gniazda w rsyslog, dodaj następującą linię do konfiguracji rsyslog (domyślnie jest włączona).

$ModLoad imuxsock

domyślnie tworzy to gniazdo pod adresem/dev/log socket, ale możesz to zmienić, modyfikując SysSock.Name parametr., Można również ustawić opcje, takie jak ograniczenie szybkości i kontrola przepływu. Więcej informacji można znaleźć w dokumentacji rsyslog imuxsock.

Logi UDP z Imupd

niektóre aplikacje wysyłają dane dziennika w formacie UDP, który jest standardowym protokołem podczas przesyłania plików dziennika przez sieć lub lokalny host. Twój Demon syslog odbiera te dzienniki i może je przetwarzać lub przesyłać w innym formacie. Możesz również wysłać logi do innego serwera syslog lub do rozwiązania do zarządzania dziennikami.,

użyj następującego polecenia, aby skonfigurować rsyslog tak, aby akceptował dane syslog przez UDP na standardowym porcie 514.

$ModLoad imudp$UDPServerRun 514

Zarządzaj konfiguracją na wielu serwerach

gdy masz tylko kilka serwerów, możesz ręcznie skonfigurować logowanie na nich. Gdy już posiadasz kilkadziesiąt lub więcej serwerów, możesz skorzystać z narzędzi, które ułatwiają i zwiększają skalowalność. Na poziomie podstawowym celem każdego narzędzia jest włączenie syslog na każdym z serwerów, zastosowanie konfiguracji i upewnienie się, że zmiany wejdą w życie.,

Pssh

Pssh (lub parallel ssh) pozwala uruchomić polecenie ssh na kilku serwerach równolegle. Używaj wdrożenia pssh tylko dla niewielkiej liczby serwerów. Jeśli jeden z Twoich serwerów zawiedzie, musisz ssh do nieudanego serwera i wykonać wdrożenie ręcznie. Jeśli masz kilka nieudanych serwerów, ręczne wdrażanie na nich może zająć dużo czasu.

Puppet/Chef

Puppet i Chef to narzędzia do zarządzania konfiguracją, które mogą automatycznie skonfigurować wszystkie serwery i doprowadzić je do tego samego stanu. Mogą monitorować twoje serwery i utrzymywać je zsynchronizowane., Puppet i Chef to potężne narzędzia umożliwiające instalowanie oprogramowania, tworzenie plików, ponowne uruchamianie usług i wiele innych. Jeśli nie masz pewności, które z nich jest bardziej odpowiednie do zarządzania konfiguracją wdrażania, możesz docenić porównanie dwóch narzędzi InfoWorld.

niektórzy dostawcy oferują również moduły lub przepisy do konfiguracji syslog. Na przykład, Loggly zapewnia moduł Puppet, który używa rsyslog do automatycznego przekazywania dzienników od agentów. Zainstaluj moduł Loggly Puppet na swoim Puppet master, a następnie dodaj następującą konfigurację do manifestu Puppet.,

 # Send syslog events to Loggly class { 'loggly::rsyslog': customer_token => 'YOUR_CUSTOMER_TOKEN', }

po odświeżeniu agenci zaczną logować się do Loggly.

Kubernetes

Kubernetes jest narzędziem do zarządzania kontenerami na wielu węzłach. Kubernetes zapewnia kompletną architekturę rejestrowania, która automatycznie zbiera i zapisuje dzienniki kontenerów do pliku na komputerze hosta. Możesz przeglądać dzienniki dla konkretnego Pod, uruchamiając komendę kubectl logs <pod name>, która jest przydatna do uzyskiwania dostępu do dzienników aplikacji na zdalnym serwerze.,

wiele rozwiązań do zarządzania dziennikami zapewnia agentów, które można wdrożyć za pośrednictwem usługi Kubernetes w celu zbierania dzienników aplikacji i dzienników hosta. Na przykład, Loggly zapewnia Demonset, który wdraża pod logowania do każdego węzła w klastrze. Pod zbiera logi z innych Pod i z samego hosta, a wdrożenie go jako Demonsetu pomaga zapewnić, że zawsze jest instancja uruchomiona na każdym węźle. Logowanie klastra Kubernetes za pomocą Loggly jest tak proste, jak uruchomienie następujących poleceń.

Docker

Docker używa kontenerów do uruchamiania aplikacji niezależnych od bazowego serwera., Jest często używany jako środowisko wykonawcze kontenera dla orkiestratorów takich jak Kubernetes, ale może być używany jako samodzielna Platforma. ZDNet ma szczegółowy artykuł na temat korzystania z Dockera w centrum danych.,

istnieje kilka sposobów logowania z kontenerów Dockera, w tym:

• logowanie za pomocą sterownika Docker Logging do systemu hosta (zalecana metoda)
• przekierowanie wszystkich dzienników kontenera do jednego dedykowanego kontenera logging (tak działa kontener logspout)
• Logowanie do kontenera Sidecar logging
• dodawanie agenta logging do kontenera

Możesz również użyć kontenerów Docker do zbierania dzienników z hosta., Jeśli kontener ma uruchomioną usługę syslog, możesz wysłać dzienniki z hosta do kontenera za pośrednictwem syslog lub zamontować pliki dziennika hosta w kontenerze i użyć agenta monitorowania plików do odczytu plików.

Skrypty lub agenci dostawcy

większość rozwiązań do zarządzania logami oferuje skrypty lub agentów, aby wysyłanie danych z jednego lub więcej serwerów było stosunkowo łatwe. Agenci wagi ciężkiej mogą wykorzystać dodatkowe zasoby systemowe. Niektórzy dostawcy integrują się z istniejącymi demonami rsyslog, aby przekazywać dzienniki bez użycia znacznie większej ilości zasobów., Na przykład Loggly dostarcza skrypt, który przekazuje logi z rsyslog do serwerów loggly ingestion przy użyciu modułu omfwd.