Посмотрел интересное выступление с HighLoad++ 2021, которое весной выложили в открытый доступ - Есть ли жизнь без ELK? Как снизить стоимость Log Management:

https://www.youtube.com/watch?v=BOVuwr43ZTE

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

Они решили для экономии денег и ресурсов собрать систему сбора логов самостоятельно на базе сборщика логов Vector (по их тестам он оказался быстрее FluentD), парсинг делают им же, обработка с помощью Kafka, данные хранят в ClickHouse, визуализируют с помощью Grafana.

Если вам интересная данная тема, то рекомендую. Я, например, про Vector вообще впервые услышал. Всегда думал, что оптимальный парсер и доставщик логов это FluentD. Обычно его рекомендуют вместо тормозного Filebeat.

#видео #elk #logs

​​Хочу вас познакомить с отличной современной программой по передаче текстовых данных из одних источников в другие. Речь пойдёт про Vector и проект vector.dev. Это пример простой и качественной программы, которая решает одну задачу - взять данные в одном месте, преобразовать их или оставить в неизменном виде и передать в другое место.

Мне она понравилась в первую очередь своим сайтом с подробной информацией обо всех возможностях и настройках. Буквально за несколько минут разобрался с настройками и запустил в работу.

С помощью Vector можно взять данные из источников: File, Docker logs, JournalD, Kafka, Kubernetes logs, Logstash и ещё 40 различных программ и положить их в один из 50-ти типов поддерживаемых приёмников, среди которых: Console, Elasticsearch, File, HTTP, Loki, Prometheus и т.д. 

По пути Vector может делать преобразования. Для каждого источника, преобразования и приёмника есть пример конфигурации, как это можно реализовать. В итоге по частям настраивается полный маршрут.

Вот для примера конфиг для сбора логов JournalD и записи их в файл. Я прямо взял из документации конфиг для JournalD, конфиг для File и совместил их.

Ставим Vector (есть и пакеты, и docker образ):
# curl --proto '=https' --tlsv1.2 -sSf https://sh.vector.dev \
| bash

Рисуем конфиг:

[sources.journal_ntp]
type = "journald"
current_boot_only = true
include_units = [ "ntp" ]

[sinks.log_ntp]
type = "file"
inputs = [ "journal_ntp" ]
path = "/tmp/ntp-%Y-%m-%d.log"

[sinks.log_ntp.encoding]
codec = "text"

Всё просто и понятно - источник, приёмник, преобразование. Можно текст автоматом в json сконвертировать. Я оставил обычный формат.

Создаём дефолтную директорию для Vector и запускаем его:
# mkdir /var/lib/vector/
# vector --config /root/.vector/config/vector.toml

В файле /tmp/ntp-%Y-%m-%d.log будет текстовый лог службы ntp, взятый из journald. По такому же принципу работают и другие направления.

Программа очень простая и удобная. По сути она заменяет более именитых и старых товарищей - fluentd, filebeat и т.д. Частично и logstash. Я принял решение использовать её для сбора логов и отправки в ELK.

⇨ Сайт / Исходники / Документация

#logs #devops

​​Некоторое время назад я рассказывал про программу Vector, с помощью которой удобно управлять потоками данных. Сейчас покажу, как с её помощью отправить логи Nginx в сервис axiom.co, где бесплатно можно хранить и обрабатывать до 500 ГБ в месяц. Это отличная возможность быстро собрать дашборд для анализа логов веб сервера.

Сначала зарегистрируйтесь в axiom.co. Там не нужны ни кредитки, ни какая-то ещё информация, кроме email. Сразу получите аккаунт с очень солидными бесплатными лимитами. Там же создайте новый Dataset и к нему API ключ. Это условный аналог облака Elastic на минималках. Я собственно, про него и хотел рассказать, но решил сразу на конкретном примере. К тому же у вектора не очень очевидная документация, особенно в плане преобразований. В своё время долго разбирался, как там парсинг json и grok фильтры правильно настраивать и описывать в конфигах.

Установите Vector любым удобным способом из документации. Настройте логи Nginx в формате json. Это можно не делать, но тогда понадобится grok фильтр для обработки access лога, что дольше и сложнее, чем использование сразу json. Рисуем конфиг для Vector.

[sources.nginx_access_logs]
type     = "file"
include   = ["/var/log/nginx/access.log"]

