Насколько я понимаю, я испытываю смешанные чувства по поводу захвата журналов из нескольких контейнеров в одном файле, данные будут смешаны. Но хорошее решение - добавить дополнительный объем.
Можно создать том Docker / Kubernetes (или много томов), предназначенный для размещения этих файлов журнала в приложении. Используя шаблоны Docker, можно дополнить каждый том суффиксом идентификатора сервисной задачи (целое число). Размещение суффикса в имени тома предотвращает любые коллизии, связанные с ведением журнала, если на одном хосте выполняются несколько сервисных задач. Необходимо создать глобальную службу, которая запускает агент ведения журнала с поддержкой подстановочных знаков каталога. Наконец, дополнительное регулярное выражение можно настроить с помощью утилиты ведения журнала, которая превращает исходный каталог файла в индексированное значение.
Пример ниже показывает, как это можно сделать, используя официальное изображение Tomcat . Официальный образ Tomcat регистрирует несколько файлов в /usr/local/tomcat/logs, как и большинство приложений Java. По этому пути можно найти такие файлы, как catalina.2017-07-06.log, host-manager.2017-07-06.log, localhost.2017-07-06.log, localhost_access_log.2017-07-06.txt и manager.2017-07-06.log.
Создание глобальной службы для утилиты ведения журнала, которая монтирует /var/lib/docker/volumes:/logs/volumes.
Создайте правило ведения журнала для агента ведения журнала, который ведет журнал, используя правило, аналогичное приведенному ниже общему примеру: "/log/volumes/*/_data/*.log".
Запуск службы с использованием шаблонов на основе go для томов:
При запуске сервиса используйте следующие параметры:
docker service create \
-d \
--name prod-tomcat \
--label version=1.5 \
--label environment=prod \
--mount type=volume,src="{{.Task.Name}}",dst=/usr/local/tomcat/logs \
--replicas 3 \
tomcat:latest
Если на одном узле запланированы обе реплики, то на хосте будут созданы два тома, содержащие журналы prod-tomcat.1.oro7h0e5yow69p9yumaetor3l и prod-tomcat.2.ez0jpuqe2mkl6ppqnuffxqagl.
Пока агент ведения журнала поддерживает подстановочные знаки и обрабатывает любое ротацию журналов, проверяя inode (не файл), журналы должны собираться.
Если приложение ведет журнал в нескольких местах, попробуйте использовать символическую ссылку журналов в один каталог или добавьте описательное имя к тому. Если к имени тома добавлено описательное имя, то любой вид извлечения необходимо будет обновить, чтобы учесть это изменение. (т.е. с grok)
Большинство регистраторов должны собирать путь к файлу, а также содержимое журнала. Превратив тома, в которых находятся файлы журналов, в индексируемые поля, можно искать и собирать информацию из этих типов приложений. Вот пример, который использует шаблон grok и создает два новых индексируемых поля: CONTAINER_NAME и FILENAME.
match => { "path" => "/log/volumes/%{DATA:CONTAINER_NAME}/_data/%{GREEDYDATA:FILE_NAME}" }
CONTAINER_NAME будет соответствовать выходному потоку stdout из контейнера, что упрощает фильтрацию на основе журналов контейнера.
Дополнительную информацию о репозитории с рабочим примером можно найти в репо swarm-elk .
Более подробную информацию о процессе регистрации вы можете найти здесь: регистрация .