О логгировании в Node.js

[azproduction]

Есть еще одна библиотека — debug (npm debug). Ее очень удобно использовать как в процессе написания библиотек, так и для логирования. Она не имеет привычных уровней логирования, вместо этого вводятся id типа логов, кооторые можно гибко включать, используя wildcard.

var debug = require('debug')('worker');

setInterval(function(){
  debug('doing some work');
}, 1000);

$ DEBUG=http,worker node server.js

Рекомендую ;)

[btd]

Да, знаю про эту вещь, но это не то =)

[miripiruni]

github.com/nodules/terror

[MarcusAurelius]

Несколько вопросов:
1. Есть ли разделение логов по датам, т.е. каждый день, час или месяц начинаем писать в новый файл?
2. Есть ли автоматическое удаление старых файлов (например, храним 100 последних)?
3. Поддерживается ли запись в лог из нескольких процессов (cluster)?
4. Реализована ли буферизация записи в лог на уровне таймеров (запись не чаще N мсек.) и на уровне объема буфера (например, пишем в память 128кб и сбрасываем это на диск в свободное время)?

[bobrik]

4. Это забота ядра, двойная буферизация будет лишней. Вряд ли какой-либо из логгеров делает fdatasync, чтобы что-то изменить.

[MarcusAurelius]

Тем не менее, у класса stream.Writable в Node.js есть собственные буферы чтения и записи, и мы можем управлять их размерами. Более того, я проводил тесты для CentOS 6.5 (64 бит) и Win 7 (64 бит), в обоих случаях производительность записи в логи существенно поднималась, если увеличить буфер записи, выделенный по-умолчанию с 16 кб до 64 кб, а вот при большем увеличении, существенного увеличения производительности нет.

Автору библиотеки, btd: при создании файлового потока 1 строчку можно дописать и будет шустрее, см. пример тут.

[btd]

Спасибо, возьму на заметку.

[btd]

Про intel:
1. Да
2. Да
3. Нет
4. Нет
Если говорить как я делаю н-р logrotate
1. Да
2. Да
3. Не думаю что игра стоит свеч чтобы во время исполнения синхронизировать логи от нескольких процессов. Я лично пишу в разные файлы. Если нужно будет собрать я использую коллектор.
4. Идея понятна, но тут еть несколько моментов: 1. Нода работает в одном процессе, логи пишутся в нем же при краше процесса мы херим логи, 2. В intel используются стримы не думаю что это сложно реализовать на их уровне и просто скормить обработчику собстевенный.

[MarcusAurelius]

По пункту 3: два процесса могут писать в один файл, если оба открывают его с флагом «a». Тут только проблема будет в ротейте, создавать новые и удалять старые файлы должен Master процесс, а не Worker, и не несколько процессов сразу, ну и Worker должен открывать файл уже после того, как Master его создает. Вообще это удобно, представьте, что работает 16 или 32 воркера, это сколько же будет лог-файлов плодиться.

[btd]

Да, я знаю, что можно писать с нескольких процессов, тут проблема не в возможности, а в результате. Что-то мне кажется, что такой лог будет не очень полезным при чтении.

[MarcusAurelius]

Тогда еще нужно будет логировать ID процесса и кто он (Master или Worker). Для веб-сервера полезно, например Apache и Nginx не делают же 32 лог-файла если у них в конфиге установить параметр 32 процесса.

[Keenn]

по поводу таймштампов в винстоне: github.com/flatiron/winston#console-transport
в settings просто указываем timestamp: true и дело в шляпе:



мне лично винстон очень нравится тем что я одновременно подключил 2 транспорта: в файл (в json формате) и в консоль (обычным текстом). хотя я много других и не пробовал.

[btd]

Спасибо я честно не заметил этих опций чуть позже обновлю пост, чтобы людей в заблуждение не вводить. Подключение нескольких транспортов я бы сказал это одна из минимальных вещей которые должна делать либа для логгирования.

[Devgru]

Как-то невежливо списывать библиотеку со счетов только потому, что её надо настраивать :) Winston действительно неплох.

[btd]

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

[Sannis]

Соглашусь что для анализа производительности логи в таком виде трудно применимы :) Потому я и занимаюсь портированием Pinba на Node.js и надеюсь на днях написать об этом.

[arikon]

Портировали? Интересно будет посмотреть.

[broderix]

github.com/Sannis/node-pinba

[arikon]

github.com/baryon/tracer