Component
Zap bridge
Problem Statement
otelzap currently treats zap errors like ordinary structured fields. When applications log with zap.Error, zap.NamedError, or equivalent error-carrying fields, the bridge forwards that data under generic attribute names such as error or the caller-provided key.
That makes exception data inconsistent with the OpenTelemetry log semantic conventions and harder to recognize as exception information once it leaves the process.
Proposed Solution
Make it follow the OpenTelemetry semantic conventions for exceptions in logs are here: Semantic conventions for exceptions in logs.
Alternatives
No response
Prior Art
No response
Additional Context
No response
Component
Zap bridge
Problem Statement
otelzapcurrently treats zap errors like ordinary structured fields. When applications log withzap.Error,zap.NamedError, or equivalent error-carrying fields, the bridge forwards that data under generic attribute names such aserroror the caller-provided key.That makes exception data inconsistent with the OpenTelemetry log semantic conventions and harder to recognize as exception information once it leaves the process.
Proposed Solution
Make it follow the OpenTelemetry semantic conventions for exceptions in logs are here: Semantic conventions for exceptions in logs.
Alternatives
No response
Prior Art
No response
Additional Context
No response