Skip to content

Easier migration to v7 and new naming of fields #36

@angularsen

Description

@angularsen

Upgrading to v7 causes problems for us with the new camelCase renaming of fields. This breaking change is mentioned on the README, but it was not trivial to find out exactly what changed and how to resolve it.

Since logz.io has case-sensitive indexes, this causes all sorts of problems with our logs, reports and alerts.

We were using the non-durable sink: WriteTo.LogzIo()

In my opinion, the default naming should not have changed in v7, to make the upgrade easier.
camelCase would be better as opt-in, since it is configurable.

Definitions

Internal fields: "level", "exception", "messageTemplate" + custom field prefix "properties."

What changed for us

  • All custom fields in log event were renamed to camelCase.
  • Internal fields changed from camelCase to PascalCase, even when specifying KeepAsIs.

Attempted workaround, does not work

We had to use the other overload of WriteTo.LogzIo(), which takes LogzioTextFormatterOptions and allows us to configure KeepAsIs naming.

We tried to override the internal field names back to camelCase, but it seems the internal fields are not affected by PropertyTransformationMap, so the below does NOT work:

            var textFormatterOptions = new LogzioTextFormatterOptions
            {
                BoostProperties = true,                                 // When true, does not add 'properties' prefix.
                FieldNaming = LogzIoTextFormatterFieldNaming.KeepAsIs,  // v7.x changed to CamelCase as default, preserve to match log indexes.
                IncludeMessageTemplate = true,                          // When true the message template is included in the logs, useful for filtering.
                LowercaseLevel = false,                                 // Set to true to push log level "Information" as lowercase "information".

                // THIS DOES NOT WORK, INTERNAL FIELDS LIKE "level" ARE NOT MAPPED.
                // Easier migration to v7 and new naming of fields · Issue #36 · serilog-contrib/Serilog.Sinks.Logz.Io
                // https://github.com/serilog-contrib/Serilog.Sinks.Logz.Io/issues/36
                PropertyTransformationMap = new Dictionary<string, string>
                {
                    { "SourceContext", "logger" },
                    { "ThreadId", "thread" },
                    { "Exception", "exception" },
                    { "MessageTemplate", "messageTemplate" },
                    { "Level", "level" },
                },
            };

            loggerConfig.WriteTo.LogzIo(logzIoToken,
                type: "app",
                new LogzioOptions
                {
                    DataCenter = new LogzioDataCenter { SubDomain = logzIoSubdomain },
                    TextFormatterOptions = textFormatterOptions,
                });

Proposal

Option 1 - Change the default naming back to v6

May require another major version bump since the cat already left the bag.

  1. Leave custom field naming as-is by default.
  2. Change internal fields back to camelCase

Option 2 - Make it easier to configure the v6 behavior

  1. Change FormattingOptions.ctor() to use camelCase names for internal fields and prefix if LogzIoTextFormatterFieldNaming? fieldNaming argument is KeepAsIs. Alternatively, make the field names explicitly configurable.
  2. Add section to REAMDE on how to configure v6 behavior
    a. The current documentation describes overriding the global static JSON serializer instance, but it seems better to configure the sink.
    b. Use the WriteTo.LogzIo overload that takes LogzioTextFormatterOptions in order to specify field naming KeepAsIs
    changed PropertiesPrefix though, but we boost properties to top level so not relevant for us.
    d. Describe exactly what fields changed naming in v7.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions