It seems that running an AWS Lambda (with the winston-logzio-node transport), causes the Lambda function to always be timed-out.

Was anyone able to make that work ?

Thanks!

CVE-2020-7598 - High Severity Vulnerability

Vulnerable Library - minimist-0.0.8.tgz

parse argument options

Library home page: https://registry.npmjs.org/minimist/-/minimist-0.0.8.tgz

Path to dependency file: /tmp/ws-scm/logzio-nodejs/package.json

Path to vulnerable library: /tmp/ws-scm/logzio-nodejs/node_modules/mocha/node_modules/minimist/package.json

Dependency Hierarchy:

• mocha-5.2.0.tgz (Root Library)
  • mkdirp-0.5.1.tgz
    • ❌ minimist-0.0.8.tgz (Vulnerable Library)

Found in HEAD commit: c8f318300c915c177b52af0bf40acb13741a5427

Vulnerability Details

minimist before 1.2.2 could be tricked into adding or modifying properties of Object.prototype using a "constructor" or "proto" payload.

Publish Date: 2020-03-11

URL: CVE-2020-7598

CVSS 3 Score Details (9.8)

Base Score Metrics:

• Exploitability Metrics:
  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: None
  • User Interaction: None
  • Scope: Unchanged
• Impact Metrics:
  • Confidentiality Impact: High
  • Integrity Impact: High
  • Availability Impact: High

For more information on CVSS3 Scores, click here.

Suggested Fix

Type: Upgrade version

Origin: https://github.com/substack/minimist/commit/63e7ed05aa4b1889ec2f3b196426db4500cbda94

Release Date: 2020-03-11

Fix Resolution: minimist - 0.2.1,1.2.2

requst v2.75.0 using old node-uuid package, so we have a warn during the instalation:
npm WARN deprecated [email protected]: Use uuid module instead

With request v2.81.0 (uuid module inside) all test are passed

When I tried to use in electron js I got this error:
"TypeError: this._addTimestamp is not a function:

Hi, I was trying to send log by using a statement like;
logger.log('Response: ', response);
However, it did not work. It would be nice if it can work like that or maybe a warning should be written in your docs. I know your docs say it expects string or an object.

However, as Javascript has a usage like console.log("statement", object); it feels natural to use such statements in logging.
Have a nice day.

have a method signature like console.log('message : ', object)

Hi,

The sendAndClose Method is not working any more.
When calling it the data is logged but the process doesn't end...
I had to revert back to my branch.
It seems that one of your recent changes broke this functionality.

--Barak

var jsonToString = exports.jsonToString = function(json) {
try {
return JSON.stringify(json);
}
catch(ex) {
return stringifySafe(msg, null, null, function() { }); <<<<<------ Exception
}
};

Hi,

would be awesome if you could provide @types for typescript.

When logging from my angular app, I get a 'no Access-control-allow-origin' message. (Even though the message is sent to my logzio account).

It would be nice if setting headers could be configured when creating the logger.

hi,

Is it a way to send a tag relative to a log?

Thanks

1. @timestamp_nano can't be used to compare timestamps of two different shippers, because hrtime(), used by @timestamp_nano, is relative to a process start time. So the order of log messages, sorted by @timestamp_nano, will be wrong when several shippers are involved.

2. When converting hrtime() timestamp to a @timestamp_nano string, the integers are not left-padded with zeroes, this leads to errors when comparing resulting strings alphabetically (e.g. 1234 will be less than 567 when compared alphabetically). This will cause sorting errors.

The version of axios currently used by logzio-nodejs, 0.27.2, is vulnerable to CVE 2023 45857. Snyk is flagging this as a high vulnerability: https://security.snyk.io/vuln/SNYK-JS-AXIOS-6032459

Axios has patched this in version 1.6.0 as of yesterday.

I'm running the latest version of the library and periodically get errors like this:

3|neo4j-ap | TypeError: Cannot read property 'code' of undefined
3|neo4j-ap |     at request.post.then.catch (/usr/src/app/node_modules/logzio-nodejs/lib/logzio-nodejs.js:287:45)
3|neo4j-ap |     at tryCatcher (/usr/src/app/node_modules/bluebird/js/release/util.js:16:23)
3|neo4j-ap |     at Promise._settlePromiseFromHandler (/usr/src/app/node_modules/bluebird/js/release/promise.js:512:31)
3|neo4j-ap |     at Promise._settlePromise (/usr/src/app/node_modules/bluebird/js/release/promise.js:569:18)
3|neo4j-ap |     at Promise._settlePromise0 (/usr/src/app/node_modules/bluebird/js/release/promise.js:614:10)
3|neo4j-ap |     at Promise._settlePromises (/usr/src/app/node_modules/bluebird/js/release/promise.js:690:18)
3|neo4j-ap |     at _drainQueueStep (/usr/src/app/node_modules/bluebird/js/release/async.js:138:12)
3|neo4j-ap |     at _drainQueue (/usr/src/app/node_modules/bluebird/js/release/async.js:131:9)
3|neo4j-ap |     at Async._drainQueues (/usr/src/app/node_modules/bluebird/js/release/async.js:147:5)
3|neo4j-ap |     at Immediate.Async.drainQueues (/usr/src/app/node_modules/bluebird/js/release/async.js:17:14)
3|neo4j-ap |     at Immediate.args.(anonymous function) (/usr/src/app/node_modules/event-loop-inspector/index.js:138:29)
3|neo4j-ap |     at runCallback (timers.js:810:20)
3|neo4j-ap |     at tryOnImmediate (timers.js:768:5)
3|neo4j-ap |     at processImmediate [as _immediateCallback] (timers.js:745:5)

It seems that it's not safe to assume the err var has a cause or code.

Package Version: 0.4.16

We've been working until recently with v0.4.2, since the last auto-update (we do that for patch version) in some scenarios (simples one is no token) the following error will be thrown.

'TypeError: Cannot read property \'log\' of undefined',
     '    at LogzioLogger._defaultCallback (/Users/matan/git/bookmd/client/node_modules/logzio-nodejs/lib/logzio-nodejs.js:102:28)',
     '    at Request._callback (/Users/matan/git/bookmd/client/node_modules/logzio-nodejs/lib/logzio-nodejs.js:315:21)',
     '    at Request.self.callback (/Users/matan/git/bookmd/client/node_modules/request/request.js:185:22)',
     '    at emitTwo (events.js:106:13)',
     '    at Request.emit (events.js:191:7)',
     '    at Request.<anonymous> (/Users/matan/git/bookmd/client/node_modules/request/request.js:1161:10)',
     '    at emitOne (events.js:96:13)',
     '    at Request.emit (events.js:188:7)',
     '    at IncomingMessage.<anonymous> (/Users/matan/git/bookmd/client/node_modules/request/request.js:1083:12)',
     '    at IncomingMessage.g (events.js:291:16)',
     '    at emitNone (events.js:91:20)',
     '    at IncomingMessage.emit (events.js:185:7)',
     '    at endReadableNT (_stream_readable.js:974:12)',
     '    at _combinedTickCallback (internal/process/next_tick.js:74:11)',
     '    at process._tickDomainCallback (internal/process/next_tick.js:122:9)'

Multiple places in the package perform the following action:
var callback = this.callback or this.callback = this._defaultCallback which causes the method to become unbound and when this.internalLogger.log('logzio-logger error: ' + err, err); is called an error is thrown.

This did not happen in the older version since it used console.log directly. The only usage of this in the older context was if (err && !this.supressErrors) so I assume the supressErrors check never had an effect (when called from unbound context).

$ npm test produces the following output:

> [email protected] test ........./winston-logzio
> mocha -w




  winston-logzio
    send string as log message
warn: Just a test message
      ✓ builds the log object properly


  1 passing (14ms)

and hangs indefinitely.
node v4.2.4, npm 2.14.12 on OSX 10.11.2

My gut feeling is that this has to do with winston transport socket left open and occupying the event loop, looking for more guidance here as I'm testing logzio implementation in my project.

The version of axios currently used by logzio-nodejs,1.6.0, is vulnerable to CWE-1321. Snyk is flagging this as a high vulnerability: https://security.snyk.io/vuln/SNYK-JS-AXIOS-6144788

Axios has patched this in version 1.6.4.

Opening this issue to track updating Axios to v1.6.4.

Currently I can sort by timestamp, however for events that are in the same millisecond, the sort order is usually wrong (reversed?). According to logz.io support, the way to fix this is to add an incrementing sequence number that can be used when defining the sort order in the kibana dashboard (presumably as the secondary sort attribute).

