Я часто упоминал в различных заметках систему по сбору логов Loki. Например, вот в этой подборке подобных систем (там сразу можете посмотреть аналоги). При этом у меня нет ни одной заметки на тему того, как её быстро развернуть. Решил написать краткое руководство по этой теме.

Проект относительно новый, стартовал в 2018 году в противовес стеку ELK. Grafana решила сделать более простой и легковесный вариант хранения логов немного с другой моделью анализа, без полной индексации текстов логов, используя вместо этого метки для потоков. На деле получился хороший продукт, интегрированный в стек Grafana + Prometheus с похожей идеологией хранения и поиска (язык запросов LogQL по аналогии с PromQL).

Для начала выполню базовые действия для запуска Loki и Grafana и настрою отправку логов в Loki от различных Docker контейнеров. Большее в одну заметку не уместить. Думаю, что далее я эту тему разовью.

Я не буду запускать Loki и Grafana в одном Docker Compose файле, так как им не обязательно быть установленными вместе. Grafana поддерживает весь стек своих продуктов, так что нет особого смысла поднимать её рядом со сборщиком логов.

Сначала запустим Loki. Готовим для него compose.yaml и конфигурацию в config.yaml. Не буду приводить здесь содержимое. Оно будет отправлено следующим сообщением в архиве со всеми остальными конфигурациями. Для удобства скопировал её же в gitflic.

# curl https://get.docker.com | bash -
# git clone https://gitflic.ru/project/serveradmin/grafana-loki.git
# cd grafana-loki/loki/

В файле compose.yaml укажите актуальную версию image на момент установки. Запускаем проект:

# docker compose up -d

Проверим, что сервис стартовал:

# curl http://192.168.137.29:3100
404 page not found

Это нормальный ответ. 404 нам ответил Loki. Запустим теперь Grafana:

# cd ../grafana

Указываем нужную версию в compose.yaml и запускаем:

# docker compose up -d

Идём браузером по IP сервера, где запущена Grafana на порт 3000. Учётка по умолчанию - admin / admin. Заходим в Grafana, идём в раздел Connections ⇨ Data sources ⇨ Add data source. Выбираем Loki. В качестве настроек достаточно указать только url. В моём случае это http://192.168.137.30:3100/. Мотаем страничку в самый низ и нажимаем Save & Test. Ошибок быть не должно.

Стек поднят и готов к приёму логов. Отправим туда логи контейнеров Docker. Для этого у Docker существует драйвер. Его необходимо установить на хосте:

# docker plugin install grafana/loki-docker-driver:3.6.0-amd64 --alias loki --grant-all-permissions

Проверяем, что он установился:

# docker plugin ls
018395707e37  loki:latest  Loki Logging Driver  true

Всё в порядке. Теперь мы можем в самом демоне Docker настроить отправку всех логов в Loki через правку его конфигурации в /etc/docker/daemon.json. Для этого туда надо добавить:

{
  "debug": true,
  "log-driver": "loki",
  "log-opts": {
    "loki-url": "http://192.168.137.30:3100//loki/api/v1/push",
    "loki-batch-size": "400"
  }
}

Это не очень удобно, если у нас нет желания собирать логи абсолютно всех контейнеров. Удобнее управлять этим для каждого контейнера отдельно. Для этого в compose файл достаточно добавить ещё одну секцию logging. Покажу сразу итоговый пример для запуска Grafana из этой публикации:

services:
 grafana:
  image: docker.io/grafana/grafana-oss:12.3.1
  container_name: grafana
  logging:
   driver: loki
   options:
    loki-url: "http://192.168.137.30:3100/loki/api/v1/push"
    loki-retries: 2
    loki-max-backoff: 800ms
    loki-timeout: 1s
    keep-file: "true"
    mode: "non-blocking"
  ports:
   - "3000:3000"
  volumes:
   - grafana-data:/var/lib/grafana
  restart: unless-stopped
volumes:
 grafana-data:
  driver: local

Перезапускаем проект:

# docker compose stop
# docker compose up -d

Идём в Grafana, раздел Drilldown ⇨ Logs. Выбираем в выпадающем списке service имя контейнера и смотрим его логи.

Настройка простая и быстрая, легко автоматизируется. Далее я разовью эту тему и добавлю логи из других систем.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#loki #logs #devops

Продолжу тему со сбором логов в Loki. Хочу написать законченный цикл заметок, в которых будет показан сбор логов популярных сервисов. В прошлой заметке я установил Loki + Grafana и отправил в Loki логи контейнеров Docker. Сегодня передам туда системные логи формата journald или текстовых файлов от syslog. Я покажу пример с обоими типами логов, а вы уже по месту сможете выбрать, какие использовать.

