Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Status

Current state:   [One of "Under Discussion", "Accepted", "Rejected"]

Discussion thread: here [Change the link from the KIP proposal email archive to your own email thread]

JIRA: here [Change the link from KAFKA-1 to your own ticket]

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

...

  1. MDC is empty: The broker, controller, and all client libraries (producer, consumer, admin) do not set any MDC fields. Only Kafka Connect (via KIP-449) sets connector.context. This means JsonTemplateLayout MDC resolvers produce null for every field on every log line.

  2. Context is trapped in string prefixes: The LogContext class prepends a human-readable prefix like [BrokerServer id=0] or [Producer clientId=p1] to every log message. This context is useful for text logs but is not available as structured fields for log aggregation, filtering, or alerting.

  3. No standard field names: Even if operators manually called MDC.put() in their code, there is no agreed-upon naming convention for context fields across Kafka components. Each deployment would invent its own names.

  4. Cross-component correlation is impossible: There is no shared field (like kafka.node.id) that appears consistently across all log messages from a given broker, making it hard to filter logs by source in multi-tenant or multi-cluster environments.

Prior Art

KIPKafka VersionWhat it didRelationship to this KIP
KIP-6534.0Upgraded to Log4j 2.x; enabled JsonTemplateLayoutProvides the JSON output capability. This KIP populates the MDC fields that JSON output needs.
KIP-4492.3Added MDC context (connector.context) to Kafka ConnectProved the MDC pattern works in Kafka. This KIP extends the same approach to broker, controller, and clients.
KIP-6732.8Made request/response DEBUG traces emit proper JSONDifferent scope (request traces only). Complementary to this KIP.
KIP-7143.6Client metrics telemetry via OpenTelemetry ProtocolKIP-714 structures metrics; this KIP structures logs. Together they complete the Kafka observability story.
KIP-916Under DiscussionAdds flow.context MDC key for MirrorMaker 2Same MDC pattern, narrow scope (MM2 only). Complementary to this KIP.

Industry Context

Structured logging with pre-populated context fields is industry standard:

...

When JSON logging is enabled, the following MDC keys appear as top-level JSON fields. These key names become a stable public contract --- log consumers (dashboards, alerts, analysis tools) will depend on them.

MDC KeyTypeDescriptionPhase
kafka.node.idstringBroker or controller node ID1
kafka.componentstringComponent name (e.g., BrokerServer, UnifiedLog)1
kafka.client.idstringClient ID (producer, consumer, admin)1
kafka.client.typestringOne of: producer, consumer, admin1
kafka.group.idstringConsumer/share group ID1
kafka.group.instance.idstringStatic group membership instance ID1
kafka.transactional.idstringTransactional producer ID1
kafka.topicstringTopic name1
kafka.partitionstringPartition number1
kafka.cluster.idstringKafka cluster ID2 (reserved)
kafka.connectorstringKafka Connect connector name2 (reserved)
kafka.task.idstringKafka Connect task ID2 (reserved)

All keys use the kafka. prefix to avoid collision with user-defined MDC entries. Keys whose MDC value is null are omitted from the JSON output (not emitted as "kafka.topic": null).

...

The JSON template file defines the output schema for structured log events. Every JSON log line contains these fixed fields:

FieldSourceDescription
timestampLog4j2 eventISO-8601 timestamp in UTC
levelLog4j2 eventLog level name (INFO, WARN, ERROR, etc.)
loggerLog4j2 eventLogger name (fully qualified class name)
messageLog4j2 eventThe formatted log message (includes the LogContext prefix)
threadLog4j2 eventThread name
exceptionLog4j2 eventStack trace string (omitted when no exception)
kafka.*MDCAll standard MDC keys from the table above (omitted when null)

This template file is a configuration artifact, not compiled code. Users can customize it by providing their own template via the eventTemplateUri property in the Log4j2 YAML config.

...

4. New Runtime Dependency

ArtifactVersionScope
org.apache.logging.log4j:log4j-layout-template-jsonSame as log4j-core (currently 2.25.4)Runtime (only needed when JSON config is active)

This artifact is ~80KB with no transitive dependencies beyond log4j-core (already a Kafka dependency). It is added to the log4j2Libs and log4jReleaseLibs dependency groups. The minimum Log4j2 version required for JsonTemplateLayout is 2.14.0; Kafka currently ships 2.25.4.

...

A set of standard MDC key names is defined for consistent structured output:

MDC KeyDescriptionSet byPhase
kafka.node.idBroker or controller node IDBrokerServer, ControllerServer, SharedServer1
kafka.componentComponent nameEach component1
kafka.client.idClient IDKafkaProducer, KafkaConsumer, KafkaAdminClient1
kafka.client.typeproducer, consumer, or adminClient constructors1
kafka.group.idConsumer group IDKafkaConsumer, ShareConsumer1
kafka.group.instance.idStatic group membership IDKafkaConsumer1
kafka.transactional.idTransactional producer IDKafkaProducer1
kafka.topicTopic nameUnifiedLog1
kafka.partitionPartition numberUnifiedLog1
kafka.cluster.idKafka cluster ID(Phase 2)2
kafka.connectorConnect connector name(Phase 2)2
kafka.task.idConnect task ID(Phase 2)2

All key names use the kafka. prefix to avoid collision with user-defined MDC entries.

...

Three new Log4j2 configuration files are provided alongside the existing text configs:

FilePurposeReplaces
config/log4j2-json.yamlBroker/Controller JSON loggingconfig/log4j2.yaml
config/connect-log4j2-json.yamlConnect worker JSON loggingconfig/connect-log4j2.yaml
config/tools-log4j2-json.yamlCLI tools JSON loggingconfig/tools-log4j2.yaml

These configs use Log4j2's JsonTemplateLayout with a shared template file (config/log4j2-json-template.json) that defines the output schema.

...