[transforms.nginx_access_logs_parsed]
type = "remap"
inputs = ["nginx_access_logs"]
source = '''
. = parse_json!(.message)
'''

[sinks.axiom]
inputs = ["nginx_access_logs_parsed"]
type = "axiom"
token = "xaat-36c1ff8f-447f-454e-99fd-abe804aeebf3"
dataset = "webserver"

У Vector есть готовая интеграция с axiom, что я и указал в sinks. Теперь запускайте Vector и идите в axiom.co. На вкладке Streams увидите свои логи в режиме реального времени.

Теперь можно зайти в Dashboards и собрать любой дашборд на основе данных лога Nginx. Чем более насыщенный лог, что настраивается в конфиге Nginx, тем больше данных для визуализации. Я для тестового сервера собрал дашборд буквально за 10 минут. Смотрите во вложении к заметке.

Такая вот заметка-инструкция получилась. Vector я уже рекомендовал, теперь советую посмотреть на описанный сервис. Меня никто не просил его рекламировать. Он просто удобный и есть функциональный бесплатный тарифный план. В него включены также 3 оповещения. Например, можно настроить, что если у вас в минуту будет больше 10 500-х ошибок сервера, прилетит оповещение. Или что-то ещё. Там большие возможности для насыщения, аггегации и других манипуляций с данными. Разобраться проще, чем в ELK или OpenSearch.

Для любителей grok, как я, покажу пример transforms в Vector своего формата логов Nginx. Вот пример формата лога, который я обычно использую, где есть всё, что мне надо:

  log_format full   '$remote_addr - $host [$time_local] "$request" '
        'request_length=$request_length '
        'status=$status bytes_sent=$bytes_sent '
        'body_bytes_sent=$body_bytes_sent '
        'referer=$http_referer '
        'user_agent="$http_user_agent" '
        'upstream_status=$upstream_status '
        'request_time=$request_time '
        'upstream_response_time=$upstream_response_time '
        'upstream_connect_time=$upstream_connect_time '
        'upstream_header_time=$upstream_header_time';

Вот grok фильтр в Vector:

[transforms.nginx_access_logs_parsed]
type = "remap"
inputs = ["nginx_access_logs"]
source = '''
. = parse_grok!(.message, "%{IPORHOST:remote_ip} - %{DATA:virt_host} \\[%{HTTPDATE:access_time}\\] \"%{WORD:http_method} %{DATA:url} HTTP/%{NUMBER:http_version}\" request_length=%{INT:request_length} status=%{INT:status} bytes_sent=%{INT:bytes_sent} body_bytes_sent=%{NUMBER:body_bytes_sent} referer=%{DATA:referer} user_agent=\"%{DATA:user_agent}\" upstream_status=%{DATA:upstream_status} request_time=%{NUMBER:request_time} upstream_response_time=%{DATA:upstream_response_time} upstream_connect_time=%{DATA:upstream_connect_time} upstream_header_time=%{DATA:upstream_header_time}")
'''

#nginx #logs #devops

В логировании современных систем и программ в основном используют два подхода к распределению логов и событий по важности. Один из них поддерживает 8 уровней важности, или значимости. Не знаю, как правильно перевести severity levels, передав их смысл. Эти уровни пришли из формата логов syslog, появившемся в 80-х годах. Вот эти уровни:

▪ Emergency
▪ Alert
▪ Critical
▪ Error
▪ Warning
▪ Notice
▪ Informational
▪ Debug

Чем ниже идти по приведённому списку, тем больше информации будет в логах. Соответственно, если настраиваете систему логирования, то внимательно смотрите, какой уровень логов будете собирать.

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

Например, такой формат логов поддерживает Nginx или Apache. В них явно можно указать, какого уровня события будут логироваться.

В современной разработке прижилась немного упрощённая и более конкретная схема важности логирования или ошибок:

▪ Fatal
▪ Error
▪ Warn
▪ Info
▪ Debug
▪ Trace

Уровни Trace и Debug нужны чаще всего для разработчиков, которые занимаются отладкой. Иногда они объединены в один уровень Debug. С остальными четырьмя уровнями приходится работать уже сопровождению или поддержке.