Изначально у Grafana для сбора логов с хостов была небольшая программа Promtail. Её и сейчас можно использовать, но больше её не развивают и не обновляют. На замену предложен Alloy - огромный комбайн, который включает в себя и сбор логов, их обработку и насыщение дополнительными данными, и преобразование, сбор трейсов, а также отправку системных метрик в Prometheus вместо Node Exporter. То есть Alloy объединяет логи и метрики.

В итоге вместо легковесного и простого в настройке продукта мы получаем комбайн всё в одном. Если используется полный стек Grafana в виде мониторинга, логов и трассировки, то наверное это удобно. Если собираются только логи, то не очень. Вместо Alloy можно взять Fluent Bit, Fluentd или Vector. Последние два легковесны, популярны, с простой настройкой. Можно взять и их. Но я в своём примере ограничусь стеком Grafana и буду использовать Alloy.

Репозиторий Grafana для IP адресов из России заблокирован. В общем случае он добавляется вот так:

# mkdir -p /etc/apt/keyrings
# wget -O /etc/apt/keyrings/grafana.asc https://apt.grafana.com/gpg-full.key
# chmod 644 /etc/apt/keyrings/grafana.asc
# echo "deb [signed-by=/etc/apt/keyrings/grafana.asc] https://apt.grafana.com stable main" > /etc/apt/sources.list.d/grafana.list

Мы же подключим копию репозитория из зеркала Яндекса. Для краткости я подключу его без ключа. Если вам это не подходит, то скачайте ключ и как-то передайте его на целевые машины:

# echo "deb [trusted=yes] https://mirror.yandex.ru/mirrors/packages.grafana.com/oss/deb/ stable main" > /etc/apt/sources.list.d/grafana.list
# apt update
# apt install alloy

Как я уже упомянул, конфигурация Alloy немного замороченная. Не сказать, что прям сильно сложная, но лично мной воспринимается тяжело. Нужно вникать, когда читаешь и постоянно мотать туда-сюда конфиг, чтобы удостовериться в том, что не запутался в сущностях и названиях.

Я уже подготовил простой конфиг для логов, так что достаточно будет просто скачать и применить у себя. В базовом сценарии каких-то особых сложностей нет. Они начнутся, когда будете разбираться с различными метками, автоназначением и т.д.

Забирайте config.alloy из моего репозитория, копируйте в /etc/alloy и перезапускайте службу. Заодно добавьте в автозагрузку. По умолчанию она вроде не делает этого:

# systemctl restart alloy
# systemctl enable alloy

Больше ничего делать не надо. На все хосты Alloy устанавливается и настраивается аналогично. В Loki логи будут прилетать с метками в виде %hostname%-logs и %hostname%-journal. Соответственно, по именам серверов вы и сможете их там выбирать. Метки, если что, можно изменить. Они настраиваются в параметрах labels и job соответственно. В конфигурации это всё наглядно видно.

По аналогии можно добавить любые текстовые логи. Тут никакой привязки к syslog нет. Просто забираем текстовые логи, определённые параметром:

  __path__  = "/var/log/{syslog,messages,*.log}",

Теперь можно идти в Grafana, раздел Drilldown ⇨ Logs. Выбираем в выпадающем списке service с нужным именем и типом логов и смотрим.

Единственное, что мне не нравится тут, так это то, что в тексте лога есть метки времени, и в самом хранилище есть метки времени, когда запись была добавлена. Иногда они не совпадают и это неудобно. В Logstash есть модуль date для того, чтобы выделять дату из текста поступающих логов и использовать ее в качестве даты документа в Elasticsearch.
❓Кто-нибудь настраивал подобное в Loki, чтобы время документа совпадало со временем в логе?

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#loki #logs #devops

Продолжу одновременно две темы, которые развиваю последнее время - почтовый сервер на базе Postfix и сбор логов в Loki. Покажу, как очень просто и быстро собирать логи Postfix в Loki с базовым анализом содержимого и простенькой визуализацией в дашборде.

Напомню, что у меня есть подробная статья про мониторинг Postfix с помощью Zabbix. Там в том числе выполняется и анализ логов, но локально, а в систему мониторинга уходит результат локальной обработки. Сами логи Postfix не хранятся.

Сегодня я рассмотрю другой вариант - непосредственно хранение логов на внешнем сервере Loki, который сам будет парсить данные и выполнять некоторую аналитику. Я выведу на дашборд метрики:

◽️Количество доставленных и отклонённых писем в виде соотношения и временной шкалы
◽️Статистика по доменам внешних получателей писем от нас
◽️Статистика по полученным письмам локальных доменов нашего сервера
◽️Статистика по отклонённым письмам в разрезе ошибок и доменов

