Skip to content
Obsevo
Skip to docs navigation

Docs

Log field precedence

Which keys Obsevo reads for message, severity, timestamp and correlation — in order, first match wins.

OpenTelemetry semantic conventions are canonical; everything else is a documented alias. Keys are checked in the order below, first match wins, either as a flat key ("service.name") or as a nested path ({"service":{"name":…}}).

Anything not listed becomes a searchable attribute. Nothing is dropped.

Message
  1. message
  2. msg
  3. text
  4. textPayload
  5. body
  6. log
  7. event
  8. description

Then nested error.message / err.message / exception.message / jsonPayload.message.

Severity
  1. severityText
  2. severity_text
  3. severityNumber
  4. severity_number
  5. severity
  6. level
  7. levelname
  8. loglevel
  9. logLevel
  10. log_level
  11. log.level
  12. status
Timestamp
  1. timestamp
  2. timeUnixNano
  3. time_unix_nano
  4. observedTimeUnixNano
  5. time
  6. ts
  7. @timestamp
  8. date
  9. eventTime
  10. occurredAt
Source
  1. service.name
  2. service
  3. source
  4. serviceName
  5. service_name
  6. logger
  7. logger_name
  8. loggerName
Execution
  1. n8n.execution.id
  2. execution.id
  3. executionId
  4. execution_id

Correlates the line with an n8n run, and its nodes, in the explorer.

Workflow id
  1. n8n.workflow.id
  2. workflow.id
  3. n8nWorkflowId
  4. workflowId
  5. workflow_id
Workflow name
  1. n8n.workflow.name
  2. workflow.name
  3. workflowName
  4. workflow_name
  5. workflow
Dedupe token
  1. idempotencyKey
  2. idempotency_key
  3. event.id
  4. _id

Otherwise a content hash is used.

Three things worth knowing

Matching is case-sensitive. "Source" is not "source"; it stays an attribute. No schema in this space case-folds, and folding would read a business payload's {"Status":"shipped"} as a severity with no way to opt out. A finite published list is debuggable; a fuzzy match is not.

A lifted key is not repeated as an attribute — it became a column. Its siblings survive: service.version is kept when service.name is taken. The two sender-owned identifiers, _id and event.id, are an exception and stay in the payload after being used for deduplication, because someone will want to filter on them.

A bare id is not a dedupe token. Two lines about the same order would collide on it and the second would silently vanish. Send idempotencyKey if you want to control deduplication yourself.

Normalisation

Severity spellings are normalised generously — WARN:, [error], warning, critical, pino's 30, syslog's 3, OTel's severityNumber: 17 all land correctly. Storage uses six levels: fatal, error, warn, info, debug, trace.

Timestamps accept RFC 3339, or epoch seconds, milliseconds, microseconds or nanoseconds — told apart by magnitude.

env is never read from the payload. It comes from the instance the event key belongs to.

Attribute limits

LimitValue
Records per batch200
Attribute keys per record50
Attribute key length128
Attribute value length1024
Serialized data size8192 bytes

Two truncation markers can appear on a record: _truncated when the server's flattener hit a cap, and _clipped when the n8n node trimmed the payload before sending. They are rendered as notes rather than as payload keys.

Documentation