Як мати кілька потоків журналу в docker

У нас є додаток, який записує три типи журналів у три окремі файли: журнали доступу, загальні журнали додатків та системні журнали. Формат (і призначення) цих журналів дуже різний. І у нас є окремі логістичні експедитори, які надсилають їх окремо до нашої централізованої системи реєстрації журналів.

Виходячи з журналів обробки як принципу потоків подій , ми думаємо про перехід від використання файлів до stdout. Хоча ми знаємо деяку користь цього підходу, це також означатиме, що ми отримаємо об'єднаний потік журналів, що мають різний формат, які нам потрібно буде розділити знову, перш ніж ми зможемо надіслати їх до нашої центральної системи (Kibana / Splunk / тощо), або всередині.

Нам цікаво, чи є інструменти чи рекомендації щодо того, як нам підходити до цієї ситуації.

docker logging

— SztupY
джерело

Я не думаю, що цього варто. Навіщо працювати більше, щоб об'єднати, а потім розділити потоки журналів, саме через якийсь "принцип"? Файли хороші. Файли працюють. Це звучить перенапружено. Я б сказав, можливо, передайте всі журнали в syslog, з різними тегами і т. Д., Але мушу сказати, якби хтось із моєї команди запропонував це .. я був би .. розчарований.

— Ассаф Лав'є

Оскільки у використанні файлів є деякі інші види кошмарів управління, особливо якщо вони генеруються всередині контейнера докера. Наразі це виглядає як недоліки від переходу на stdout переважують переваги для нашого випадку використання, але ми вже маємо проблеми з нашим підходом до файлів

— SztupY

Я не знаю про "кошмари". Я знаю, що саме так це робиться на деякий час, і там є багато програмного забезпечення, яке допомагає вам це зробити. Файли журналу обертаються, читаються за допомогою контрольних точок - файл - це велика абстракція для цього. Я б не вдавався в принцип, який продає мені нові кошмари через страх старих звичних зразків. Ваші записи журналів записуються у файл або обробляються в пам'яті (принаймні, доки вони переміщуються в контейнері). Успіхів у досягненні надійності файлів журналів за допомогою подільників та злиття потоку пам'яті.

— Ассаф Лав'є

@AssafLavie Ви повинні написати це у відповідь, яку можна отримати. ІМХО - це цілком справедлива точка зору.

— Дан Корнілеску

Я прийшов сюди з тим же запитанням. Простий факт полягає в тому, що вбудована функція ведення журналу докера залежить від усього, що йде на stdout / stderr, отже, і драйвер реєстрації та екосистема сторонніх інструментів, що створюються навколо нього. Мені спокуса скинути всі мої журнали в розмір хосту, але я знаю, що мені доведеться продовжувати повертатися назад і керувати цим, коли мої контейнери переходять на k8s або openhift або gke чи будь-що інше, тоді як якщо я слідкую за докер Під час підходу це буде набагато плавніше. Тим часом я продовжуватиму шукати відповідь на це законне запитання

— Rhubarb

Відповіді:

Я все ще шукаю підхід для злиття / розщеплення, але тим часом цей підхід, рекомендований документацією Kubernetes, здається надійним рішенням: використовуйте контейнер для колясок для кожного вашого окремого журналу .

"Сидельна коляска" - це будь-який контейнер докера, який ви використовуєте поряд з іншим докерним контейнером, щоб певним чином працювати з ним. У цьому випадку для кожного з ваших трьох журналів у вас був би окремий контейнер, який сканує або вивертає журнали та виводить їх до stdout.

Таким чином, кожен із ваших контейнерів-колясок має свій власний докер-журнал із власного stdout. Будучи подібно до цього, ви можете використовувати стандартні докерські (і кубернети тощо) для відокремлення або агрегування. Ось що має сказати на сторінці Kubernetes:

Такий підхід дозволяє відокремити кілька потоків журналу від різних частин програми, у деяких з яких може бути відсутність підтримки для написання в stdout або stderr. Логіка, що стоїть за журналами переадресації, мінімальна, тому навряд чи це значні витрати. Крім того, оскільки stdout та stderr обробляються кубелетом, ви можете використовувати вбудовані інструменти, такі як журнали kubectl.

"Окремі потоки журналів" походять від вбудованого тегу, який докер застосовує до журналів з різних контейнерів, описаних тут у документації докера:

Параметр журналу тегів визначає, як відформатувати тег, який ідентифікує повідомлення журналу контейнера. За замовчуванням система використовує перші 12 символів ідентифікатора контейнера. Щоб замінити цю поведінку, вкажіть параметр тегу

— Ревінь
джерело

Варто зазначити недоліки цього підходу до контейнерів-контейнерів для журналу, цитуйте: "Зауважте, що, незважаючи на низьке використання процесора та пам'яті, записування журналів у файл та подача їх до stdout може подвоїти використання диска". Цікаво, чи хтось спробує такий підхід на практиці.

— липня

Ідея об'єднати їх в один потік просто для того, щоб розділити їх згодом, звучить болісно. У мене не було причин робити це самостійно, але ось з чого я б почав:

Під час запуску контейнера докера створіть об'єм таким, щоб було легко переглядати / пересилати журнали від хоста.
Використовуйте щось на зразок remote_syslog2 для надсилання журналів у ваш колектор журналів

Це здається трохи менш елегантним, щоб зробити певну настройку також на хості, але якщо ви використовуєте щось на зразок ansible, де ви можете запустити ігрову книгу і встановити її під час розгортання в поле, це не повинно бути занадто поганий.

— брадим
джерело

Це рішення можна поєднувати з названими трубами, єдина проблема з названими трубами полягає в тому, що вони працюють не у всіх системах зараз. Вони не працюють на Mac

— Єнс