This is a transport module for the winston logger winstonjs/winston for logging with Logsene by Sematext.
Winston-Logsene combines the flexibility of using the Winston logging framework with Logsene (think Hosted Elasticsearch + Kibana). Create your free account and access token here.
var winston = require('winston')
var logsene = require('winston-logsene')
var logger = new winston.Logger()
logger.add (logsene, {token: process.env.LOGSENE_TOKEN, type: 'test_logs'})- token - Create your free account and access token here.
- type - Type of your logs - please note you can define Elasticsearch mapping templates in Logsene
- url - Logsene receiver URL (e.g. for Logsene On Premises), defaults to
'https://logsene-receiver.sematext.com/_bulk' - handleExceptions - boolean 'true' logs 'uncaught exceptions'
- exitOnError - if set to 'false' process will not exit after logging the 'uncaught exceptions'
- source - name of the logging source, by default name of the main node.js module
// use dynamic list of placeholders and parameters and any Object as Metadata
// message placeholders work the same way as in util.format()
logger.info ('Info Message')
// utilize tags (in the metadata object) as filter to be used in Logsene UI
logger.info ('Info Message', {tags: ['info', 'test']})
logger.info ("Info message no. %d logged to %s",1,'Logsene', {metadata: "test-log", count:1 , tags: ['test', 'info', 'winston']})
logger.error ("Error message no. %d logged to %s",1,'Logsene', {metadata: "test-error", count:1, tags: ['test', 'error', 'winston']})
logger.warn ("Warning message no. %d logged to %s",1,'Logsene', {metadata: "test-warning", count:1, tags: ['test', 'warning', 'winston']})
logger.debug ("Debug message no. %d logged to %s",1,'Logsene', {metadata: "test-debug", count:1})It is possible to log any JSON Object as meta data, but please note Logsene stores data in Elasticsearch and therefore you should define an index template, matching your data structure. More about Elasticsearch mapping and templates for Logsene: http://blog.sematext.com/2015/01/20/custom-elasticsearch-index-templates-in-logsene/
In addition you should use different types for different meta data structures to avoid type conflicts in Elasticsearch. Include a type name in the meta-data like {type: 'logType1', ...} - this overwrites the "type" property, specified in the contstructor.
logger.add (logsene, {token: process.env.LOGSENE_TOKEN, type: 'my_logs'})
// numeric id, log type from constructor
logger.info('hello', {id: 1})
// The next line will cause a type conflict in Elasticsearch/Logsene, because id was a number before
logger.info('hello', {id: 'ID-1'})
// using a different type, OK no type conflict for the field 'id' in Elasticsearch/Logsene
// because we use a different type in the Elasticsearch/Logsene index
logger.info('hello', {type: 'my_type_with_string_ids',{id: 'ID-1'})
- HTTPS is enabled by default
- Environment variables for Proxy servers:
- For HTTPS endpoints (default): HTTPS_PROXY / https_proxy
export HTTPS_PROXY=https://my-ssl-proxy.example
export HTTPS_PROXY=http://my-proxy.example
- For HTTP endpoints (e.g. On-Premises): HTTP_PROXY / http_proxy
export HTTP_PROXY=http://my-proxy.example
export HTTP_PROXY=https://my-ssl-proxy.example
Apache 2, see LICENSE file