Помимо этого Loki автоматически будет парсить поступающие логи, что позволит выполнять группировки по 24 распознанным полям: имя получателя, имя отправителя, домен отправителя, IP адрес, ID сообщения, статусы и т.д.

Данную заметку я пишу на примере реального почтового сервера, который я настроил по этой своей статье. Это важно, так как в разных версиях Postfix немного отличается формат логов. Я за основу взял готовый Dashboard из базы Grafana и подправил его под свою версию сервера и настроек Alloy, которые я возьму из этой заметки. А сам Loki установлен и настроен так же, как тут.

Первым делом устанавливаем Alloy на почтовый сервер с Postfix. Посмотреть установку можно в предыдущей заметке. Для сбора только почтовых логов достаточно такой конфигурации:

loki.write "default" {
  endpoint {
    url = "http://195.20.47.169:3100/loki/api/v1/push"
  }
  external_labels = {}
}

local.file_match "postfix" {
 path_targets = [{
  __address__ = "localhost",
  __path__  = "/var/log/mail.log",
  instance  = constants.hostname,
  job     = string.format("%s-maillog", constants.hostname),
 }]
}

loki.source.file "postfix" {
 targets  = local.file_match.postfix.targets
 forward_to = [loki.write.default.receiver]
}

После этого логи сразу потекут в Loki. Их можно смотреть в разделе Drilldown ⇨ Logs. В качестве service_name в соответствии с настройками Ally будет указано имя сервера и приписка -maillog. В моём случай это будет mail.zeroxzed.ru-maillog. На картинках другое название, но это мне показалось более удачное.

Далее нам нужно импортировать дашборд. Я положил его в свой репозиторий grafana-loki, в раздел grafana/dashboards/, файл Postfix Delivery Status.json. Его нужно скачать и импортировать в Grafana. Во время импорта в качестве источника данных укажите свой Datasource с Loki. Если он не подцепится автоматически, то после импорта зайдите в настройки дашборда, раздел Variables, укажите его явно в переменной DS_LOKI.

Если у вас Loki и Postfix настроены по моим статьям и заметкам, на которые я дал ссылки, то всё должно получиться, потому что все настройки я взял с работающего сервера. Проверил в момент написания заметки. Как это всё выглядит, видно ниже на скриншотах.

Если что-то не работает на дашборде, значит либо лог немного отличается, там локальный парсер прямо в настройках виджетов, либо выборка по меткам не совпадает, если свои метки ставили. Всё это проверяется тут же, в дашборде, в настройках виджетов. Я так всё и правил в изначальном дашборде. У меня после импорта ничего не работало. Поправил и шаблоны парсинга, и метки под свои настройки, добавил ещё один виджет, разделив внешних и внутренних получателей. В итоге всё получилось.

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

Подобная настройка максимально простая и быстрая, настраивается буквально за 5 минут по готовым конфигам и шаблонам. Плюс, это всё в формате IaC.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#loki #logs #mailserver #postfix

Прорабатываю тему централизованного хранения логов в Loki. Потом для удобства объединю её в большую статью. Уже наметил план. Решил, чтобы вечно не откладывать, резать слона по частям, а не пытаться сразу всё сделать.

На текущий момент я разобрал следующие темы:

1️⃣ Установка, настройка Loki, сбор логов Docker контейнеров
2️⃣ Сбор системных логов Linux (syslog и journald) с помощью Alloy
3️⃣ Сбор логов Postfix и пример создания дашборда для них

Сегодня разберу вопрос отправки журналов с логами Windows. Как бы не пытались аврально импортозаместиться, всё равно инфраструктура на Windows - значительная часть. А может и бóльшая, смотря как считать.

На удивление, настройка Alloy оказалась довольно замороченной, несмотря на то, что есть документация. ИИ по какой-то причине предлагает постоянно неработающие конфигурации. Я что с Linux, что с Windows в итоге разбирался сам.

Основная проблем с метками, привязанными к имени сервера и с их синтаксисом в конфигурации в целом. С непривычки приходится много времени тратить, чтобы разобраться. Вообще, это самая важная часть настройки сбора логов в Loki, так как тут выборка в основном по ним идёт. Надо сразу аккуратно продумать всю схему, чтобы потом не путаться.

Установка Alloy в Windows максимально простая - скачиваем установщик из репозитория и запускаем. Нужен будет файл alloy-installer-windows-amd64.exe.

Alloy устанавливается как служба с автозапуском. После установки нужно отредактировать конфигурацию. К сожалению, если я правильно понял, для логов Windows не работает автообнаружение всех системных журналов, в том числе служб и сервисов с автоматическим назначением меток к ним. Их нужно явно указывать в конфигурации.

