sematext / winston-logsene

Winston Transport for Logsene
http://sematext.com/logsene
Apache License 2.0
13 stars 6 forks source link

tags don't appear to be received properly #26

Closed code-press closed 3 years ago

code-press commented 3 years ago

From your README, logger.info('Info Message', {tags: ['info', 'test']})

does not appear to be stored properly as a tag under the "TAGS" in the UX, did I miss something? (I also tried all caps TAGS for the key as well, no dice)

Screen Shot 2021-03-18 at 12 14 17 AM
adnanrahic commented 3 years ago

Hey! Thanks for opening this. The TAGS field is a reserved field. I'll have a look and see what's going on.

otisg commented 3 years ago

@code-press In Sematext "tags" are used in filters. And filters for logs are basically log event fields. So tags and fields are synonyms. You can ignore that "TAGS" you see in the UI, that's something else. If you want to tag log events simply make sure they have appropriate fields.

adnanrahic commented 3 years ago

Hi @code-press !

Here's a config I used that works as intended.

const { createLogger, format, transports, config } = require('winston')
const Logsene = require('winston-logsene')

const logger = createLogger({
  levels: config.npm.levels,
  format: format.simple(),
  transports: [
    new transports.Console(),
    new Logsene({
      token: 'b0a90520-xxxx-xxxx-xxxx-232a9fb9513f',
      level: 'debug',
      type: 'app_logs',
      url: 'https://logsene-receiver.sematext.com'
    })
  ]
})

logger.info('Info Message', { tags: ['info', 'test'] })

Can you please share more details about your setup? This will help me better understand what the issue might be.

matias-kovero commented 3 years ago

Hi @adnanrahic ! I'm currently having the same issue.

const { createLogger, format, config } = require('winston')
const Logsene = require('winston-logsene')
const logger = createLogger({
  levels: config.npm.levels,
  format: format.simple(),
  transports: [
    new Logsene({
      token: process.env.LOGS_TOKEN,
      level: 'debug',
      type: 'app_logs',
      url: 'https://logsene-receiver.sematext.com'
    }
  )]
});

logger.info('Checking status', { tags: ['info', 'status'] });

This will results on nasty:

tags[object Object]0 <- contains info
tags[object Object]1 <- contains status

and its really hard to create filters, as it creates variables for array positions, and not a variable that would contain all value in the array.

However, when using

var Logsene = require('logsene-js')
var logger =  new Logsene (process.env.LOGS_TOKEN)
logger.log ('info', 'Checking status', { tags: ['info','status'] })

it works as intended. Will results tags: info, status It creates an variable tags (keyword), and it has now all the values. Under tags I now find: info, status

Hopefully this helps to track down the issue?

adnanrahic commented 3 years ago

Hey @matias-kovero ! Thanks for letting me know about this. It's a strange issue. I'm trying to reproduce this issue right now. Let me get back to you on progress.

adnanrahic commented 3 years ago

It seems Winston updated the formatting methods with their latest release that causes this issue.

I'm looking into ways of fixing it with a custom format.

In the meantime, I tested this and it works as intended:

const { createLogger, format, config } = require('winston')
const Logsene = require('winston-logsene')
const logger = createLogger({
  levels: config.npm.levels,
  format: format.simple(),
  transports: [
    new Logsene({
      token: '84a777fd-xxxx-xxxx-xxxx-ffa6305c256f',
      level: 'debug',
      type: 'app_logs',
      url: 'https://logsene-receiver.sematext.com'
    }
  )]
});

logger.info('Checking status', { tags: 'info status' }) // <= string

By using a string instead of an array, you can get the desired format.

{
  "@timestamp": "2021-04-25T22:28:29.265Z",
  "severity": "info",
  "message": "Checking status",
  "tags": "info status",
  "level": "info",
  "@timestamp_received": "2021-04-25T22:28:30.026Z",
  "logsene_orig_type": "app_logs"
}
matias-kovero commented 3 years ago

Hi, thanks on a fast reply. Already tested it with an string with the values separated with space, but didn't get desired results. (more below) Also having issues with nested objects (may be user error, as I'm new using sematext)

logger.info('Checking status', { 
    tags: 'info status', 
    geo: { ip: req.headers[ip] } 
  });
{
  "@timestamp": "2021-04-26T08:58:43.752Z",
  "severity": "info",
  "message": "Checking status",
  "os": {
    "host": "xxx.xxx.xx.xx",
    "hostip": "xx.xx.xx.xx"
  },
  "tags": "info status",
  "geo[object Object]ip": "xx.xx.xx.xx",
  "level": "info",
  "@timestamp_received": "2021-04-26T08:58:43.933Z",
  "logsene_orig_type": "app_logs"
}

It seems it still supports somewhat nested objects as an os object is added that has working nested values. However, my nested object geo gets the same [object Object] issues mentioned earlier. (this is maybe caused by the Winston update)

Also the tags are coming through, but they are assigned as 1 parameter, and not as individual parameters. Sematext Common Schema on tags should create those parameters individually from spaced out values?

However tags will have an parameter: info status, and was hoping to have 2 parameters: info & status. When using the snippet from my earlier post with logsene-js it will create these 2 parameters from the array.

And for the nested object, I believe it might be caused by the issues with Winston update, however the reason why I'm trying to send a nested object is to follow the syntax of Common Schema to populate the ip field to get enriched geo data on it.

Side-note: The readme has an syntax issue on: logger.info('hello', {type: 'my_type_with_string_ids', {id: 'ID-1'}) <- missing an }

adnanrahic commented 3 years ago

Thanks for doing extensive testing! I'll look into this ASAP and figure out what's wrong with the object formatting.

adnanrahic commented 3 years ago

Hey @matias-kovero !

I pushed a fix for this issue. Feel free to try it out. Install the latest version or version 2.1.1 to get the patch. :smile:

Thanks again for your help regarding this issue.