Filog version 0.2.1 isomorphic logger released

announce
1

The first release of the Filog logger for Meteor in the 0.2.x series is out:

Description

FiLog is a highly configurable isomorphic logger for Meteor applications, published as a NPM module, supporting configurable logging strategies and custom processing and log sending destinations.

Out of the box, it can log to the console (browser, server), the Meteor database, any Syslog server, and includes a “tee” logger to send to multiple destinations. On the browser, it can log to its own Meteor server over DDP, or to a centralized FiLog log aggregation server over HTTP.

Changes from 0.1.x series

  • Event context is now split by side (client, server, mobile).
  • Better stringifying process, supporting objects with a message key
  • Source code 100% converted to TypeScript 3.4.x
  • Test coverage using Jest, over 80%
  • Quality control using Travis CI, CodeCov, CodeBeast, and Snyk for security.
  • Now includes a test_harness to support integration tests in CI.
3 Likes
2

Logging is a real pain for meteor projects. I’m using ostrio:logger with some customizations. I didn’t use yours but it’s great to see a npm package about logging.

I just want to share what I want to see in a logging package;
Dynamic levels: I’m just logging debug level logs if the user activates it.
User Id: User id in every log content.
Function Name: File Name, Method, Class, Function or whatever possible must be included in every log content.
Line Number: Line number will be great, but I couldn’t solve it :frowning:
Rolling mechanism: My logs are rolling with a date parameter. Flexibility is very important for different projects.
Which side: Logging to the browser is important but sending these logs to a file or syslog in the server with [CLIENT] prepend is a real plus.

Your package seems great. Is your package cover these topics?

1 Like
3
  • Levels: the 8 standard RFC5424 levels. Using one of the available Strategies, you can choose to handle the various levels differently.
  • You can get it by using the included MeteorUserProcessor. You don’t get it if you don’t want it, to limit logging cost
  • Stack trace: on the browser, on errors/exceptions only, via runkit
  • Line number: same
  • Rolling: not sure what this means. Timestamps are taken at every step: logging action in the browser, send to the server, server handling, send to the write target. In addition you can add any ProcessorInterface implementation of your choice to massage the event before it gets written.
  • Which side: deciding whether to log events on server or client is your choice. Syslog is available from the servers, so you can log from the browser to a logging server (over DDP or HTTP) and from there log to a central syslog.

So it seems you’re covered :wink:

2 Likes