btd 17 янв 2014 в 15:22

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

6 мин

76K

Node.JS*

Туториал

+21

Комментарии 19

azproduction 17 янв 2014 в 15:58

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

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

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

$ DEBUG=http,worker node server.js

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

-1

btd 17 янв 2014 в 21:53

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

miripiruni 17 янв 2014 в 18:25

github.com/nodules/terror

MarcusAurelius 18 янв 2014 в 01:52

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

bobrik 18 янв 2014 в 14:19

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

MarcusAurelius 18 янв 2014 в 15:06

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

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

btd 18 янв 2014 в 15:34

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

btd 18 янв 2014 в 14:21

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

MarcusAurelius 18 янв 2014 в 15:13

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

btd 18 янв 2014 в 15:38

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

MarcusAurelius 18 янв 2014 в 15:44

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

Keenn 18 янв 2014 в 13:25

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

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

btd 18 янв 2014 в 14:28

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

Devgru 18 янв 2014 в 16:48

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

btd 18 янв 2014 в 17:33

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

Sannis 23 янв 2014 в 01:23

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