Winston: Можно ли использовать winston на внешнем интерфейсе (например, в браузере) для ведения журнала?

Я не пробовал, но это может помочь https://github.com/farpoint/meteor-winston-client

Это связано с: https://github.com/flatiron/winston/issues/180

По этой ссылке 404 @joshacheson !!

Есть ли у вас прогресс в этом вопросе?

Основываясь на отзывах от #582, кажется, что любой будущий PR должен будет сосредоточиться на разделении основной логики и транспорта, а не на использовании прокладок, таких как brfs . Это будет большое структурное изменение, и почти наверняка потребуется руководство от основных разработчиков по стилю и подходу, поскольку в конечном итоге они останутся теми, кто будет поддерживать это.

Хорошей новостью является то, что код в основном чист и хорошо структурирован, но потребуются некоторые рекомендации от основных разработчиков по стилю и подходу. Не могли бы @indexzero / @pose поделиться своими мыслями?

Есть ли прогресс в решении этой проблемы?

Чувак, я возлагал большие надежды, когда увидел пакет, а потом заметил, что браузер не поддерживает.
Для меня это было бы здорово заменить в браузере некоторые доморощенные вещи.

+1

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

Я просто просматривал это, и мне кажется позорным, что, несмотря на то, что у него есть http-транспорт, похоже, нет стандартного клиента для браузера/другого.

Грустно, что мне придется использовать bunyan

есть новости по этому поводу?

Если вы действительно хотите его использовать, вы можете просто написать для него собственный транспорт, например:

const Transport = require('winston-transport');

export default class BrowserConsole extends Transport {
  constructor(opts) {
    super(opts);

    this.name = 'BrowserConsole';
    this.levels = {
        error: 0,
        warn: 1,
        info: 2,
        debug: 4,
    };

    this.methods = {
        error: 'error',
        warn: 'warn',
        info: 'info',
        debug: 'log',
    };

    this.level = opts.level && this.levels.hasOwnProperty(opts.level)
                  ? opts.level : 'info';
  }

  log(method, message) {
    setImmediate(() => {
      this.emit('logged', method);
    });

    const val = this.levels[method];
    const mappedMethod = this.methods[method];

    if (val <= this.levels[this.level]) {
      // eslint-disable-next-line
      console[mappedMethod](message);
    }
  }
}

Затем вы можете использовать его следующим образом:

import BrowserConsole from './BrowserConsole';

const { createLogger, transports } = require('winston');

const log = createLogger({
  level: 'info',
});

if (process.env.NODE_ENV !== 'production') {
  log.add(new BrowserConsole({
    level: 'info',
  }));
}

С этим транспортом вы получаете бесполезное предупреждение, потому что он считается устаревшим кодом. Также было бы красиво добавить возможность использовать другие консольные методы ( table , dir , trace , ...), но для простоты так и есть.

Спасибо @chrisvoo , я пробовал это решение, но получил ошибку:

ReferenceError: Buffer is not defined
    replacer 
    json.js/module.exports< 
    _transform 
    _stream_transform.js/Transform.prototype._read
    _stream_transform.js/Transform.prototype._write
    doWrite
    writeOrBuffer
    _stream_writable.js/Writable.prototype.write
    log

@ dmitry-salnikov Я не знаю, кстати, я не могу понять, почему этот код использует потоки. Возможно, мой вариант использования был слишком простым. Попробуйте поделиться, как вы его используете.

@chrisvoo Я скопировал реализацию BrowserConsole в отдельный файл, затем в другой файл вставил вторую часть кода, и после добавления транспортного кода BrowserConsole (последняя строка вашего фрагмента) я просто пробовал:

log.info('hello world');

Затем я получил ошибку и попытался:

