Microsoft портировала Sysmon для операционной системы Linux. Также компания открыла код сервиса под лицензиями MIT и GPLv2.
Журналирование Windows EventLog и система оповещения для администраторов
4 min
Некоторое количество времени(года три) назад, в попытке найти способ экспорта Windows EventLog, была найдена возможность в удобном виде осуществлять аудит различных событий происходящих на сервере.
Как узнать какие порты на коммутаторах уже не используются
4 min
Чуть больше года назад столкнулся с проблемой, знакомой, наверное, каждому админу: в одном из коммуникационных шкафов закончились почти все свободные порты. Визуально было видно, что почти к каждому порту подключён кабель, свободных осталось только один-два порта, а требовалось подключить около десяти новых девайсов.
Мне было чётко ясно, что на самом деле используются не все порты: какие-то, скорее всего, подключали временно, а затем забыли отключить, сетевые принтеры могли переместить и подключить к другому коммутатору, часть портов были подключены для пользователей, за время сменивших свои кабинеты, и т.д.
Отключение неактивных портов было неприемлемо, так как то, что какой-то порт в данный момент не активен, не говорит о том, что он не использовался 10 минут назад, а пользователь просто отключил свой компьютер, и, скажем, уехал на встречу.
Мне было чётко ясно, что на самом деле используются не все порты: какие-то, скорее всего, подключали временно, а затем забыли отключить, сетевые принтеры могли переместить и подключить к другому коммутатору, часть портов были подключены для пользователей, за время сменивших свои кабинеты, и т.д.
Отключение неактивных портов было неприемлемо, так как то, что какой-то порт в данный момент не активен, не говорит о том, что он не использовался 10 минут назад, а пользователь просто отключил свой компьютер, и, скажем, уехал на встречу.
Перенаправление событий Windows (Event Log) на сервер syslog Linux
8 min
Вступление
Это статья предназначена для системных администраторов, которые знакомы с Linux и используют семейство этих систем в смешанной среде прекрасно осознавая что разные ОС хороши в разных задачах. Так же она будет интересна всем администраторам, даже тем, кто не знаком с линуксом, своей теоретической частью.
В ней описывается простой и надежный способ (даже скорее простая и надежная сторонняя утилита) для передачи системных событий из Event Log’ов серверов на базе Windows в Linux syslog для удобства централизованного хранения и обработки.
Реалии таковы, что в нынешней корпоративной среде самое эффективное и надежное решение основывается на смешении серверных операционных систем из-за качества и способов решаемых ими задач. Рабочие станции, и, следовательно, групповое ими управление и администрирование проще делать на Active Directory; веб сервер, прокси сервер надежнее поставить на линукс; роутером быстрее сделать что-то из Cisco. Эта объективная реальность, с которой работают администраторы многих средних компаний (особенно знакомые с линуксом, от винды так или иначе им все равно не уйти и зачастую в фирме стоят домен-контроллеры на винде и прокси-сервер и роутер на линуксе) — в мелких фирмах можно обойтись одной виндой, в крупной фирме скорее всего раздельно существует администратор линуксоид и администратор виндузятник умело отвечающие за свои сектора. Так или иначе, эта статья не теоретизирование и не исследование на эту тему, эта статья про конкретную задачу, которая практически всегда приходит в голову любому администратору работающему в таком окружении, а вступление что-то затянулось.
NOC: Введение в Fault Management
5 min
События и аварии являются неотъемлемым элементом эксплуатации сети. Ежесекундно фиксируются тысячи событий, служба эксплуатации постоянно занята устранением нескольких аварий, еще несколько аварий наверняка где-то есть, но пока не обнаружены и не диагностированы. Оперативная диагностика и обнаружение аварий является весьма сложной задачей, которая может быть решена только комплексом организационно- технических мер. И не последнюю роль в нем играют автоматизированные средства обнаружения и обработки аварий.
Существует немало систем мониторинга, которые выполняют активную проверку сети и сетевых сервисов по протоколам ICMP и SNMP. Быстрый и неправильный ответ – очевиден. Достаточно настроить волшебную систему мониторинга, и наступит полное счастье. Вся обманчивость этого заблуждения понимается со временем. Сначала выясняется, что обнаружение аварий происходит только на тех сервисах, которые поставлены на мониторинг. Хорошо, если удалось накрыть хотя бы основные сервисы. Остальные, увы, будут ставиться на мониторинг в результате горького опыта и ценой запоздалой реакции. Чуть попозже начинается мистика. Что-то явно работает не так, есть жалобы, но система мониторинга говорит, что все в порядке. В чем причина?
Logreplica: сбор логов со всего кластера в единую точку в реальном времени
4 min
Я продолжаю делиться полезными утилитами, которые использую в различных проектах. На этот раз речь пойдет о logreplica — простом инструменте, который позволяет организовать надежную передачу логов с разных серверов кластера на единую машину с большими дисками «в реальном времени». Это очень удобно, если вы хотите централизованно мониторить или анализировать логи со всего кластера так, как будто бы они пишутся напрямую на единственную машину.Можно сказать, что logreplica задумывался как более удобный и надежный способ сбора логов в центральное место, нежели способ использования настроек syslog/syslog-ng.
Преимущество logreplica — в простоте конфигурирования: вы единственный раз настраиваете «маску» имен лог-файлов и задаете адреса машин-источников, и в дальнейшем логи, соответствующие маске, автоматически и «на лету» складываются на центральную машину (в том числе если на машинах-источниках появляются новые лог-файлы, неизвестные на момент старта logreplica). При добавлении новой машины на ней не нужно ничего донастраивать: достаточно включить ее имя в конфиг-файл.
Приручаем Graylog2 — визуализированный и функциональный сервер лог-файлов
3 min
При достаточно большом парке серверов, с тысячами крутящихся на них сервисов, демонов, скриптов, довольно непросто уследить за многочисленными ошибками внутри. Где-то кончилась память, где-то залип демон, где-то база данных ведет себя неадекватно. Уже не раз обсуждались серверы централизованного хранения логов, хочу рассказать еще об одном удобном и мощном инструменте — Graylog2.
Журналы сервисов — пользователям
4 min
Давно меня заботила проблема, что пользователь шаред-хостинга не всегда знает, что происходит с его аккаунтом — зашёл ли кто по ftp, выполнилось ли задание cron, был ли доступ по ssh, куда делось письмо и вообще отправлялось ли. У большинства хостеров (и у нас в том числе) пользователь мог задать вопрос в службу техподдержки и ждать, когда специалист с соответствующими правами и квалификацией сделает подборку нужных логов. Бонусная проблема — нельзя вот так просто взять и одной командой посмотреть записи в логах относящиеся к пользователю. Это создаёт трудности для системного администратора.Казалось бы простая задача с самого начала начала преподносить сюрпризы.
Удобный просмотр syslog журнала межсетевого экрана D-Link DFL-860E c помощью скрипта на PHP
13 min
В межсетевых экранах D-Link DFL есть несколько минусов в средстве просмотра журнала событий с помощью веб-интерфейса:
— большой поток данных переполняет отображаемый журнал событий и просмотреть логи обычно возможно только за маленький промежуток времени (несколько дней, чаще только за 1 день);
— чтобы посмотреть журнал нужно зайти в веб-панель маршрутизатора (ввести пароль и логин), выбрать статус и отображение журнала. Не имея доступа к веб-панели (не являясь админом устройства) посмотреть логи невозможно, а бывает нужно дать доступ на просмотр логов человеку, которому пароль и логин к устройству давать не нужно;
— в журнале логи разбиваются на маленькие странички, и если журнал большой перелистывать такие странички становится утомительно.
В DFL можно отправлять логи на syslog сервер, который будет писать журнал в файл, правда читать потом такой файл очень неудобно из-за его большого размера и неудобного поиска.
Для тех у кого есть возможность использовать web сервер, выполняющий скрипты на php можно просматривать журнал с помощью небольшого скрипта:
— большой поток данных переполняет отображаемый журнал событий и просмотреть логи обычно возможно только за маленький промежуток времени (несколько дней, чаще только за 1 день);
— чтобы посмотреть журнал нужно зайти в веб-панель маршрутизатора (ввести пароль и логин), выбрать статус и отображение журнала. Не имея доступа к веб-панели (не являясь админом устройства) посмотреть логи невозможно, а бывает нужно дать доступ на просмотр логов человеку, которому пароль и логин к устройству давать не нужно;
— в журнале логи разбиваются на маленькие странички, и если журнал большой перелистывать такие странички становится утомительно.
В DFL можно отправлять логи на syslog сервер, который будет писать журнал в файл, правда читать потом такой файл очень неудобно из-за его большого размера и неудобного поиска.
Для тех у кого есть возможность использовать web сервер, выполняющий скрипты на php можно просматривать журнал с помощью небольшого скрипта:
Маленькая админская история: как поймать OOM
5 min
Админская загадка: На сервере произошло три oom kill'а, а мониторинг сказал только про два. Почему?
В logstash присылаются логи со всех серверов. Он складывает их в elasticsearch. В конфиге logstash'а настроена реакция на всякие странные сообщения, которые свидетельствуют о проблемах. Если сообщение появляется, присылается event мониторингу (shinken), который разными методами начинает беспокоить админов.
Помимо syslog'ов, которые шлют сообщения от большинства приложений, у нас настроена ещё и отправка netconsole от всех ядер. Сама технология проста до невозможности — ядро помимо dmesg'а посылает сообщения в виде UDP-датаграмм на указанный IP и mac-адрес. MAC-адрес нужен потому, что netconsole очень низкоуровневая и заниматься разгадыванием «как из IP сделать MAC» (то есть ARP) не собирается. Благодаря низкоуровневости сообщения проходят даже в ситуациях полного катаклизма. Например, если программный коммутатор перестал работать (и сеть недоступна), сообщения всё равно будут посылаться. Более того, они будут посылаться, даже если в iptables сказано -j drop_vsyo_nafig. И, самое главное и ценное, эти сообщения успешно будут отправлены, если дисковая подсистема полностью не работает. То есть для post-mortem исследований «что именно случилось с зависшим сервером» — самое оно.
Очевидным кандидатом в «плохие» сообщения является сообщение от oom-killer'а.
Итак, возвращаемся к загадке. Идёт пусконаладка, предпродакшен, как, вдруг, апач (точнее, wsgi-приложение) насасывается данных до неприличия, и его прибивают со словами «go be fat somewhere else». Админам приходит сообщение. Казалось бы всё хорошо (ну, в админском смысле «хорошо»). Но…
Случилось три oom'а, сообщения пришли о двух. Мониторинг в порядке, netconsole в порядке. Загадка? Проблемы? Симптомы таинственной неведомой фигни? Звать придворного шамана с бубном?
Конфигурация
Для мониторинга всего у нас настроена связка ganglia-shinken-logstash-elasticsearch-kibana. Полное описание довольно обширно, так что ограничусь только частью, имеющей отношение к проблеме.В logstash присылаются логи со всех серверов. Он складывает их в elasticsearch. В конфиге logstash'а настроена реакция на всякие странные сообщения, которые свидетельствуют о проблемах. Если сообщение появляется, присылается event мониторингу (shinken), который разными методами начинает беспокоить админов.
Помимо syslog'ов, которые шлют сообщения от большинства приложений, у нас настроена ещё и отправка netconsole от всех ядер. Сама технология проста до невозможности — ядро помимо dmesg'а посылает сообщения в виде UDP-датаграмм на указанный IP и mac-адрес. MAC-адрес нужен потому, что netconsole очень низкоуровневая и заниматься разгадыванием «как из IP сделать MAC» (то есть ARP) не собирается. Благодаря низкоуровневости сообщения проходят даже в ситуациях полного катаклизма. Например, если программный коммутатор перестал работать (и сеть недоступна), сообщения всё равно будут посылаться. Более того, они будут посылаться, даже если в iptables сказано -j drop_vsyo_nafig. И, самое главное и ценное, эти сообщения успешно будут отправлены, если дисковая подсистема полностью не работает. То есть для post-mortem исследований «что именно случилось с зависшим сервером» — самое оно.
Очевидным кандидатом в «плохие» сообщения является сообщение от oom-killer'а.
[517935.914380] ntpd invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 [517935.914730] Call Trace: [517935.914807] [<ffffffff816e14ce>] dump_header+0x83/0xbb [517935.914877] [<ffffffff816e155b>] oom_kill_process.part.6+0x55/0x2cf ... с финальным торжествующим: [517935.951044] Out of memory: Kill process 4550 (apache2) score 247 or sacrifice child [517935.951203] Killed process 4550 (apache2) total-vm:2610268kB, anon-rss:2012696kB, file-rss:3928kB
Итак, возвращаемся к загадке. Идёт пусконаладка, предпродакшен, как, вдруг, апач (точнее, wsgi-приложение) насасывается данных до неприличия, и его прибивают со словами «go be fat somewhere else». Админам приходит сообщение. Казалось бы всё хорошо (ну, в админском смысле «хорошо»). Но…
Случилось три oom'а, сообщения пришли о двух. Мониторинг в порядке, netconsole в порядке. Загадка? Проблемы? Симптомы таинственной неведомой фигни? Звать придворного шамана с бубном?
Удобный мониторинг Syslog сообщений c сетевых железок в Zabbix
16 min
Tutorial
Неотъемлемой частью сетевого мониторинга является сбор логов с контролируемых серверов и прочих железок. Ведь сколько бы мы ни создали отдельных элементов данных и триггеров к ним, в какой-то момент возникнет ситуация, что что-то важное мы упустили из виду и не контролируем. Итог: «У нас ничего не работает», а система мониторинга говорит, что все хорошо.
Поэтому первое, что хотелось сделать — собирать все логи в заббиксе, сгруппировав их по узлу сети для того, чтобы всегда можно было пробежаться по сообщениям глазами, не тратя время на доступ на оборудование.
Второе — обратить внимание и на те события, о которых и не подозреваешь.
Как это сделать на серверах или компьютерах, где установлен заббикс-агент, многие знают — есть встроенные элементы данных log[], logrt[].
Но как быть, когда нужно собирать логи с сетевого оборудования, на которое никак не водрузить Zabbix-agent’а? Вообще-то можно, конечно, настроить syslog-сервер на том же ПК, на которой есть заббикс-агент, а дальше при помощи log[] переносить эти данные в заббикс. Вот только элементы данных и триггеры по нему будут прикреплены к узлу сети с заббикс-агентом, что интуитивно малопонятно. А можно ли прикрепить эти данные непосредственно к сетевому устройству? Можно.
Для этого нам понадобится zabbix_sender, Zabbix API и rsyslog на машине с заббикс-сервером или заббикс-прокси. В качестве бонуса также получим быстрый контекстный переход в журнал syslog-сообщений с карты сети.
Как будет выглядеть результат? Ну, примерно вот так:
Контекстный вызов:
Поэтому первое, что хотелось сделать — собирать все логи в заббиксе, сгруппировав их по узлу сети для того, чтобы всегда можно было пробежаться по сообщениям глазами, не тратя время на доступ на оборудование.
Второе — обратить внимание и на те события, о которых и не подозреваешь.
Как это сделать на серверах или компьютерах, где установлен заббикс-агент, многие знают — есть встроенные элементы данных log[], logrt[].
Но как быть, когда нужно собирать логи с сетевого оборудования, на которое никак не водрузить Zabbix-agent’а? Вообще-то можно, конечно, настроить syslog-сервер на том же ПК, на которой есть заббикс-агент, а дальше при помощи log[] переносить эти данные в заббикс. Вот только элементы данных и триггеры по нему будут прикреплены к узлу сети с заббикс-агентом, что интуитивно малопонятно. А можно ли прикрепить эти данные непосредственно к сетевому устройству? Можно.
Для этого нам понадобится zabbix_sender, Zabbix API и rsyslog на машине с заббикс-сервером или заббикс-прокси. В качестве бонуса также получим быстрый контекстный переход в журнал syslog-сообщений с карты сети.
Как будет выглядеть результат? Ну, примерно вот так:
Контекстный вызов:
Сбор логов межсетевого экрана Checkpoint (OPSEC LEA)
5 min
OPSEC LEA (Log Export API) – интерфейс, позволяющий получать логи с сервера управления (Checkpoint SmartCenter).
В основе OPSEC LEA лежит клиент-серверная архитектура. В качестве сервера выступает Checkpoint SmartCenter, который слушает входящие соединения на порт 18184 ТСР (по-умолчанию). Клиент OPSEC LEA подключается к Серверу на вышеуказанный порт и получает логи.
Fw1-loggrabber – программное обеспечение, поддерживающее OPSEC LEA, и предназначенное для получения логов с серверов управления (Checkpoint SmartCenter – далее SC). Fw1-loggrabber может выводить полученные логи на экран, перенаправлять в файл или в syslog.
Существуют версии данного ПО как под Linux, так и под Windows (под windows не поддерживается вывод в syslog).
Дано:
получить логи c SC и передать их по протоколу syslog на внешний syslog сервер.
В основе OPSEC LEA лежит клиент-серверная архитектура. В качестве сервера выступает Checkpoint SmartCenter, который слушает входящие соединения на порт 18184 ТСР (по-умолчанию). Клиент OPSEC LEA подключается к Серверу на вышеуказанный порт и получает логи.
Fw1-loggrabber – программное обеспечение, поддерживающее OPSEC LEA, и предназначенное для получения логов с серверов управления (Checkpoint SmartCenter – далее SC). Fw1-loggrabber может выводить полученные логи на экран, перенаправлять в файл или в syslog.
Существуют версии данного ПО как под Linux, так и под Windows (под windows не поддерживается вывод в syslog).
Дано:
- Сервер управления Checkpoint. Версия ПО Checkpoint – R77.30 (sc.local);
- Сервер с CentOS 6.6 (loggraber.local);
- Syslog сервер (syslog.local).
Задача:
получить логи c SC и передать их по протоколу syslog на внешний syslog сервер.
Мониторинг системных вызовов Linux
7 min
Translation
Если вы инженер в организации, использующей Linux в промышленной эксплуатации, у меня к вам два небольших вопроса.
- Сколько уникальных исходящих TCP-соединений установили ваши серверы за последний час?
- Какие процессы и пользователи инициировали установку этих соединений?
Если вы в состоянии ответить на оба вопроса, отлично — дальше можете не читать. А если ответа нет, то получить эту информацию поможет go-audit.
Cбор логов с rsyslog, именами файлов в тегах, многострочными сообщениями и отказоустойчивостью
17 min
Изображение с сайта oxygen-icons.org
Задача
Передавать лог-файлы на центральный сервер:
- При недоступности сервера не терять сообщения, а накапливать и передавать при его появлении в сети.
- Корректно передавать многострочные сообщения.
- При появлении новых лог-файлов, достаточно перенастройки клиента, не требуется изменение конфигурации сервера
- Можно передавать содержимое всех лог-файлов с соответствующим шаблону именем, причём на сервере их содержимое будет сохраняться раздельно в файлы с таким же именем.
Условия: в инфраструктуре используются только Linux-сервера.
SystemD отстой, да здравствует SystemD
7 min
Translation
Кажется, что systemd — некое яблоко раздора в Linux-сообществе. Как будто не существует нейтральной точки зрения на systemd. Кардинально противоположные мнения предполагают, что вы должны или любить его, или желать уничтожения. Я хочу предложить некую середину. Для начала, обсудим кошмарные свойства systemd.
Тот факт, что существует systemd-escape, сам по себе явно указывает на нечто ужасно неправильное. Если вы никогда не видели или не использовали эту команду в деле, считайте, что вам повезло.
Плохое и кошмарное
systemd-escape
Тот факт, что существует systemd-escape, сам по себе явно указывает на нечто ужасно неправильное. Если вы никогда не видели или не использовали эту команду в деле, считайте, что вам повезло.
Грязное место провайдера: проект blondemine
8 min
В нашей компании имеется распределенная сеть продаж. Связь офиса с магазином обеспечивает маршрутизатор, на котором настроен VPN до центра. И вот, с определенного момента, эта связь стала крайне некачественной, из-за шквала пакетов по 53-му DNS порту. Связь хоть и улучшилась после введения блокирующих правил файрволла, но атаки не прекратились.
Я обратился к провайдеру, с просьбой решить проблему на его стороне. На что получил ответ вынесенный в заголовок: «Ну вы же понимаете, интернет — это грязное место». И тогда я решил бороться с этим явлением самостоятельно.
В результате была собрана система сбора и анализа несанкционированных сетевых пакетов.
А чтобы не утомлять читателя техническими подробностями, самое интересное я расскажу сразу, а тем кто пожелает ее повторить или улучшить рекомендую дочитать до конца.
В результате почти двух месяцев работы, в систему поступило почти 200 миллионов записей. Большая часть (98%) — это атаки типа DNS amplification, которые не раз обсуждались на хабре [1], [2]. Причем атаки начинаются не сразу, а по прошествии некоторого времени, достаточного для попадания нового публичного адреса в базу сканирующих интернет ботов. В оставшейся части событий выделяется большой сегмент атак на 23-й порт. Как я выяснил — это китайские DVR системы Hikvision, разбросанные по всему миру и сканирующих весь интернет на предмет telnet подключений. На трети из них, кстати, как раз заводские логин и пароль. А все остальное — это уже рукотворные переборы портов, попытки залогиниться, опросить по snmp и прочее.
Я обратился к провайдеру, с просьбой решить проблему на его стороне. На что получил ответ вынесенный в заголовок: «Ну вы же понимаете, интернет — это грязное место». И тогда я решил бороться с этим явлением самостоятельно.
В результате была собрана система сбора и анализа несанкционированных сетевых пакетов.
А чтобы не утомлять читателя техническими подробностями, самое интересное я расскажу сразу, а тем кто пожелает ее повторить или улучшить рекомендую дочитать до конца.
В результате почти двух месяцев работы, в систему поступило почти 200 миллионов записей. Большая часть (98%) — это атаки типа DNS amplification, которые не раз обсуждались на хабре [1], [2]. Причем атаки начинаются не сразу, а по прошествии некоторого времени, достаточного для попадания нового публичного адреса в базу сканирующих интернет ботов. В оставшейся части событий выделяется большой сегмент атак на 23-й порт. Как я выяснил — это китайские DVR системы Hikvision, разбросанные по всему миру и сканирующих весь интернет на предмет telnet подключений. На трети из них, кстати, как раз заводские логин и пароль. А все остальное — это уже рукотворные переборы портов, попытки залогиниться, опросить по snmp и прочее.
Как определить объем ваших логов?
3 min
Добрый день!
Сегодня мы рассмотрим распространённый вопрос, с которым сталкиваются все, кто обрабатывает логи или собирается это делать и сейчас приценивается к различным решениям по обработке и хранению. Какой же объем логов в день/неделю/месяц мы будем получать из различных систем и какие ресурсы по хранению мы должны задействовать?
Однозначно точно сказать довольно сложно, но мы попробуем помочь вам примерно разобраться с предполагаемыми объемами, основываясь на нашем опыте.
VyOS OpenSource Router
5 min
В этой статье я хотел поднять не стандартную для меня тему о сетевом маршрутизаторе VyOS. Впервые я познакомился с этим проектом благодаря Нилу Андерсону (Neil Anderson) который составил гайд как у себя дома развернуть мини-лабораторию с NetApp симулятором и VyOS.
VyOS это opensource проект на базе Debian Linux, который родился как форк от проекта Vyatta Core Edition of the Vyatta Routing software. Как и любой роутер VyOS оперирует на третьем уровне OSI и маршрутизирует North-South трафик. VyOS включает в себя следующие ключевые проекты:
Ключевые проекты
VyOS это opensource проект на базе Debian Linux, который родился как форк от проекта Vyatta Core Edition of the Vyatta Routing software. Как и любой роутер VyOS оперирует на третьем уровне OSI и маршрутизирует North-South трафик. VyOS включает в себя следующие ключевые проекты:
- Debian 8, ядро 4.19
- FRRouting (в версии 1.1 и более древних использовался Quagga)
- ISC-DHCP
- Keepalived
- StrongSwan
- OpenVPN
- PowerDNS
- Wireguard
- OpenNHRP
- Accel-ppp
- xL2tpd
- Squid
- mDNS-repeater
- IGMP-Proxy
- iPerf
- более детальный список в Release notes
Создание инкрементального сервера для iOS Team
3 min
Бесплатная книга
После пяти лет наступаний на одни и те же грабли, и полугода поисков DevOps-а, который знает что-такое Provision Profile и как от него зависит развертывание приложения, было принято решение составить пошаговую инструкцию, в картинках, о том, настраивать рабочее окружение в iOS Team с минимальными финансовыми вложениями (к примеру, когда нет проплаченных аккаунтов GitHub или Jira), а работа кипит.
journald вместо syslog
7 min
Tutorial
Использование journald как замена syslog'у для приложений с большим числом логов.Давным-давно, когда были дебаты о том, стоит ли принимать в качестве init-системы systemd (с одной стороны удобно, с другой стороны, довольно токсичный автор...), вместе с systemd приехал и journald. В целом, он ощущался как аппендикс к systemd, и вместе с ForwardToSyslog, он мирно жил на серверах. Дефолтная конфигурация в целом устраивала, а всё нужное можно было по-старинке накрутить в syslog'е.
В одном из проектов у нас образовалась потребность в обработке большого числа логов, и мы решили попробовать journald вместо (r)syslog(d|-ng). Оказалось, что:
journald решает все наши проблемы
документации по нему подозрительно мало (особенно, в сравнении с systemd)
при том, что его поведение более-менее разумно, интуиция о том, как он работает, практически отсутствует и её надо набирать.