CutTheLog – когда он слишком большой

Больше десяти тысяч серверов. Завидую твоей осведомлённости о том, как всё работает у Гугла.

CutTheLog – когда он слишком большой

Действительно слышал про все эти системы сбора и хранения метрик только краем уха, потому что на масштабах, с которыми работаю, они превращаются в тыкву, и нужно придумывать что-то своё.

CutTheLog – когда он слишком большой

Чтобы навесить алерт в графане туда должна прилетать метрика с хоста. Чтобы метрика прилетала, на хосте должен работать собирающий её агент. Чтобы посчитать метрику за прошедший интервал, агент должен открыть лог файл, найти место, где закончил читать его в про... 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

CutTheLog – когда он слишком большой

Подход действильно альтернитивный, но непонятно, чем он лучше) Зато понятно, чем хуже. Форматы таймспампа в логах разных приложений могут сильно отличаться: там может отсутствовать года, там могут присутствовать нелатинские буквы. Написать универсальный парсер для всего этого, та ещё задачка...

CutTheLog – когда он слишком большой

Например, чтобы узнавать о проблеме до того, как её заметять пользователи и случится инцидент. Фоновый мониторинг логов на типовые записи о проблемах – стандартная практика.

CutTheLog – когда он слишком большой

Допустим, мы хотим добавить оповещение, если количество ошибок в логе за фиксированный интервал времени превысило порог. Для этого мы сначала кешируем конец лог файла:

$ cutthelog logfile > /dev/null

а потом добавляем в cron вызов такого однострочника с нужным интервалом

[ $(cutthelog logfile | grep "some error" | wc -l) -ge ${THRESHOLD} ] && echo "ALARM"

Теперь расскажите, как можно решить эту задачу с помощью вашей кучи утилит.

Как перестать жить и начать беспокоиться о потреблении памяти

Я стакливался с этой ошибкой в скрипте отправки метрик в Graphite. Когда сервис отключали для плановых работ, накапливалось столько данных, что скрипт не мог их переварить.

Логирование в объектах Python. Путь перфекциониста

@logged(name="Arthur")
class MyClass:

Здесь logged сначала вызывается с одним именованным аргументом name и возвращает декоратор, который уже применяется к MyClass

Логирование в объектах Python. Путь перфекциониста

Мы и так добавляем классу атрибут логгера self.log и можно использовать его, если так больше нравиться. Или я чего-то не понял?