log.log('info, 'hello world');

Оба вызова возвращают одну и ту же ошибку.

Моя среда, которая позволяет использовать Node в браузере, — это Meteor.js v1.6 (Node 8.8.1). Также я не изменил ни одной строки вашего фрагмента кода.

Кстати: я начал использовать Winston не так давно, поэтому, возможно, что-то делаю не так.

@dmitry-salnikov какую ошибку вы получаете? Типа "информация не является функцией"? Может быть, по какой-то причине он плохо импортируется.

@chrisvoo, пожалуйста, взгляните:

Содержимое BrowserConsole.js (вы можете увидеть его в дереве файлов) точно такое же, как в вашем фрагменте.

И я согласен с вами, я чувствую, что что-то не так с импортом, но не могу понять, почему :( Не могли бы вы поделиться своими мыслями по этому поводу?

Какая у тебя версия Винстона? Мой:

"winston": "^3.0.0-rc1",
"winston-transport": "^3.0.1"

На самом деле то же самое

$ npm ls | grep winston
├─┬ [email protected]
│ └── [email protected]
└── [email protected]
$ cat package.json | grep winston
    "winston": "^3.0.0-rc1",
    "winston-transport": "^3.0.1"

Пытаясь решить эту проблему, я сделал еще один тест:

import winston from 'winston';
import BrowserConsole from '/imports/BrowserConsole.js';

const format = winston.format;
// next line throws exception, see below
const { combine, timestamp, label, printf, colorize, prettyPrint } = format;

const logger = winston.createLogger({
...

и получил следующую ошибку: Cannot find module './combine'

Вот трассировка стека и соответствующий код (скриншот браузера):

Похоже, что-то действительно плохо импортировано. @chrisvoo , не могли бы вы взглянуть?

В Winston 3.0.0 транспорты являются потоками. Однако в browserify-stream readableStream instanceof Stream не выполняется. Это заставляет Winston вернуться к обертыванию транспорта в оболочку Legacy и выдать предупреждение. Я сделал PR, чтобы использовать другой метод определения потоковости: #1145

@Jasu правда, я тоже это заметил, я ранее отправил вопрос по этому поводу на winston-transport . Я также скоро отправлю запрос на извлечение, чтобы консольный транспорт был изоморфным.

IGNOREME: я комментирую здесь, чтобы легко найти эту проблему в будущем [поскольку я не могу сделать это, подписавшись в одиночку] (https://github.com/isaacs/github/issues/283).

Я столкнулся с той же проблемой, Error: Cannot find module './combine' .

+1

@chrisvoo : ниже приведена ошибка, когда я пытаюсь запустить ваш фрагмент (winston и winston-transport находятся в 3+ версиях)
ОШИБКА в winston-transport/index.js
Модуль не найден: ошибка: не удается разрешить «поток» в node_modules/winston-transport.

есть ли шанс, что PR #1145 (открыт в ноябре 2017) будет объединен в этом году? :подмигивание:

@dmitry-salnikov #1145 был объединен с master. Хотя еще не в релизе.

ЗАКРЫТО ЗАКРЫТО ЗАКРЫТО.

Спасибо за поддержку, картошка

5 лет, по крайней мере, его осуществление. Winston по-прежнему остается лучшей системой ведения журналов для JavaScript IMO.

Спасибо!

Это останется открытым до тех пор, пока в нашем наборе тестов не появятся тесты, подтверждающие поддержку браузера. Однако похоже, что большинство крайних и угловых случаев, связанных с babel и webpack, были решены.

Здесь мы любим Winston и нуждаемся в промежуточном программном обеспечении для ведения журнала на стороне клиента.

С момента внедрения браузера прошло некоторое время, и мы хотели бы использовать его с этого момента.

Любое приблизительное представление о поддержке браузера, прежде чем ждать модульных тестов и полного охвата браузера?

Пытался импортировать winston в мой проект и не смог со следующим сообщением:
ОШИБКА в ./\~/winston/lib/winston/tail-file.js
Модуль не найден: ошибка: не удается разрешить «fs» в «/Users/me/workspaces/app/node_modules/winston/lib/winston»
@ ./\~/winston/lib/winston/tail-file.js 10:11-24
@ ./\~/winston/lib/winston/transports/file.js
@ ./\~/winston/lib/winston/transports/index.js
@ ./\~/винстон/lib/winston.js
@ ./src/app/app.module.ts
@ ./src/main.ts

index.js winston import Transports, которые импортируют «.file», для которых требуется «fs».

Как мне отписаться от этого свежего ада

• Майкл

Во вторник, 7 августа 2018 г., в 14:19 Kfir [email protected] написал:

Пытался импортировать winston в мой проект и не смог со следующим
сообщение:
ОШИБКА в .//winston/lib/winston/tail-file.js
Модуль не найден: ошибка: не удается разрешить «fs» в
'/Users/me/workspaces/app/node_modules/winston/lib/winston'
@ .//winston/lib/winston/tail-file.js 10:11-24
@ .//winston/lib/winston/transports/file.js
@ .//winston/lib/winston/transports/index.js
@ ./~/винстон/lib/winston.js
@ ./src/app/app.module.ts
@ ./src/main.ts

winston index.js import Transports, которые импортируют «.file», которые требуют
'фс'.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/winstonjs/winston/issues/287#issuecomment-410946148 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AE3lcdZ3aQKEVYvYB2TXjh0dnQ1FaBS2ks5uOTFhgaJpZM4A2vjK
.

@mjcd вы застряли здесь навсегда 😆 (j/k, вы можете отписаться, используя ссылку в письме или через gh)

У меня была та же ошибка, что и у @KErez при использовании веб-пакета.

Обычный способ решить эту проблему - поместить node: { fs: 'empty' } в конфигурацию вашего веб-пакета - и, очевидно, не пытайтесь использовать транспорт File из браузера, это не сработает. Было бы неплохо, если бы мы могли сделать пакет winston в веб-пакете без этой дополнительной настройки конфигурации, но idk, если это возможно. Другие популярные пакеты рекомендуют то же самое, хотя https://github.com/pugjs/pug-loader/issues/8#issuecomment -328331541 предполагает, что мы можем исправить это в пакете winston.json. Кто-нибудь хочет попробовать это и открыть PR, если он решит эту ошибку (т.е. без изменения конфигурации веб-пакета вашего приложения, просто изменив package.json winston)?

Я получаю сообщение об ошибке из-за setImmediate... Я не понимаю, почему, поскольку @chrisvoo , кажется, преуспевает. Может быть, потому что вы используете полифилл?

Моя связанная проблема: https://github.com/winstonjs/winston/issues/1489

Сделал пакет на основе кода @chrisvoo (большое спасибо) здесь:
https://www.npmjs.com/package/winston-transport-browserconsole.

Кроме того, там есть небольшой образец, так что вы можете сравнить с выводом консоли winston по умолчанию.

Обычный способ решить эту проблему — поместить node: { fs: 'empty' } в конфигурацию вашего веб-пакета.

Планируется ли поддержка пакетов браузера webpack без необходимости внесения этого изменения в конфигурацию webpack?

Было бы неплохо, если бы мы могли сделать пакет winston в веб-пакете без этой дополнительной настройки конфигурации, но idk, если это возможно. Другие популярные пакеты рекомендуют то же самое, хотя pugjs/pug-loader#8 (комментарий) предполагает, что мы могли бы исправить это в пакете winston.json. Кто-нибудь хочет попробовать это и открыть PR, если он решит эту ошибку (т.е. без изменения конфигурации веб-пакета вашего приложения, просто изменив package.json winston)?

@DABH К сожалению, я не думаю, что это так просто. Вы, ребята, используете поле браузера, чтобы определить другую точку входа. Я считаю, что его можно использовать либо для определения другой точки входа, либо для замены определенных модулей, как описано в этом билете, но не для того и другого. Но поскольку вы уже создаете свою собственную версию браузера, возможно, ее можно просто удалить из нее. Я возьму пик, если у меня будет шанс в эти выходные.

Есть ли прогресс в этом? Прошло 6 лет, а завтра будет 2020 :-)

Возможно, решением было бы переупаковать winston, чтобы транспортеры были их собственными модулями. Звучит как лучшее решение

мы можем использовать Winston в angular? как ?

@ArpithaGMGowda не со стандартным угловым интерфейсом командной строки

Тогда что мы можем использовать для Angular 7??
Любая идея

Я использовал js-logger в своем последнем проекте, который работал очень хорошо и позволял мне отправлять журналы в elk, хотя похоже, что в прошлом году он не проявлял особой активности: https://github.com/jonnyreeves/js-logger .
Есть хорошие службы ведения журналов, которые также могут вам подойти, например track.js.

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

Проблема с Winston, основанная на коде, нуждается в модернизации без нарушения основных функций.

Транспортный уровень должен быть разделен на собственные подформы, которые, в свою очередь, приведут к критическим изменениям, которые, как мне кажется, команда не хочет вносить. В точку, если только команда не захочет принять новую экосистему. Я не уверен, что ремонтируемый PR будет одобрен.

вы пробовали использовать NGX-Logger " https://www.npmjs.com/package/ngx-logger "?

@ArpithaGMGowda Думаю, мне не нравится писать базу кода, которая привязывает вас к установленной структуре. Код должен быть максимально независимым от пользовательского интерфейса до сервисных вызовов. Мне также нравится идея единого механизма. Почему один способ для бэкэнда, а другой для фронтенда

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

@ Джордан-Холл Интересно, скоро ли у нас будет RC (и спасибо).
Необходимость модифицировать сторонние веб-пакеты, чтобы они не ломались, когда они используют наш проект / библиотеку, в которой используется winston, борется.

@MarcoMedrano Это фундаментальное изменение, которое теоретически будет новой библиотекой, когда я ее закончу.

@pose Как вы относитесь к отделению транспортных уровней от основного пакета? Мне нравится Уинстон, но экосистему нужно менять.

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

Чтобы это работало, вам нужно установить winston , logform и winston-transport в качестве зависимостей.

Вот код, который вам нужен для реализации этого.
Обратите внимание , что это написано на машинописном языке, пример javascript ниже.

import * as winston from 'winston';
import {TransformableInfo} from 'logform';
import TransportStream = require('winston-transport');

// enumeration to assign color values to
enum LevelColors {
  INFO = 'darkturquoise',
  WARN = 'khaki',
  ERROR = 'tomato',
}

// type levels used for setting color and shutting typescript up
type Levels = 'INFO' | 'WARN' | 'ERROR';

const defaultColor = 'color: inherit';

//! Overriding winston console transporter
class Console extends TransportStream {
  constructor(options = {}) {
    super(options);

    this.setMaxListeners(30);
  }

  log(info: TransformableInfo, next: () => void) {
    // styles a console log statement accordingly to the log level
    // log level colors are taken from levelcolors enum
    console.log(
      `%c[%c${info.level.toUpperCase()}%c]:`,
      defaultColor,
      `color: ${LevelColors[info.level.toUpperCase() as Levels]};`,
      defaultColor,
      // message will be included after stylings
      // through this objects and arrays will be expandable
      info.message
    );

    // must call the next function here
    // or otherwise you'll only be able to send one message
    next();
  }
}

// creating silent loggers with according levels
// silent by default to be automatically deactivated
// in production mode
export const logger = winston.createLogger({
  transports: [
    new Console({
      silent: true,
      level: 'info',
    }),
  ],
});

// don't log anything in production mode
// probably should go further and return non
// working logger function to reduce
// execution time and improve speed results
// on application
if (process.env.NODE_ENV !== 'production') {
  logger.transports.forEach(transport => (transport.silent = false));
}

и вот пример javascript

import * as winston from 'winston';

import {TransformableInfo} from 'logform';
import TransportStream = require('winston-transport');

// enumeration to assign color values to
const LevelColors = {
  INFO: 'darkturquoise',
  WARN: 'khaki',
  ERROR: 'tomato',
}

const defaultColor = 'color: inherit';

//! Overriding winston console transporter
class Console extends TransportStream {
  constructor(options = {}) {
    super(options);

    this.setMaxListeners(30);
  }

  log(info, next) {
    // styles a console log statement accordingly to the log level
    // log level colors are taken from levelcolors enum
    console.log(
      `%c[%c${info.level.toUpperCase()}%c]:`,
      defaultColor,
      `color: ${LevelColors[info.level.toUpperCase()]};`,
      defaultColor,
      // message will be included after stylings
      // through this objects and arrays will be expandable
      info.message
    );

    // must call the next function here
    // or otherwise you'll only be able to send one message
    next();
  }
}

// creating silent loggers with according levels
// silent by default to be automatically deactivated
// in production mode
export const logger = winston.createLogger({
  transports: [
    new Console({
      silent: true,
      level: 'info',
    }),
  ],
});

// don't log anything in production mode
// probably should go further and return non
// working logger function to reduce
// execution time and improve speed results
// on application
if (process.env.NODE_ENV !== 'production') {
  logger.transports.forEach(transport => (transport.silent = false));
}

Вы можете изменить цвета в перечислении LevelColors. Если вы хотите изменить форматирование, взгляните на строку 29.

Чтобы добавить поддержку уровня отладки. установите level в настройках консоли на 'debug' .
Также можно добавить поддержку всех стандартных уровней Winston, то есть: появление, предупреждение, крит, ошибка, предупреждение, информация и отладка. Если вы хотите использовать и их, вам нужно добавить назначение этого объекта в конфигурацию levels в корне createLogger.

{
   emerg: 0,
   alert: 1,
   crit: 2,
   error: 3,
   warn: 4,
   info: 5,
   debug: 6,
}

а затем добавьте значения цвета в перечисление LevelColors.

Я изо всех сил пытаюсь получить четкое представление о статусе этой проблемы. Могу ли я использовать Winston в своем приложении React?

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

Моя ситуация такова, что мое приложение React работает в контейнере Docker за прокси-сервером nginx / Let's Encrypt, поэтому у меня нет доступа к каким-либо выводам консоли JavaScript; Поэтому я хотел бы направить любой вывод журнала на сервер системного журнала.

Я успешно настроил контейнер Docker syslog-ng , который объединяет выходные данные журнала из базы данных, серверной части и некоторых других контейнеров, из которых состоит мой проект, но я не могу найти прямой/канонический подход к системному логированию. вывод из интерфейса React.

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

@ z00m1n Это в основном зависит от вашего варианта использования. Я использую winston в браузере для регистрации всех запросов и вызовов функций, которые я делаю. И если я нахожусь в производственной среде, я ограничиваю вывод только ошибками печати.

И использование моего кода и замена оператора console.log чем-то другим сработало бы.

Однако, прежде чем вы напишете хакерское решение для этой работы, я бы предложил использовать sentry.

Это также зависит от того, есть ли у вас контроль над webpack. К сожалению, этот удивительный пакет устарел архитектурно, что делает невозможным его решение.

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

@gcperrin Не уверен, что это можно назвать проблемой производительности, но я провел несколько тестов и получил следующие результаты:
среда разработки: он записывает что-то в консоль
среда prod: она ничего не регистрирует, но вызывает функцию журнала

_console.info (среда разработки)_; 1,863 с для 10 000 журналов. (0,1893 мс каждый)
_logger.info (среда разработки)_: 7,980 с для 10 000 журналов. (0,7980 мс каждый)

_logger.info (рабочая среда)_; 3,731 с для 10 000 бревен. (0,3731 мс каждый)

Это означает, что если вы используете мою функцию, чтобы отключить регистраторы в рабочей среде, у вас все равно будет синхронный код, работающий в течение 0,3731 мс (потенциально даже больше). Это может быть не проблема производительности, но если у вас есть несколько сотен журналов, которые не работают в рабочей среде, это может привести к задержке вашего веб-приложения.

Есть ли способ использовать winston для сохранения входа в файловую систему на стороне браузера?

У меня есть приложение React, и я хочу хранить журналы на стороне клиента в файловой системе. Пожалуйста, предложите некоторые мысли.

Заранее спасибо.