Покажу пример с тремя стандартными журналами: System, Application и Security. Положил работающий и отлаженный файл конфигурации в репозиторий. На винде отлаживать неудобно, так как если в конфигурации была ошибка, служба тупо не запускалась с неинформативной ошибкой. Приходилось вручную всё проверять и пробовать разные варианты.

В итоге получил то, что хотел. Для логов назначил две метки:

◽️instance = "имя сервера", например WINSRV01.
◽️job = "имя сервера"-"имя журнала", то есть WINSRV01-application.

С этими метками можно просто открыть все логи сервера по имени и в нём по меткам открыть нужные потоки. Но если будет необходимость сразу из общего списка взять отдельный job конкретного сервера, это тоже можно сделать, так как в названии job будет имя сервера.

Редактируем конфигурацию, перезапускаем службу Alloy и идём в Grafana смотреть логи. Никаких дополнительных настроек делать не надо. Loki сам парсит виндовые логи и выделяет в них стандартные поля: event_id, channel, level, security_userId, timeCreated и т.д. По ним сразу можно делать выборку.

Несмотря на некоторые трудности и неудобства стека на базе Loki и Alloy, пользоваться им приятно в том плане, что базовые настройки относительно просты и функциональны. Можно особо не заморачиваясь просто отправлять логи в Loki и с ними тут будет удобно работать. Он сам распарсит стандартные типы, что позволит сразу выборки делать и рисовать дашборды. Когда изучал ELK с парсингом больше ковырялся. Тут он как-то проще работает.

Далее планирую разобрать сбор логов веб сервера и создание дашбордов для них с важными метриками. Плюс, отдельно хранение и очистку старых журналов. А потом всё это можно будет собрать в единую законченную статью.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#loki #logs #devops

Завершу тему с Loki и Mikrotik окончательным и максимально удобным решением, к которому я пришёл, и которое можно сохранить себе. Я в итоге применил Vector, про который я уже не раз упоминал и которым я пользуюсь для других задач. Мне этот сборщик, обработчик и отправитель логов нравится больше всего. На примере настройки ниже вы сами убедитесь в его удобстве.

Ставим Vector любым удобным для вас способом. Я выбираю пакеты:

# bash -c "$(curl -L https://setup.vector.dev)"
# apt install vector

Приводим конфигурацию /etc/vector/vector.yaml к следующему виду:

sources:
 syslog_udp:
  type: syslog
  address: 0.0.0.0:3514
  mode: udp

sinks:
 syslog_to_loki:
  type: loki
  inputs:
   - syslog_udp
  compression: none
  encoding:
   codec: json
  endpoint: http://192.168.137.30:3100
  labels:
   job: mikrotik

Перезапускаем Vector:

# systemctl restart vector

Сравните это с конфигурациями Alloy. Небо и земля по читаемости. Здесь я на вход принимаю syslog любых форматов. А на выходе выпускаю json. Хотя у Vector в документации на выходе есть формат syslog. Я сначала с ним пробовал, так как это выглядит логично. Но на практике итоговый результат с json лучше.

Теперь идём в Mikrotik в раздел System ⇨ Logging ⇨ Actions и добавляем новое действие. Я назвал его Loki, указал адрес и порт сервера, где установлен Vector, в качестве Remote Log Format выбрал BSD Syslog. После этого в разделе Rules добавил новое правило для логов System действие - Loki. Всё, в Микротике больше ничего делать не надо.

Можно идти в Loki и смотреть логи. Не нужно специально настраивать парсинг логов, добавлять дополнительные метки и т.д. Всё, что надо, уже есть. При такой настройке Vector вы получите в логах следующие поля:

▪️hostname
▪️source_ip
▪️message

Ну и некоторые другие, которые уже не так нужны. Главное, что есть эти. Теперь можно легко различать логи из единого потока по устройствам. И не нужно настраивать разные приёмники или как-то насыщать логи дополнительной информацией об отправителях. При других настройках, в том числе в Alloy, я не смог добиться автоматического парсинга этих полей. А в Vector заработало сразу, благодаря его внутреннему преобразованию syslog в json.

Рекомендую познакомиться с Vector, если ещё не доводилось пользоваться. Он берёт логи из любых источников, например из обычного файла, docker logs, journald, kafka, kubernetes logs, logstash и ещё 40 различных программ и кладёт их в кучу разных источников: loki, elasticsearch, prometheus, clickhouse, postgres, текстовый файл и ещё около 50-ти различных типов. То есть он может взять практически всё что угодно, отправлять куда угодно, попутно преобразовывая. И при этом у него отличная документация с примерами.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#loki #mikrotik