История изменений

ты знаешь, что syslog - это не текстовые логи вообще-то? syslog - это RFC 5424, протокол удаленной передачи логов? теперь смотри.

Знаю. Более того — не только (и не столько) этот. Потом что legacy syslog все ещё более активно используется (в том числе той же openbsd).

есть такая классическая ситуация... ну допустим ISP, домашние сеточки (в одной такой я работал), там линуксов штук 20-30 (на самом деле не знаю точно, сколько в других отделах), а сетевого оборудования ... черт, я уже не помню... ну пара тысяч умных свичей на город, допустим. и они все могут сливать логи по syslog в одно какое-то место. общий коллектор логов.

Я так на работе делаю.

жорналд не является стандартом - это а. жорналд - изначальное не содержал средств для удаленной передачи логов - это б (а то, что содержит сейчас - это г).

Никто этого и не утверждал.

для интеграции линуксов теперь надо настраивать вот это самое проксирование логов в rsyslog. journald пока разберется со своими структурами и ring buffer всеравно создаст нагрузку на сервер. если это нагруженный сервер, где много логов, он создаст большую нагрузку. молись, чтобы при этом не надо было сохраняться вот этим самые нетекстовые логи локально, ибо journald by design более тормозной (делал минитесты. он раза в три более тормозной), чем любой писатель текстовых логов. особенно rsyslog, который уже больше десятилетия задрачивают на перфоманс в таких ситуациях.

Кхм... во-первых, я знаю, какой rsyslogd быстрый (нет, не такой быстрый, как хотелось бы), потому что в начале года я чинил потери логов на нашем централизированном лог-хранилище. Во-вторых, в моей конторе мы шлем ВСЕ логи со ВСЕХ наших серверов (несколько сотен штук). И это не умные свичи, это фронты, которые фигачат 24/7. И нет, journald <-> rsyslogd даже не в top5 потребителей ресурсов.

ты знаешь, что syslog - это не текстовые логи вообще-то? syslog - это RFC 5424, протокол удаленной передачи логов? теперь смотри.

Знаю. Более того — не только (и не столько) этот. Потом что legacy syslog все ещё более активно используется (в том числе той же openbsd).

есть такая классическая ситуация... ну допустим ISP, домашние сеточки (в одной такой я работал), там линуксов штук 20-30 (на самом деле не знаю точно, сколько в других отделах), а сетевого оборудования ... черт, я уже не помню... ну пара тысяч умных свичей на город, допустим. и они все могут сливать логи по syslog в одно какое-то место. общий коллектор логов.

Я так на работе делаю.

жорналд не является стандартом - это а. жорналд - изначальное не содержал средств для удаленной передачи логов - это б (а то, что содержит сейчас - это г).

Никто этого и не утверждал.

для интеграции линуксов теперь надо настраивать вот это самое проксирование логов в rsyslog. journald пока разберется со своими структурами и ring buffer всеравно создаст нагрузку на сервер. если это нагруженный сервер, где много логов, он создаст большую нагрузку. молись, чтобы при этом не надо было сохраняться вот этим самые нетекстовые логи локально, ибо journald by design более тормозной (делал минитесты. он раза в три более тормозной), чем любой писатель текстовых логов. особенно rsyslog, который уже больше десятилетия задрачивают на перфоманс в таких ситуациях.

Кхм... во-первых, я знаю, какой rsyslogd быстрый (нет, не быстрый), потому что в начале года я чинил потери логов на нашем централизированном лог-хранилище. Во-вторых, в моей конторе мы шлем ВСЕ логи со ВСЕХ наших серверов (несколько сотен штук). И это не умные свичи, это фронты, которые фигачат 24/7. И нет, journald <-> rsyslogd даже не в top5 потребителей ресурсов.