Jak mieć wiele strumieni dziennika w oknie dokowanym

Mamy aplikację, która zapisuje trzy typy dzienników w trzech osobnych plikach: dzienniki dostępu, ogólne dzienniki aplikacji i dzienniki systemowe. Format (i cel) tych dzienników są bardzo różne. I mamy osobne moduły logforwarderów, które wysyłają je osobno do naszego scentralizowanego systemu rejestrowania.

Opierając się na zasadzie traktuj dzienniki jako strumienie zdarzeń , myślimy o przejściu z używania plików na standardowe wyjście. Chociaż znamy niektóre zalety tego podejścia, oznaczałoby to również, że otrzymalibyśmy scalony strumień różnych formatów dzienników, które musielibyśmy ponownie podzielić, zanim będziemy mogli wysłać je do naszego systemu centralnego (Kibana / Splunk / itp.) lub w środku.

Zastanawiamy się, czy istnieją jakieś narzędzia lub zalecenia dotyczące tego, jak powinniśmy podejść do tej sytuacji.

docker logging

— Sztuczki
źródło

Nie sądzę, żeby było warto. Po co ciężko pracować, aby scalić, a następnie podzielić strumienie dziennika, tylko z powodu jakiejś „zasady”? Pliki są dobre. Pliki działają. To brzmi jak przerośnięte. Powiedziałbym, że może potokuj wszystkie logi do syslog, z różnymi tagami itp., Ale muszę powiedzieć, że jeśli ktoś z mojego zespołu to zasugerował ... byłbym ... rozczarowany.

— Assaf Lavie,

Ponieważ korzystanie z plików ma inne koszmary zarządzania, zwłaszcza jeśli są generowane z wnętrza kontenera dokowanego. Na razie wygląda na to, że wady przejścia na standardowe wyjście przeważają nad zaletami naszego przypadku użycia, ale już mamy problem z podejściem opartym na plikach

— SztupY

Nie wiem o „koszmarach”. Wiem, że jest to sposób, w jaki zostało to zrobione od jakiegoś czasu, i istnieje wiele programów, które Ci to pomogą. Pliki dziennika są obracane, odczytywane za pomocą punktów kontrolnych - plik jest do tego świetną abstrakcją. Nie kupiłbym zasady, która sprzedaje mi nowe koszmary z powodu strachu przed starymi, znanymi wzorami. Twoje rekordy dziennika są zapisywane w pliku lub obsługiwane w pamięci (przynajmniej tak długo, jak są przenoszone w kontenerze). Powodzenia w uzyskiwaniu niezawodności plików dziennika dzięki rozdzielaczom i łączeniom strumieni w pamięci.

— Assaf Lavie,

@AssafLavie Powinieneś napisać to w odpowiedzi, która może zostać oceniona. IMHO to całkowicie poprawny punkt widzenia.

— Dan Cornilescu,

Przybyłem tutaj z tym samym pytaniem. Prostym faktem jest to, że wbudowana funkcja rejestrowania dokera zależy od wszystkiego, co będzie ustawione na stdout / stderr, stąd też sterownik rejestrowania i ekosystem narzędzi innych firm, które się wokół niego gromadzą. Kusi mnie również, aby zrzucić wszystkie moje dzienniki do woluminu hosta, ale wiem, że będę musiał wracać i zarządzać tym, gdy moje kontenery przeniosą się do K8s, OpenShift, GKE itp., Ale jeśli podążę za dokerem podejście standardowe będzie znacznie płynniejsze. Tymczasem będę szukał odpowiedzi na to uzasadnione pytanie

— Rhubarb,

Odpowiedzi:

Nadal szukam metody łączenia / dzielenia, ale tymczasem to podejście zalecane przez dokumentację Kubernetes wydaje się rozsądnym rozwiązaniem: użyj kontenera bocznego dla każdego z osobnych dzienników .

„Wózek boczny” to każdy pojemnik dokowania, którego używasz obok innego kontenera dokowania, aby w jakiś sposób z nim pracować. W takim przypadku dla każdego z trzech dzienników miałbyś osobny pojemnik, który skanuje lub ogonuje dzienniki i dane wyjściowe na standardowe wyjście.

W ten sposób każdy z twoich log-sidecar-container ma swój własny log-docker z własnego standardowego wyjścia. Będąc tak oddzielnymi, możesz używać standardowych metod dokowania (i kubernetes itp.) Do rozdzielania lub agregowania. Oto, co ma do powiedzenia strona Kubernetes:

Takie podejście pozwala oddzielić kilka strumieni dziennika od różnych części aplikacji, z których niektóre mogą nie obsługiwać zapisu na standardowe wyjście lub standardowe wyjście. Logika przekierowywania dzienników jest minimalna, więc nie jest to znaczny narzut. Dodatkowo, ponieważ stdout i stderr są obsługiwane przez kubelet, możesz używać wbudowanych narzędzi, takich jak dzienniki kubectl.

„Oddzielne strumienie dziennika” wynikają z wbudowanego tagowania, które doker stosuje do dzienników z różnych kontenerów, opisanych w dokumentacji dokera tutaj:

Opcja dziennika znaczników określa sposób formatowania znacznika identyfikującego komunikaty dziennika kontenera. Domyślnie system używa pierwszych 12 znaków identyfikatora kontenera. Aby zastąpić to zachowanie, określ opcję znacznika

— Rabarbar
źródło

Warto wspomnieć o wadach tego podejścia do log-sidecar-container, cytat: „Zauważ, że pomimo niskiego zużycia procesora i pamięci, zapisywanie logów do pliku, a następnie przesyłanie ich strumieniowo na standardowe wyjście może podwoić użycie dysku”. Zastanawiam się, czy ktoś spróbuje tego podejścia w praktyce.

— yusong

Pomysł połączenia ich w jeden strumień w celu ich późniejszego podzielenia wydaje się bolesny. Sam nie miałem powodu, aby to zrobić, ale od tego chciałbym zacząć:

Po uruchomieniu kontenera dokowanego utwórz wolumin, który ułatwi przeglądanie / wysyłanie dzienników z hosta.
Użyj czegoś takiego jak remote_syslog2, aby wysłać dzienniki do modułu gromadzącego dzienniki

Nie jest zbyt eleganckie, że trzeba trochę skonfigurować na hoście, ale jeśli używasz czegoś takiego jak ansible, w którym możesz uruchomić playbook i ustawić to podczas wdrażania w pudełku, nie powinno to być zbyt zły.

— bradym
źródło

To rozwiązanie można łączyć z nazwanymi potokami, jedynym problemem z nazwanymi potokami jest to, że obecnie nie działają one na wszystkich systemach. Nie działają na komputerach Mac

— Jens