How does Seq map the GELF Log Levels from Seq.Input.Gelf plugin into CLEF Log Levels?

[apatenge]

Hello SEQ Team,

I am wondering where I can find information about the Mapping of the LogLevels between the Log Levels coming from the Seq.Input.Gelf Plugin into the CLEF Log Levels.

We are receiving logs from may different source, one is via GELF Protocol via Seq.Input.Gelf Plugin. The others via Serilog in CLEF Protocol. All Logs will be handled then by an own developed SEQ App Plugin. There we are receiving the Log Level as Enum in CLEF Standard.

I need now to make sure the correct log level is mapped, or the correct Log Level is sent via GELF to get the right out of SEQ finally.

I did some tests on this and found SEQ doing the following mapping. The plugin turns the numeric GELF Log Levels into strings. These will be mapped as the following by SEQ before handing over to the output plugin.

GELF → CLEF
debug (7) → Debug (1)
info (6) → Information (2)
notice (5) → Information ()
warning (4) → Warning (3)
err (3) → Error (4)
crit (2) → Fatal (5)
alert (1) → Information () → unexpected Mapping?!
emerg (0) → Fatal ()

According to the Log Level Enum/Numeric values I would expect to get "alert" mapped to "Fatal" since it means "Immediate action is required."

CLEF Verbose is not used at all, which is fine, since there is no corresponding value in GELF.

Where is that mapping specified, defined or documented that I can be sure that SEQ will always map these values according to this specification?

Many thanks already for your support.

Best Regards.
André

[KodrAus]

Hi @apatenge 👋

The source for the level mapping between CLEF and GELF lives here: https://github.com/datalust/seq-input-gelf/blob/dev/sqelf/src/process/mod.rs#L181-L189

That value is then converted into a Serilog level by seqcli here: https://github.com/datalust/seqcli/blob/8c0e0e21aeaf77d0e9597d6c3fa5efbca71471a5/src/SeqCli/Levels/LevelMapping.cs#L29-L77

There is indeed a gap there where we're not mapping the alert level.

[KodrAus]

I've opened datalust/seqcli#371 to track this.

[KodrAus]

@apatenge would it be possible to get a JSON export of that alert event as it appears in Seq? Re-reading your post it looks like the point you're seeing the level incorrectly mapped is in your input plugin, not in Seq itself.

[apatenge]

Many thanks for your fast answer.

Now I understand how the mapping is done and my results match completely with that implementation.
So it now clear why the “alert” (GELF) is mapped to “Information” (CLEF), it is simply not there and the fallback/default value is “Information” (CLEF).

Find here my test event as JSON export:
{"@t":"2016-06-07T04:10:00.3457981Z","@mt":"Hello, {User}","@m":"Hello, alert","@i":"8491ffee","@l":"alert","User":"alert"}

The level here is alert -> "@l":"alert"

We are using the input plugin "seq-input-gelf" (https://github.com/datalust/seq-input-gelf) from Datalust.
There the mapping of the numeric log level to the string log level is done. The numeric log level is according to GELF standard, which is the Syslog standard (https://en.wikipedia.org/wiki/Syslog#Severity_level).

We are feeding in events via UDP to the plugin "seq-input-gelf". This one turns the numeric values into these strings.

For us the more interesting part is how SEQ itself is doing the mapping at that point where it forwards the events with its log level to the output plugin. In the output plugin the log level appears as enumeration in CLEF standard. This is now explained.

If you have any question let me know.

Regards,
André

[nblumhardt]

Hi André,

If your output plug-in implements ISubscribeToJsonAsync instead of ISubscribeTo<..>, it can receive the raw event JSON, with "alert" level intact.

Let me know if this sounds like it would help.

Cheers,
Nick

[apatenge]

Hello Nick,

many thanks for that hint. This could be an option. I will definitely consider this :)

Best regards,
André