wedvich / structured-log-seq-sink Goto Github PK

There are currently no type definitions for this project to use in Typescript.

structured-log puts exceptions in the LogEvent's error field. This should be pushed to Seq's Exception field.

See http://docs.getseq.net/docs/posting-raw-events

We are currently using the window.onunhandledrejection function to log any unhandled rejected promises within our code.

The issue we are seeing is that structured-log-seq-sink is not handling any of it's internal promises being rejected, thus causing the window.onunhandledrejection to be raised.

This is causing a infinite loop for us as when the seq server is not available, the fetch promise fails, causing an window.onunhandledrejection event to raised, which we handle and then try to log the error and the cycle continues.

Here is some example code to reproduce the issue

var structuredLog = require('structured-log');
var seqSink = require('structured-log-seq-sink');

var logger = structuredLog.configure()
  .writeTo(seqSink({ url: "http://INVALID_URL_TO_SIMULATE_SEQ_NOT_AVAILABLE" }))
  .writeTo(new structuredLog.ConsoleSink())
  .create();

window.onunhandledrejection = (event) => {
  logger.error(
    'A window.onunhandledrejection exception occured: {errorMessage}',
    event.reason ? event.reason.message : null
  )
  return false
}

logger.info('this causes an infinite loop')

While we can write code to work around the issue, I believe the solution is to swallow any exceptions that occur within the sink. Especially given that we are never given access to the fetch promise to handle ourselves.

Thoughts?

When using an API key to send events , the minimum accepted level for events can be set for that API key in Seq. A header is returned in the HTTP response with the minimum supported level when logging. This sink could use an internal minimum level filter that's updated by whatever Seq gives it.

• Add internal minimum level filter
• Update minimum level with response value from Seq

Changelog would be great.
At least for future changes.

http://keepachangelog.com/en/1.0.0/

Instead of sending events as soon as they arrive, it would be beneficial to batch them and send them at regular intervals to reduce the number of HTTP requests.