request module is considered deprecated and is accumulating up security vulnerabilities.
suggesting migration to Axios, which shouldn't be much effort.

https://www.npmjs.com/package/request

Is it possible to add support for port 5050 to allow UDP?
http://support.logz.io/support/solutions/articles/6000112383-how-do-i-ship-json-logs-to-loz-io-via-udp-

In api test using mocha, last step after tests have run is to shutdown the nodejs server with:

 after(function (done) {
      server.close(done);
 })

however, with any script that has require('logzio-nodejs'); this does not shutdown the server as presumably some resources eg; sockets must still be in use.

Currently I can sort by timestamp, however for events that are in the same millisecond, the sort order is usually wrong (reversed?). According to logz.io support, the way to fix this is to add an incrementing sequence number that can be used when defining the sort order in the kibana dashboard (presumably as the secondary sort attribute).

I am declaring the winston logger in this way:

const logzioWinstonTransport = new LogzioWinstonTransport({
  level: 'info',
  name: 'winston_logzio',
  token: '__YOUR_API_TOKEN__',
});

But it doesn't make what I put on the name variable, I am always receiving the type as nodejs:

Any idea how to configure this? It's important because in all the other services (using other loggers) this is working properly, and we use this field to filter out.

Thanks a lot!

PS: I first opened the issue here, but then I realized that the problem was in this repository.

The type of the log method is given as

    log(msg: string, obj?: object): void;

In the docs it is recommended to send an object as the first parameter, and this is supported in the Javascript code.

Note that the second parameter is stringified and appended to the first parameter, so does not appear to be useful for sending JSON.

Currently I can sort by timestamp, however for events that are in the same millisecond, the sort order is usually wrong (reversed?). According to logz.io support, the way to fix this is to add an incrementing sequence number that can be used when defining the sort order in the kibana dashboard (presumably as the secondary sort attribute).

WS-2019-0019 - Medium Severity Vulnerability

Vulnerable Library - braces-1.8.5.tgz

Fastest brace expansion for node.js, with the most complete support for the Bash 4.3 braces specification.

path: /tmp/git/logzio-nodejs/node_modules/braces/package.json

Library home page: https://registry.npmjs.org/braces/-/braces-1.8.5.tgz

Dependency Hierarchy:

• jest-23.6.0.tgz (Root Library)
  • jest-cli-23.6.0.tgz
    • micromatch-2.3.11.tgz
      • ❌ braces-1.8.5.tgz (Vulnerable Library)

Vulnerability Details

Version of braces prior to 2.3.1 are vulnerable to Regular Expression Denial of Service (ReDoS). Untrusted input may cause catastrophic backtracking while matching regular expressions. This can cause the application to be unresponsive leading to Denial of Service.

Publish Date: 2019-03-25

URL: WS-2019-0019

CVSS 2 Score Details (5.0)

Base Score Metrics not available

Suggested Fix

Type: Upgrade version

Origin: https://www.npmjs.com/advisories/786

Release Date: 2019-02-21

Fix Resolution: 2.3.1

Step up your Open Source Security Game with WhiteSource here

If you try to log a message containing objects then logz.io doesn't show these logs in Kibana.

How to reproduce it

var logger = require('logzio-nodejs').createLogger({
  token: 'process.env.LOGZ_IO_TOKEN',
  type: 'YourLogType',   
  debug: true
});

logger.log({message: 'string'}); // ok
logger.log({message: {a: 'object'}}); // LOST
logger.log({message: {a: 'object', b: {c: 2}}}); // LOST
logger.log({message: ['array']}); // ok
logger.log({message: ['number', 1]}); // ok
logger.log({message: ['number', 1, {a: 'object', b: {c: 2}}]}); // LOST
logger.log({message: "['the whole log is a string', 1, {a: 'object', b: {c: 2}}]"}); // ok

I verified that this lib actually sends the parsed objects. It seems like Logz.io servers can't parse the incoming requests. The lib logzio-nodejssends the requests usingrequest.post(options, function (err, res, body) {fromLogzioLogger.prototype._send. The options.body` contains all data:

{"message":"This is a log message","type":"YourLogType","@timestamp":"2018-03-21T12:19:15.440Z"}
{"message":"string","type":"YourLogType","@timestamp":"2018-03-21T12:19:15.440Z"}
{"message":{"a":"object"},"type":"YourLogType","@timestamp":"2018-03-21T12:19:15.440Z"}
{"message":{"a":"object","b":{"c":2}},"type":"YourLogType","@timestamp":"2018-03-21T12:19:15.440Z"}
{"message":["array"],"type":"YourLogType","@timestamp":"2018-03-21T12:19:15.440Z"}
{"message":["number",1],"type":"YourLogType","@timestamp":"2018-03-21T12:19:15.440Z"}
{"message":["number",1,{"a":"object","b":{"c":2}}],"type":"YourLogType","@timestamp":"2018-03-21T12:19:15.440Z"}
{"message":"['the whole log is a string', 1, {a: 'object', b: {c: 2}}]","type":"YourLogType","@timestamp":"2018-03-21T12:27:21.962Z"}

Actual result

This is a screen shot from kibana. All logs containing objects are not logged.

Expected result

Kibana should display also the logs for objects from the code snippet:

• logger.log({message: {a: 'object'}}); // LOST
• logger.log({message: {a: 'object', b: {c: 2}}}); // LOST
• logger.log({message: ['number', 1, {a: 'object', b: {c: 2}}]}); // LOST

For those users who are behind firewall it will be useful to get an ability to send logs messages on common http ports, like 80 for plain HTTP and 443 for HTTPS. Seems that listener.logz.io ready to accept bulk logs via HTTPS on port 443.

Lets say it will port option of createLogger method, what you think about?

You are using request package which itself uses HTTP_RPOXY environment variable to configure HTTP proxy to use. In the particular case of proxies, this is bad – I don't want logs to flood our internal proxies.

Add an option to explicitly disable use of any proxy for the logging transport.

The sendAndClose type is given as

    sendAndClose(callback: (error: Error, bulk: object) => void): void;

The callback parameter should be optional.

WS-2019-0032 - Medium Severity Vulnerability

Vulnerable Library - js-yaml-3.12.0.tgz

YAML 1.2 parser and serializer

path: /tmp/git/logzio-nodejs/node_modules/js-yaml/package.json

Library home page: https://registry.npmjs.org/js-yaml/-/js-yaml-3.12.0.tgz

Dependency Hierarchy:

• eslint-5.9.0.tgz (Root Library)
  • ❌ js-yaml-3.12.0.tgz (Vulnerable Library)

Vulnerability Details

Versions js-yaml prior to 3.13.0 are vulnerable to Denial of Service. By parsing a carefully-crafted YAML file, the node process stalls and may exhaust system resources leading to a Denial of Service.

Publish Date: 2019-03-26

URL: WS-2019-0032

CVSS 2 Score Details (5.0)

Base Score Metrics not available

Suggested Fix

Type: Upgrade version

Origin: https://www.npmjs.com/advisories/788/versions

Release Date: 2019-03-26

Fix Resolution: 3.13.0

Step up your Open Source Security Game with WhiteSource here

We are extensively using winston in our application code. I suspect a lot of people are.

Is there a winston-transport wrapper for Logz.io? Any plans to make one in the near future?

We are using Bunyan - do you have a transporter for Bunyan as well? (Did see the one regarding Winston..)

From reading the winston-logzio, there is an object part that I didn't found on here

const logObject = Object.assign({},
      info,
      msg, {
        level: info[LEVEL] || this.level,
        name: this.name,
      });

    this.logzioLogger.log(logObject);
    callback(null, true);
  }

Describe the bug
When running logzio in an AWS lambda I did the logger.close() at the end of the execution as I was instructed.

However, if you close the logger and the lambda gets reused, the logger is closed and won't ship any more logs and will error with Attempt to write logs with no transports, which can increase memory usage

To Reproduce
Steps to reproduce the behavior:

1. Run a lambda and initialize the logger
2. Run close() at the end of the execution as instructed per docs
3. Next warm execution of the lambda will fail logging

Expected behavior
Replace close with a flush that will instruct flushing the current batch of logs

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Within the Travis build we still test against version 8, I believe we should stop active support and switch to the following support pattern:

• Current LTS (currently that is both v14 & v12)
• Long term maintenance version (v10)

We could consider the latest build (v16) as a future-proofing step to forewarn of possible breaking changes in the core node APIs, but probably shouldn't be a breaking test.