Comments 18
tail -f -s 5 /var/log/<file>
Для логов лучше -F
С -f если в момент просмотра произошла ротация логов - так и будете смотреть старый файл, а данные будут писаться уже в новый.
Спасибо. В принципе все нормально, по делу и довольно очевидно.
Но, знаете, мне когда-то сказали, что всякий раз, когда ты пишешь
$ cat /path/file | grep -i "any"в мире умирает один котик. Не используй конвейер без надобности.
grep -i "any" /path/fileв большинстве случаев более предпочтительно. Безусловно это не самый критичный момент, и даже вкусовщина. Но определённый смысл в ней есть.
Мне кажется cat с grep используют из-за того, что не нужно запоминать порядок аргументов - после cat один аргумент (файл, тут всё понятно), и содержимое передаём на grep, собственно, если указать единственный аргумент, это будет искомый текст.
А когда используем только grep, то нужно помнить, что сначала указываем текст, потом имя файла. Снижаем нагрузку на комп, увеличиваем на свой мозг :) Конечно, чуть больше и дольше поработать с этими инструментами, и уже будет на автоматизме.
В целом, тут имеется смысл когда имеется -Hr, а в контексте одного файлика вообще смысла особого не имеет. Пайплайны ничего не нагружат, не жрут память и работают отлично.
С cat даже удобнее, сначала просто cat, посмотрел в целом что там есть, а дальше уже докидываешь | grep xxx, | grep -v yyy и разбираешься). Но в целом да, я согласен, вкусовщина.
@brammatorтут чет сломалась обработка обратных кавычек...
Эээээ.
А при чём тут я?
Тьфу блин, я хотел @Boomburum захайлайтить...) Прошу прощения!
Согласны, но это уже дело привычки.
Какие ещё инструменты вы используете?
почему для логов не использовать ELK и его возможности по анализу/мониторингу и уведомлениям
к нему есть cli?(я не очень знаком с темой, по этому только через страницу поиск делаю)
Конечно можем использовать, почему бы и нет? Про ELK написано в параграфе про анализ данных, единственное, что в статье вопрос рассматривается не в разрезе мониторинга в реальном времени, а в исследовании имеющихся данных уже после возникновения инцидента.
Ну, у нас, к примеру, всякие логи (access/error логи nginx'а, всякие высеры различных сервисов, ...) валятся на "центральный" логгер через rsyslog, и в целом нет никакой проблемы запустить что-то вроде `tail -f xxx-access.log` и посмотреть что происходит именно сейчас.
Да, есть и разделная запись логов, ну с каждой ноды в свою папочку, и параллельно есть ещё папочка с агрегированными логами, всё средствами rsyslog.
в `/var/log/*` смотрим а в journalctl не смотрим? как-то это странно нет?
Топ-10 артефактов Linux для расследования инцидентов