К слову, актуально даже на десктопе с теме же амдешными, кривыми GPU дровами.

Приветствую. Имею опыт расследования инцендентов на высоконагруженной системе где за минуту порядка гигабайта. В чем собственно вопрос?

Ну так-то да, у грамотного сисадмина железо и девушки не ломаются.

1) Там в отличие от <random program name> - sync сделан более-менее грамотно. И оно это делает - потому что например при панике семантика файловых операций все же может быть нарушена. Но редко. И, главное, детектируемо.

2) Там есть режим tamper resistant логов. Обычный текстових хаксор просто подрихтует. Да, ремотные сервера, бла-бла, но это сразу - другой уровень затрат и возни, с штатом админов или уймой нагрузки. А их tamper resistant работает и для локалхоста. И таки мешает хаксору подрихтовать лог задним числом. Его можно саботировать - но это будет опять же ЗАМЕТНО. Так что ситуации когда хаксор подрихтовал за собой и не оставил следов станет организовать значительно сложнее.

Есть системы автоматизированного анализа логов.

Когда нет драйверов, нет и багов. Всё просто.

А теперь попробуй то же самое с cron-задачами. Нет, -u crond и прочие вариации не подходят, потому что красношляпые гении решили, что на каждый запуск задачи нужно плодить одноразовые session-c31337.scope. В итоге опять грепаем, только не из файла, а через, ээээ, пайпы. Очень удобно.

> сколько запросов с этого IP было за последние 5 минут

Кому это вообще может быть интересно? Всё, что меньше 100 rps не интересует.

Добро пожаловать в мир явного прокостыливания. И даже так это все - delayed по соображениям эффективности, и без каких-то жестких гарантий.

О ситуации когда форенсик или кто там смог прорубиться в работающую систему и снять дамп и/или ключи оттуда - мы подумаем немного потом :)

Драмаквин в треде, развел соплей будто уже это отключили

Держи такой же настрой, пригодится когда и твою багу к системде закроют с "not a bug" и коротким каментом про "ты не понимаешь как работает компьютер"

По тому, какой вoй поднял, можно судить, что это не "их проблема", а твоя. На ряду с проблемой абсолютной беспомощности в отсутствии васяносоветов из интернетов. Решай проблему - подтягивай компетенции, RTFM, как деды делали, не трать, оплачиваемое хозяином, время на пустой лай. Развёл тут автономию резких, как понос дерзких, пустопорожних пустобрёхов Опеннета. Как ни зайдешь сюда, одно coпливое нытbё - это ему, очередному карапузу, (бесплатно) не сделали, там шнурочки не завязали, тут по-пку не под-тёрли.
Это тебе какой-то рыночный самодур в трудовую написал, что ты специалист? Ну так будь добр, соответствуй!

Никакой мир не предпочёл, тупо навязали вендорлок через крупнейшего вендора, остальные игроки какое-то время оставались на существовавших инструментах, но постепенно всё равно пришлось сдаться.

Впрочем, никто особо и не использует journald, syslog по прежнему текстовый, докер тоже пишет джейсоны в свои текстовые логи, все прочие сервисы, apache, nginx, caddy и прочие тоже пишут в свои логи и у каждого свой формат. По дефолту в journald летят только stdout/stderr выхлопы процессов, запускаемых из systemd, но эти логи полезны только в случае когда сервисы неожиданно падают.

Так, круто, ну и где в результате гайды, хаутушки, примеры? Бенчи? Анализ write amplification, наконец?!

Гугл делает много странной фигни. Они видите ли хотели фуксию одно время вообще. Рассказывая вместе с адептами про планы переезда столицы в Нью-Васюки.

Потом правда оказалось что не столицы а только сельпо и администрации в виде пары чиновников, и захват мира застрял на паре фоторамок, но говорить не мешало же!

Или - кто хочет энтерпрайзно и массово - вот вам андроид вообще! Это - линух который всякие взаимозаменимые винтики и хомы объективно заслуживают. Да, он бастардизирован. Но это то что вы получаете за целование корпоративных ботинок. Об вас взамен начинают вытирать ноги и считать за подставку для ботинок. Какие-то проблемы с этим?!

Потом пойти в магазин и обнаружить что сраный китайский мобильник за 50 баксов - работает намного лучше чем весь этот античный кластерфак...

а если так - "так они хуже всех, насилуют диск"

Ну а кстати вполне очевидно, почему оно так.

В силу архитектуры journald найти нужные строчки он может относительно быстро, а вот выдернуть их и вывести на экран — увы, нет. Накладных расходов целая гора: там же отдельные операции чтения на каждую запись...

Я не вижу как journald "быстро находит" логи, но просто "долго выводит их на экран". Вывод в cat режиме скорости не добавляет вообще, тут дело вообще не в форматировании вывода (который для 100Кб информации и так должен быть моментальным). Скорее всего просто формат файлика логов г-но и алгоритм поиска по этому формату очень неэффективный. Хотя казалось бы, раз уж сделали бдшку вместо потока логов быстро пробежаться по 10 Мб бдшке из которых нам нужно 100 Кб проблем не должно вызывать.