Winston has unexpected output when using default meta

[Tim-Machine]

Example code

import winston from 'winston'
import ecsFormat  from '@elastic/ecs-winston-format'

const logger = winston.createLogger({
    level: 'info',
    format: ecsFormat(),
    defaultMeta: { service: "Service Name" },
    transports: [
        new winston.transports.Console()
    ],
  });

 logger.info('Unable to connect to ElasticSearch')

Output

{"@timestamp":"2021-02-11T01:45:57.337Z","log.level":"error","message":"Unable to connect to ElasticSearch","ecs":{"version":"1.6.0"},"service":{"0":"S","1":"e","2":"r","3":"v","4":"i","5":"c","6":"e","7":" ","8":"N","9":"a","10":"m","11":"e"}} 

Expected

{"@timestamp":"2021-02-11T01:45:57.337Z","log.level":"error","message":"Unable to connect to ElasticSearch","ecs":{"version":"1.6.0"},"service":{"Service Name"}} 

As you can see above when using defaultmeta the object value is serialized even if it is a string. Any quick fix I can put in place to solve this?

[trentm]

@Tim-Machine The issue here is that "service" is a name reserved in ECS to be an object at the top-level: https://www.elastic.co/guide/en/ecs/current/ecs-service.html

That combined with the schema-based usage of "fast-json-stringify" in these ecs-logging packages results in that broken rendering of your "service" field.

I don't have a plan for a general fix yet. I'm not sure what an ECS logger should best do when a user attempts to use a conflicting type for an ECS-specified field. Something I need to think about and discuss with others.

As a quick fix, the canonical ECS way to state the service name is via "service.name", so either of:

    defaultMeta: {
        service: {name: "Service Name"},

or

    defaultMeta: {
        "service.name": "Service Name",

would work. Does that suffice for you in the short term?

[Tim-Machine]

Let me test this out and I'll get back to you, good catch.

[Tim-Machine]

Just verified, this is working as suggested. Sorry for the false flag 😂