Назад | Перейти на главную страницу

Как перенаправить журналы приложений из контейнеров Docker в ELK

Я пытаюсь централизовать ведение журнала в среде, использующей несколько прикладных технологий (Java, Rails и различные БД).

Мы хотим, чтобы разработчики создавали стеки с помощью Docker Compose, но мы хотим, чтобы они обращались к центральному источнику журналов (ELK) для отладки проблем, а не пытались открывать оболочки для запуска контейнеров Docker.

Все приложения записывают данные в файловую систему, а не в STDOUT / STDERR, который удаляет все параметры, связанные с драйвером ведения журнала Docker, а также logspout.

Что мы сделали, так это настроили контейнеры так, чтобы rsyslog включал файлы журнала приложения и перенаправлял их в logstash, у которого есть вход syslog. Это работает с точки зрения перемещения журналов из A в B, но управление журналами с несколькими технологиями в ELK на основе входных данных syslog ужасно (например, попытка захватить многострочные трассировки стека Java или медленные запросы MySQL).

Есть лучший способ сделать это? Должен ли я запускать logstash в каждом контейнере, чтобы я мог применять фильтры и кодеки непосредственно к файлам журналов, чтобы мне не приходилось полагаться на ввод системного журнала?

Есть ли способ использовать драйвер ведения журнала Docker с файлами журнала приложений, которые записываются в файловую систему?

Последние версии Docker поддерживают передачу журналов в формате GELF на сетевой порт. Logstash имеет вход GELF. Вы можете запустить Logstash на каждом узле и направить на него все экземпляры Docker на узле.

В качестве ввода Logstash: https://www.elastic.co/guide/en/logstash/current/plugins-inputs-gelf.html

gelf {
}

Для вывода Docker: https://docs.docker.com/engine/admin/logging/overview/#gelf

$ docker run -dit \
             --log-driver=gelf \
             --log-opt gelf-address=udp://127.0.0.1:12201 \
             alpine sh

(Gelf-адрес находится снаружи контейнера, а не внутри)

Вы также можете настроить logstash для анализа различных файлы журналов json докер выдает по умолчанию.

Другой подход - использовать то, что в Kubernetes называется sidecar.

Они приводят несколько разных примеров в своих ведение журнала кластера страница концепций.

То, как вы решите применить эту концепцию, полностью зависит от ваших потребностей.

Однако простое доказательство концепции может сработать:

  • создание сопроводительного файла logstash, который принимает входящие потоки системного журнала (например, использует ввод системного журнала)
  • настройка всех контейнеров для использования докеров драйвер системного журнала отправить журнал в коляску.

Вы также можете, конечно, настроить центральный прослушиватель системного журнала (например, с помощью logstash или rsyslog) и сделать это без сопутствующего элемента.

Этот подход также очень похож на @Джейсон МартинПредложение использовать GELF.

Другой вариант использования локального сопроводительного файла может заключаться в создании контейнера, в котором выполняется logstash с ввод файла, и предоставил том журнала (например, / var / log / или / logs). Затем вы можете поделиться этим томом с другими контейнерами, чтобы они могли писать свои журналы (например, /logs/$INSTANCE_ID/file.log), и logstash их анализировал.

Эта последняя настройка позволяет отслеживать файлы, а не STDOUT / STDERR, но вам, вероятно, понадобится каталог журнала. chmod 1777 (или иметь несколько таких коляскок).

«Обратный» режим, конечно, тоже будет работать (но кажется, что его сложнее управлять / поддерживать): пусть контейнеры приложений выставляют том журнала, а сопутствующая сделка logstash читает содержимое тома журнала.