A fine logger package for Meteor.JS applications (client + server)
GPL-3.0 License
FiLog is a highly configurable isomorphic logger for Meteor applications, 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.
FiLog is based upon low-level NPM packages::
Read the Documentation.
(level, message, context)
triplet, in which
level
is an RFC5424 number (0..7)message
is a plain string or can be converted to one automaticallycontext
is a plain Objectwindow.onerror
handling) and exception reporting.logger.arm()
method, and can be disabled by thelogger.disarm()
method.client/main.js
:
instantiates any number of "processors": instances of classes derived from
ProcessorBase
. These are able to add information to a message on its way
to the logging destination. Current concrete processors are:
BrowserProcessor
: adds browser-related information, such as userMeteorUserProcessor
: adds user-related information if any isfgm:accounts-drupal
.RoutingProcessor
: adds request-related information, such as theinstantiates any number of "senders": instances of classes derived from
SenderBase
. These are able to receive a (level, message, context)
triplet ("event") and forward it somwhere else. Current concrete senders
are:
ConsoleSender
: output the message using console.log
MeteorClientHttpSender
: HTTP POST the message to the Meteor serverROOT_URL
MongodbSender
: store the event in a collection in the Meteor MongoDBNullSender
: ignore the message.SyslogSender
: send the event to syslog, on server only: including it onTeeSender
: send the event to all sender instances passed to itsinstantiate a sending "strategy": instance of a class derived from
StrategyBase
. There are able to decide, based on an event, where it
should be sent by available senders. They may also modify the logger
instance at the last step of its construction, Two concrete strategies are
currently available:
LeveledStrategy
: based on the level of the message, it defines threeTrivialStrategy
uses a single sender for all messages. Especially usefulconstructs a ClientLogger
instance, passing it the strategy instance, like:
let logger = new ClientLogger(new LeveledStrategy(
new NullSender(),
new ConsoleSender(),
new MeteorClientHttpSender(Meteor.absoluteUrl('logger'))
));
adds processor instances to the logger instance, like:
logger.processors.push(
new BrowserProcessor(),
new RoutingProcessor(),
new MeteorUserProcessor(Meteor)
);
is now able to log events, like:
logger.warn("Some warning condition", { foo: "bar" });
with this configuration:
LeveledStrategy
constructor), the logger passes the now-richMeteorClientHttpSender
server/main.js
is configured in much the same way as the client, so it has its own logger
,
typically configured with just a MongodbSender
instance for all levels.
let sender = new MongodbSender(Mongo, 'logger');
let logger = new ServerLogger(
new LeveledStrategy(sender, sender, sender),
WebApp);
logger.processors.push(new MeteorUserProcessor());
in the example above, it receives the POSTed event, and proceed to log it
the server may also initiate a logging action, for example in a publish function or Meteor method. It can use the same API:
logger.error("Some server condition", { baz: "quux" }
Logger.log()
method adds atimestamp.log
key.timestamp.store
key.These two timestamps are here to alleviate any issue resulting from a clock difference between clients and servers.
Any sender can add extra keys to the context, under the timestamp
main key,
to enable timing diagnostics.
The module contains tests. Some of them are unit tests and need nothing special
to run, while others are currently implemented as integration tests and assume
you have a working harness project using Filog, exposed on
http://localhost:3000
.
Start by compiling the package:
meteor yarn run ts-compile
Then you can run :
meteor yarn run test-unit
meteor yarn run test-integration
meteor yarn run test
meteor yarn run cover
To run integration tests, you need to run the provided test_harness project in one terminal, and the tests in another one. Alternatively, you could also roll your own bespoke test harness, which will need to have Filog configured.
This file is needed to allow Filog to operate on the /logger
URL: otherwise,
Meteor will handle it natively and return a 200 with the default application
page, failing the integration tests.
cd (filog_dir)/test_harness
meteor yarn
meteor run --port 3100
This example uses port 3100 to avoid conflicting with existing applications on
the default Meteor port (3000). To use another port, be sure to change it in
__tests__/integration/harness.ts
too.
cd (filog_dir)
meteor yarn
meteor yarn run compile
meteor yarn run test
meteor yarn run cover
TIP Reading the .travis.yml
file can be useful too.