Уровень Info это обычно информация о работе сервиса: запуск, остановка, перезагрузка и т.д. Реакция на это не нужна. А вот на уровень Warn и выше уже может потребоваться реакция, хотя и не всегда. К примеру, если у вас почтовый сервер Postfix смотрит в интернет, то все неудачные попытки аутентификации будут уровня Warn. И реагировать на это не обязательно. А вот если у вас система в закрытом контуре и неудачных аутентификаций там быть не должно, то на подобное событие нужна реакция.

Уровни Error и Fatal самые критичные. Очевидно, что на них реакция требуется всегда. В соответствии с уровнями событий, настраиваются разные реакции. К примеру, я события типа Info в Zabbix собираю, но никаких реакций и оповещений на них не делаю. С дашбордов обычно тоже их убираю, либо делаю отдельные информационные панели. Например, со списком действий пользователей VPN, подключения и отключения. Реакция на это не нужна, но иногда бывает нужно быстро посмотреть, кто сейчас подключен. Отлично подойдёт виджет с такой информацией.

Так что рекомендую осмысленно подходить к классификации событий. Это помогает и упрощает настройку систем мониторинга и оповещений.

#linux #logs

​​Постоянно приходится заниматься вопросами сбора и анализа логов веб серверов. Решил сделать подборку инструментов для этих целей от самых навороченных, типа ELK, до одиночных консольных утилит.

✅ Сам я чаще всего использую именно ELK, потому что привык к нему, умею настраивать, есть все заготовки и понимание, как собрать необходимые дашборды. Минусов у этого решения два:
◽ELK очень прожорливый.
◽Порог входа довольно высокий. Но тем не менее, ничего запредельного там нет. У меня знакомый с нуля по моей статье за несколько дней во всём разобрался. Немного позадавал мне вопросов, чтобы побыстрее вникнуть в суть. А дальше сам. В итоге всю базу освоил, логи собрал, дашборды сделал. В общем, было бы желание, можно и без дорогих курсов разобраться с основами. Сразу плюс к резюме и будущей зарплате.

Про #elk я много писал как здесь, так и на сайте есть разные статьи.

🟢 Альтернатива ELK - Loki от Grafana. Сразу скажу, что опыта с ним у меня нет. Так и не собрался, нигде его не внедрил. Всё как-то лениво. Использую привычные и знакомые инструменты. Плюсы у Loki по сравнению с ELK существенные, а конкретно:
◽кушает меньше ресурсов;
◽проще настроить и разобраться.
Из минусов — меньше гибкости и возможностей по сравнению с ELK, но во многих случаях всего этого и не надо. Если бы сейчас мне нужно было собрать логи веб сервера и я бы выбирал из незнакомых инструментов, начал бы с Loki.

🟢 Ещё один вариант — облачный сервис axiom.co. У него есть бесплатный тарифный план, куда можно очень быстро настроить отправку и хранение логов общим объёмом до 500 ГБ!!! Зачастую этого хватает за глаза. В него можно отправить распарсенные grok фильтром логи, как в ELK и настроить простенькие дашборды, которых во многих случаях хватит для простого анализа. Мне понравился этот сервис, использую его как дубль некоторых других систем. Денег же не просит, почему бы не использовать.

Далее упомяну системы попроще, для одиночных серверов. Даже не системы, а утилиты, которых иногда может оказаться достаточно.

🟡 Классная бесплатная утилита goaccess, которая умеет показывать статистику логов веб сервера в режиме онлайн в консоли. Либо генерировать статические html страницы для просмотра статистики в браузере. Устанавливается и настраивается очень легко и быстро. Подробности есть в моей заметке. Интересная программа, рекомендую. Пример html страницы.

🟡 Ещё один вариант консольной программы — lnav. Он заточен не только под веб сервер, но понимает и его формат в виде базовых настроек access логов.

Перечислю ещё несколько решений по теме для полноты картины, с которыми я сам не работал, но знаю про них: Graylog, OpenSearch.

❗️Если забыл что-то известное, удобное, подходящее, дополните в комментариях.

#logs #webserver #подборка

​​На днях поднимал вопрос сбора логов веб сервера и забыл упомянуть одну систему, которую я знаю уже очень давно. Пользуюсь лет 8. Речь пойдёт про New Relic. Это очень мощная SaaS платформа по мониторингу и аналитике веб приложений и всего, что с ними связано, в том числе серверов. Я не раз уже писал о нём, но можно и ещё раз напомнить.

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

