Комментарии 19
У меня есть одна утилитка с альтернативным подходом - тейлить логи за последние N секунд. Логи-то отсортированы, содержат таймстамп так что бинарный поиск нужного места - весьма дешев.
Подход действильно альтернитивный, но непонятно, чем он лучше) Зато понятно, чем хуже. Форматы таймспампа в логах разных приложений могут сильно отличаться: там может отсутствовать года, там могут присутствовать нелатинские буквы. Написать универсальный парсер для всего этого, та ещё задачка...
Форматы таймстампа действительно могут быть разные и утилитка это умеет. А парсер для форматов называется strptime(3) и он уже давно написан :)
А использовалась утилитка в дремучие времена до структурированных логов и всяких логстешей, когда метрики не слались самими приложениями, а парсились из их логов
По-моему проблема высосана из пальца, хотя, может, и в случае автора она актуальна. Но в большинстве случаев каждая запись в логе имееи таймстэмп и в логах всегда ищется место по времени инцидента и дальше смотрится, что было непосредственно перед этим. Зачем мне смотреть с последнего просмотренного места? Там гигабайты и гигабайты новых логов!
Например, чтобы узнавать о проблеме до того, как её заметять пользователи и случится инцидент. Фоновый мониторинг логов на типовые записи о проблемах – стандартная практика.
Согласен, но там этим занят специальный сервис (из коробки или свой), и если он падает, то при перезауске просто продолжает мониторить с конца лога (если свой). Перезапустить сервис - секунды. Делается это тоже автоматически.
А еще лучше, как привильно нааисали ниже, просто использовать нормальную систему хранения и обработки логов. Их действительно много.
Логи бывают разные. К примеру журнал 1С.
А зачем вообще руками смотреть логи, да еще и запоминать позицию? Вроде бы уже XXI век, для постоянной работы с логами есть куча утилит и стоит пользоваться именно ими.
Допустим, мы хотим добавить оповещение, если количество ошибок в логе за фиксированный интервал времени превысило порог. Для этого мы сначала кешируем конец лог файла:
$ cutthelog logfile > /dev/null
а потом добавляем в cron вызов такого однострочника с нужным интервалом
[ $(cutthelog logfile | grep "some error" | wc -l) -ge ${THRESHOLD} ] && echo "ALARM"
Теперь расскажите, как можно решить эту задачу с помощью вашей кучи утилит.
Э, нет конечно. Мы просто вешаем алерт на систему логгинга (которых бесконечное количество на любой вкус). И делаем это без каких-либо операций с продакшен-системой (типа добавления однострочников), крона и так далее.
В стандартном стеке это делается в несколько кликов в графане. Она при этом еще и письмо пришлет или в телегу напишет.
Ну вот серьезно, уже XXI век на дворе, откуда эти идеи времен "приходящих виндовс-админов"?
Виндовые одмины они такие. Им невдомек, что tail существует уже лет 50
Чтобы навесить алерт в графане туда должна прилетать метрика с хоста. Чтобы метрика прилетала, на хосте должен работать собирающий её агент. Чтобы посчитать метрику за прошедший интервал, агент должен открыть лог файл, найти место, где закончил читать его в про... oh, wait!.. так вот же код агента:
echo "stats.${HOSTNAME}.metric_name $(cutthelog logfile | grep "some error" | wc -l) $(date +%s)" | nc ${GRAPHITE} ${GRAPHITE_PORT}
Даже в XXII веке утилита и cron будут актуальны. Все логи будут отправлять в ChatGPT бот, чтобы он разобрался, что делать:
cutthelog logfile | send_to_chatgpt_bot
splunk, graylog, elk, newrelic и прочие уже не в моде?
Кстати, yaznahar, а вы действительно не знаете про современные подходы к observability?
Про системы сбора и хранения метрик, про системы сбора и хранения логов, про разделение метрик, логов и трейсов, про алертинги, про концепцию сайдкаров, про изоляцию продакшена от админов и разработчиков, про контейнеризацию и так далее и так далее?
Пост действительно выглядит как пришедший из прошлого тысячелетия.
Действительно слышал про все эти системы сбора и хранения метрик только краем уха, потому что на масштабах, с которыми работаю, они превращаются в тыкву, и нужно придумывать что-то своё.
CutTheLog – когда он слишком большой