В итоге сейчас есть бесплатный тарифный план без необходимости привязки карты. Просто регистрируетесь на email. Вам даётся 100 ГБ для хранения всех данных с любых сервисов системы. А их там море, они все разные. Это очень удобно и просто для контроля. Хотите мониторить сервера - подключайте хосты, настраивайте метрики. Хотите логи - грузите их. Используется то же доступное пространство.

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

Работа с New Relic по мониторингу сервера и сбора логов выглядит следующим образом. Регистрируетесь в личном кабинете, получаете ключ. Во время установки агента используете этот ключ. Сервер автоматом привязывается к личному кабинету. Дальше за ним наблюдаете оттуда. В настройках агента можно включить сбор логов. Какие - выбираете сами. Можно systemd логи туда отправить, или какие-то отдельные файлы. К примеру, логи Nginx. Если предварительно перевести их в формат json, то потом очень легко настраивать визуализацию в личном кабинете.

Понятное дело, что у такого подхода есть свои риски. Агент newrelic имеет полный доступ к системе. А уж к бесплатному тарифному плану привязываться и подавно опасно. Используйте по месту в каких-то одиночных серверах или временно для дебага.

Мониторинг сервера позволяет посмотреть статистику по CPU, I/O, Memory в разрезе отдельных процессов. Это очень удобно и нигде больше не видел такой возможности.

#мониторинг #logs

​​Если у вас есть желание максимально быстро и без лишних телодвижений проанализировать логи веб сервера, то можно воспользоваться типичной windows way программой http Logs Viewer. Скачиваете, устанавливаете, открываете в ней свой лог.

Программа платная, но базовые возможности доступны в бесплатной версии. После открытия лога она автоматом парсит значения из него в виде типовых полей: url, код ответа, IP адрес и т.д. Для IP адреса сразу же определяет страну. Можно тут же сделать сортировку по странам, кодам ответа, урлу и прочим записям в логе.

Если загрузить большой лог, то можно по всем распознанным значениям посмотреть статистику за разные промежутки времени. Тут уже начинается платная функциональность. Бесплатно доступен очень ограниченный набор отчётов.

Программа удобная и простая. Кто привык тыкать мышкой, а не грепать в консоли, будет прям кайфово. Нашёл, отсортировал, скопировал, выгрузил и т.д. Всё наглядно с привычным скролом для больших списков. И никаких вам ELK.

⇨ Сайт

#webserver #logs

В современных дистрибутивах Linux почти везде вместо традиционных текстовых логов средствами syslog используются бинарные логи journald. Они также, как и текстовые логи, иногда разрастаются до больших размеров, так что необходимо заниматься чисткой. Вот об этом и будет заметка. На днях пришлось на одном сервере этим заняться, поэтому решил сразу оформить заметку. Написана она будет по мотивам Debian 11.

Смотрим, сколько логи занимают места:
# journalctl --disk-usage
Обычно они хранятся в директории /var/log/journal.

Настройки ротации логов могут быть заданы в файле /etc/systemd/journald.conf. Управляются они следующими параметрами:

[Journal]
SystemMaxUse=1024M
SystemMaxFileSize=50M

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

# systemctl restart systemd-journald.service

Так же вы можете обрезать логи в режиме реального времени. Примерно так:

# journalctl --vacuum-size=1024M
# journalctl --vacuum-time=7d

В первом случае обрезали старые логи, чтобы их осталось не больше 1024 мегабайт. Во втором обрезали все логи, старше 7-ми дней.

Кстати, если вы не хотите связываться с настройками journald, то можете команды выше просто в cron добавить на регулярное выполнение. Это тоже будет решение по ротации логов.

По умолчанию journald может занимать до 10% объёма раздела, на котором он находится. Но не более 4 Гб. На деле именно с ограничением в 4 Гб я чаще всего и сталкивался. Если у вас общий системный диск 40+ Гб, то как раз логи в 4 Гб у вас и будут.

Если у вас в логи спамит какая-то конкретная служба, то имеет смысл для неё отдельно настроить ограничение, выделив её логи в отдельный namespace. Для этого в unit службы в раздел [Service] добавьте отдельное пространство логов. Покажу на примере ssh. Запускаем редактирования юнита.
# systemctl edit ssh
Добавляем:
[Service]
LogNamespace=ssh

Создаём в директории /etc/systemd/ отдельный конфиг для этого namespace journald@ssh.conf со своими параметрами:

[Journal]
SystemMaxUse=20M

Перезапускаем службу:
# systemctl restart ssh

Смотрим его логи отдельно:
# journalctl --namespace ssh

Я, кстати, по старинке, всегда запускаю текстовые логи через syslog. Просто привык к ним. В итоге у меня и бинарные логи в journal, и текстовые в syslog. Примерно как с cron и timers. Через systemd больше функциональности и настройки гибче, но старые инструменты проще и быстрее в настройке.

#linux #logs #systemd #journal

В systemd есть все необходимые инструменты для централизованного сбора логов. Вот они:

▪ systemd-journal-remote — служба, принимающая или забирающая записи журналов на центральном сервере
▪ systemd-journal-upload — служба, отправляющая локальные журналы на центральный сервер

Всё это позволяет без сторонних инструментов настроить централизованный сбор логов со множества серверов в одном месте. В Debian эти службы устанавливаются одним пакетом systemd-journal-remote.

# apt install systemd-journal-remote

После этого можно подготовить конфиг службы. Если нет нужды, то можно отключить работу по https, чтобы не заморачиваться с сертификатом, если сбор логов идёт по закрытым каналам связи. Для этого копируем системный unit в /etc/systemd/system и меняем параметр ExecStart:

# cp /lib/systemd/system/systemd-journal-remote.service \
/etc/systemd/system/systemd-journal-remote.service

[Service]
ExecStart=/lib/systemd/systemd-journal-remote --listen-http=-3 --output=/var/log/journal/remote/

Заменили ключ --listen-https на --listen-http. Если захотите использовать https, то сертификат надо будет прописать в /etc/systemd/journal-remote.conf. Далее достаточно создать необходимую директорию, назначить права и запустить службу:

# mkdir -p /var/log/journal/remote
# chown systemd-journal-remote:systemd-journal-remote /var/log/journal/remote
# systemctl daemon-reload
# systemctl start systemd-journal-remote

Служба запустится на tcp порту 19532.

Перемещаемся на сервер, который будет отправлять логи и устанавливаем туда этот же пакет. Затем идём в конфигурационный файл /etc/systemd/journal-upload.conf и добавляем туда путь к серверу:

[Upload]
URL=http://10.20.1.36:19532

Запускаем службу и проверяем, что она успешно начала отправку логов:

# systemctl start systemd-journal-upload
# systemctl status systemd-journal-upload

Если ошибок нет, то можно идти на центральный сервер и там смотреть логи от удалённого сервера.

# journalctl -D /var/log/journal/remote -f

Сами логи будут лежать в отдельных файлах с ip адресом отправляющего сервера в названии. Примерно так: remote-10.20.1.56.journal. Можно посмотреть конкретный файл:

# journalctl --file=remote-10.20.1.56.journal -n 100

Для этих логов действуют те же правила фильтрации, что и для локальных. Смотрим все логи юнита ssh:

# journalctl --file=remote-10.20.1.56.journal -u ssh

Или только сообщения ядра:

# journalctl --file=remote-10.20.1.56.journal -k

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

С помощью systemd-journal удобно собирать логи в одно место с множества хостов без установки на них стороннего софта. А потом уже централизованно отправить в любую другую систему хранения логов на обработку. Я ещё забыл упомянуть, что systemd-journal-remote можно настроить так, что он сам будет ходить по серверам и забирать с них логи.

#linux #logs #systemd #journal

​​Ещё одна заметка про systemd и его встроенные инструменты для работы с логами. Есть служба systemd-journal-gatewayd, с помощью которой можно смотреть логи systemd через браузер. Причём настраивается она максимально просто, буквально в пару действий. Показываю на примере Debian.

Устанавливаем пакет systemd-journal-remote:

# apt install systemd-journal-remote

Запускаем службу:

# systemctl start systemd-journal-gatewayd.service

Порт по умолчанию 19531. Идём смотреть логи в браузер: http://10.20.1.36:19531/browse. Это обзорный url. Тут в выпадающем списке можно выбирать любой лог.

Можно посмотреть логи только текущей загрузки: http://10.20.1.36:19531/entries?boot.

Можно через curl забирать эти же логи в json формате. Примерно так для юнита ssh:
# curl --silent -H 'Accept: application/json' \
   'http://10.20.1.36:19531/entries?UNIT=ssh.service'

Все параметры и возможности описаны в документации. Обращаю внимание, что можно не только локальные логи открывать для доступа, но и собранные с удалённых машин. Если вы настроили такой сбор по моей вчерашней заметке, то директорию с логами для systemd-journal-gatewayd можно указать отдельно. Параметр -D DIR, --directory=DIR.

#linux #logs #systemd #journal

​​Для сбора и обработки логов есть много различных решений, как self-hosted, так и облачных. Наиболее популярные - ELK и Loki. Первый прям вообще монстр, его надо плотно изучать, прежде чем пользоваться. Второй попроще, но тоже сходу его не одолеть. Надо разбираться. А самый простой вариант централизованного сбора - какой-нибудь syslog сервер. Во все эти хранилища логи надо как-то передавать и желательно перед этим обрабатывать. Одним из таких сборщиков и обработчиков является NXLog.

NXLog - относительно старое (2011 год) и известное решение, которое есть как в редакции Community, так и Enterprise. Различия в возможностях можно тут посмотреть. NXLog поддерживает установку на многие популярные системы, в том числе Windows. Для него есть готовые наборы фильтров для обработки логов. Это в целом популярный вариант для сбора логов в той же винде и отправки их куда-то дальше. Например, в ELK или другое хранилище. Я сам NXLog никогда не использовал. Предпочитаю другие варианты (Vector, Fluentd, Winlogbeat). Но много раз видел отзывы о том, что с его помощью собирают и обрабатывают логи с винды и потом куда-то пересылают.

Сейчас покажу на практике, чем NXLog может быть полезен. Я сам им никогда не пользовался, но он меня заинтересовал. Скорее всего воспользуюсь, когда возникнет задача под него.

Допустим, нам надо распарсить логи postfix и куда-то передать в формате json. Качаем пакет под свою систему и устанавливаем. Все настройки будут в едином конфигурационном файле. Идём в раздел документации Integration, находим там Postfix. Видим готовый пример фильтра, который распарсит лог и выдаст результат в json, чтобы получилось вот так:

{
"EventReceivedTime": "2016-10-05 16:38:57",
"SourceModuleName": "postfix",
"SourceModuleType": "im_file",
"EventTime": "2016-10-10 01:23:46",
"HostName": "mail",
"SourceName": "postfix",
"Component": "smtp",
"ProcessID": "2538",
"Message": "4F9D195432C: to=<destination@example.com>, relay=mail.example.com[216.150.150.131], delay=11, status=sent (250 Ok: queued as 8BDCA22DA71)",
"QueueID": "4F9D195432C",
"Recipient": "<destination@example.com>",
"RelayHostname": "mail.example.com",
"RelayIP": "216.150.150.131",
"Delay": "11",
"Status": "sent",
"SMTPCode": "250",
"QueueIDDelivered": "8BDCA22DA71"
}

Я нигде не видел такого простого готового решения. Правда специально и не искал. Когда нужно было парсить логи postfix для ELK, писал свой фильтр для Grok. Не скажу, что это было сильно сложно, но изначально для Grok нужно какое-то время, чтобы разобраться. Я просто это уже умею.

Другой пример. Допустим, вы хотите парсить логи Windows DHCP server. То же самое. Идёте в документацию и смотрите готовый конфиг для парсинга виндовых логов аудита dhcp сервера. Там же будет рассказано, как включить нужные логи. NXLog даже историю браузеров умеет парсить. Очень любопытное решение для сбора истории пользователей. Мне даже в голову никогда не приходило, что это можно и нужно централизованно собирать у пользователей, а не где-то на шлюзе. Думаю, нужно для решения каких-то задач по безопасности.

Список готовых интеграций у NXLog солидный. Он умеет в том числе ходить в SQL базы и брать данные оттуда. В документации есть примеры. Дальше логи можно отправить в различные популярные современные хранилища - ELK, Graylog, Splunk или тот же Syslog. В простых случаях можно забирать логи, парсить и выгружать их рядом обработанными в отдельный лог файл.

⇨ Сайт / Исходники

#logs

Не знаю, как вы, а я так и не привык к логам в journald. Уже и команды основные запомнил, но всё равно кажется каким-то неудобным интерфейс для просмотра логов через systemctl. Поэтому, когда настраиваю сервер на Debian, в обязательном порядке возвращаю туда rsyslog:

# apt install rsyslog

И сразу же делаю некоторые настройки, которые мне кажутся удобными. Во-первых, складываю логи cron в отдельный файл. Во-вторых, убираю логи почты из основного файла /var/log/syslog. Если на сервере идёт отправка почты, то она забивает весь этот файл. Потом неудобно в нём системные записи искать. Для всего этого делаю такие настройки в /etc/rsyslog.conf:

..................................
*.*;auth,authpriv.none,cron.none,mail.none   -/var/log/syslog
cron.*             -/var/log/cron.log
mail.*             -/var/log/mail.log
..................................

Мне интересно, много таких же ретроградов, которые предпочитают текстовые логи? Мне лично удобнее зайти в /var/log и открыть нужный лог файл, чтобы посмотреть информацию. Это кажется быстрее и удобнее, чем тыкаться в systemctl, указывать там службы, даты, с какого конца читать и т.д.:

# systemctl list-units --type=service
# journalctl -u ssh -r

Проще открыть текстовый файл и промотать куда надо. Ещё и не у всех служб есть логи в systemd. Тот же fail2ban всю основную информацию пишет в текстовый файл. По крайней мере это его поведение по умолчанию. Специально не проверял, можно ли его логи в journald отправить. С postfix, dovecot та же история. В итоге проще и удобнее всё в старых добрых текстовых файлах хранить и смотреть в одном месте - /var/log.

#logs

​​Нашёл очень функциональный инструмент для логирования действий пользователей в подключениях по SSH к серверам. Речь пойдёт про open sourse проект sshlog. Выглядит он так, как-будто хотели сделать на его основе коммерческий продукт, но в какой-то момент передумали и забросили. Сделан он добротно и целостно. Расскажу по порядку.

📌 С помощью sshlog можно:

▪️ Логировать все подключения и отключения по SSH.
▪️ Записывать всю активность пользователя в консоли, в том числе вывод.
▪️ Отправлять уведомления по различным каналам связи на события, связанные с SSH: подключение, отключение, запуск команды и т.д.
▪️ Отправлять все записанные события и сессии на Syslog сервер.
▪️ Собирать метрики по количествам подключений, отключений, выполненных команд и т.д.
▪️ Наблюдать за чьей-то сессией и подключаться к ней для просмотра или взаимодействия.
▪️ Расширять функциональность с помощью плагинов.

Сразу скажу важное замечание. Записывать события пользователя root нельзя. Только обычных пользователей, даже если они сделают sudo su. В описании нигде этого не сказано, но я сам на практике убедился. Плюс, увидел такие же комментарии в вопросах репозитория.

Установить sshlog можно из репозитория разработчиков:

# curl https://repo.sshlog.com/sshlog-ubuntu/public.gpg | gpg --yes --dearmor -o /usr/share/keyrings/repo-sshlog-ubuntu.gpg
# echo "deb [arch=any signed-by=/usr/share/keyrings/repo-sshlog-ubuntu.gpg] https://repo.sshlog.com/sshlog-ubuntu/ stable main" > /etc/apt/sources.list.d/repo-sshlog-ubuntu.list
# apt update && apt install sshlog

Репозиторий для Ubuntu, но для Debian тоже подходит. После установки автоматически создаётся служба systemd. В директории /etc/sshlog/conf.d будут 2 файла конфигурации:

- log_all_sessions.yaml - запись ssh сессий в директорию /var/log/sshlog/sessions, каждая сессия в отдельном лог файле, сохраняется в том числе вывод в консоли, а не только введённые команды.
- log_events.yaml - запись событий: подключения, отключения, введённые команды, общий лог для всех.

В директории /etc/sshlog/samples будут примеры некоторых других настроек. Вся конфигурация в формате yaml, читается легко, интуитивно. Возможности программы большие. Можно логировать только какие-то конкретные события. Например, запуск sudo. Либо команды от отдельного пользователя. Это можно настроить либо в событиях, либо в исключениях. Подробно механизм описан отдельно: sshlog config.

Функциональность sshlog расширяется плагинами. Они все находятся в отдельном разделе с описанием и принципом работы. Все оповещения реализованы в виде плагинов. Есть готовые для email, slack, syslog, webhook. Оповещения отправляются при срабатывании actions. Так же по этим событиям могут выполняться и другие действия, например, запуск какой-то команды.

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

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

⇨ Сайт / Исходники

#ssh #logs #security