feat(log)!: intoduce log v2 with OpenTelemetry and slog by technicallyty · Pull Request #25701 · cosmos/cosmos-sdk

technicallyty · 2025-12-16T02:48:51Z

Description

Closes: SDK-430

refactors the log package to add support for OpenTelemetry trace correlation. notable changes:

extended logging interface to add context methods - allows trace correlation.
logging constructor function signature changed
logging options all changed to be more standard i.e. log.With<Option> rather than log.SomeOption
if no opentelemetry configuration is set, we simply use zerolog as we did before.
if an OpenTelemetry configuration is set, we use slog, and all logs are output to console and forwarded to the configured logger provider (otel.yml).
New flag introduced, --log_no_console, to allow logs to ONLY go to otel, not to console. (performance related)
reduced log levels to align with slog. some zerolog levels won't be supported now

…ng-metrics

aljo242 · 2026-01-06T21:57:01Z

log/CHANGELOG.md


 ## [Unreleased]

+* [#25701](https://github.com/cosmos/cosmos-sdk/pull/25701) Introduce log v2, enabling OpenTelemetry logging with slog. The logging interface has been updated to accommodate Context logging methods, which allows correlation of logs with traces.


can we link to the upgrade guide for this?

aljo242 · 2026-01-06T22:01:38Z

log/logger.go

-		opt(&logCfg)
+// newZerologLogger creates a Logger backed by zerolog directly.
+// This is the fast path with zero allocations.
+func newZerologLogger(dst io.Writer, cfg *Config) Logger {


previously we filled out the default config and overrode it. Why are we making this change and should cfg be nullable (a pointer)?

we still do that, it's just pulled up to the top level NewLogger now. ill remove the pointers

aljo242 · 2026-01-06T22:02:44Z

log/level_test.go

 	}
 }

-func TestVerboseMode(t *testing.T) {


did we remove this test accidentally?

yes, adding back in

aljo242 · 2026-01-06T22:04:26Z

log/logger.go

-// Impl returns the underlying zerolog logger.
-// It can be used to use zerolog structured API directly instead of the wrapper.
-func (l zeroLogWrapper) Impl() interface{} {
+func (l *zeroLogWrapper) Impl() interface{} {


should return the concrete type here

this would break the interface

aljo242 · 2026-01-06T22:08:43Z

log/options.go

+	// nil = check LoggerProvider.
+	// true = force enable
+	// false = force disable
+	EnableOTEL *bool


why pointer

i wanted to have presence checking here. if set at all, we know that this was explicitly set with the WithOTEL or WIthoutOTEL options. if unset, we can make a decision based on if they had a provider set in their otel configuration.

on second thought though, perhaps we just enable it if they have otel set at all. not actually sure its useful to have this expression here.

should be a bool → false by default. no need for a pointer

see above comment

aljo242 · 2026-01-06T22:10:33Z

log/with_test.go

-// this test ensures that when the With and WithContext methods are called,
-// that the log wrapper is properly copied with all of its associated options
-// otherwise, verbose mode will fail
-func TestLoggerWith(t *testing.T) {


seems like this test would be fine to still include?

added back, but removed the wrapper3 case because the return type changed, making that test case invalid.

aljo242 · 2026-01-06T22:11:56Z

server/cmd/execute.go

 	ctx := CreateExecuteContext(context.Background())

-	rootCmd.PersistentFlags().String(flags.FlagLogLevel, zerolog.InfoLevel.String(), "The logging level (trace|debug|info|warn|error|fatal|panic|disabled or '*:<level>,<key>:<level>')")
+	rootCmd.PersistentFlags().String(flags.FlagLogLevel, "info", "The logging level (debug|info|warn|error|disabled or '*:<level>,<key>:<level>')")


can we not use the library values from slog etc or something?

yeah added slog.InfoLevel.String() here instead of "info"

aljo242 · 2026-01-06T22:13:16Z

server/util.go

 		viper.New(),
 		cmtcfg.DefaultConfig(),
-		log.NewLogger(os.Stdout),
+		log.NewLogger("cosmos-sdk", log.WithConsoleWriter(os.Stdout)),


should we define a constant for this name? or a default somehow?

added it to a const block

aljo242 · 2026-01-06T22:15:15Z

simapp/app_di.go

@@ -1,373 +0,0 @@
-//go:build !app_v1


why did this need to be removed (not opposed)

oops. meant to add back after testing.

swift1337

Great to see OTEL in logging, left some comments related to the design

swift1337 · 2026-01-07T12:02:15Z

client/flags/flags.go

 	FlagVerboseLogLevel = "verbose_log_level"
 	FlagLogFormat       = "log_format"
 	FlagLogNoColor      = "log_no_color"
+	FlagLogNoConsole    = "log_no_console"


I think this refactoring is a good opportunity to fix flags' naming:

--log-level

--log-level-verbose (what's that?)

--log-format

--log-no-color

--log-disable-stdout → is a more suitable name IMO

trying to reduce API breakage here, leaning towards keeping the flags the same

as for --log-disable-stdout, kinda lean against that as well. we can log to stderr as well, and using a flag with that name could imply stderr logs will display, when the flag currently disables all console output entirely.

I think it's fine to break a couple of flags since this PR already introduces breaking changes. Especially, since current log flags have this weird -- + _ casing.

we can log to stderr as well

good call, maybe then --log-disable-console ?

swift1337 · 2026-01-07T12:07:49Z

log/logger.go


+	// InfoContext takes a context, message and key/value pairs and logs with level INFO.
+	// The context is used for trace/span correlation when using OpenTelemetry.
+	InfoContext(ctx context.Context, msg string, keyVals ...any)


I find this API a bit too excessive. All of this can be expressed with:

// Logger is the Cosmos SDK logger interface. type Logger interface { // Info takes a message and a set of key/value pairs and logs with level INFO. // The key of the tuple must be a string. Info(msg string, keyVals ...any) // Warn takes a message and a set of key/value pairs and logs with level WARN. // The key of the tuple must be a string. Warn(msg string, keyVals ...any) // Error takes a message and a set of key/value pairs and logs with level ERR. // The key of the tuple must be a string. Error(msg string, keyVals ...any) // Debug takes a message and a set of key/value pairs and logs with level DEBUG. // The key of the tuple must be a string. Debug(msg string, keyVals ...any) // Ctx returns logger with context attached. Usable for propagating OTEL traces. Ctx(ctx context.Context) Logger // With returns a new wrapped logger with additional context provided by a set. With(keyVals ...any) Logger // Impl returns the underlying logger implementation. // It is used to access the full functionalities of the underlying logger. // Advanced users can type cast the returned value to the actual logger. Impl() any }

Example:

app.logger.InfoContext(ctx, "InitChain", "initialHeight", req.InitialHeight, "chainID", req.ChainId)

becomes →

app.logger.Ctx(ctx).Info("InitChain", "initialHeight", req.InitialHeight, "chainID", req.ChainId)

this also allows to keep most of the code that doesn't need OTEL. Another benefit is that now we can reuse ctx logger in larger functions:

func (k Keeper) LargeMigration(...) error { ctx, span := tracer.Start(...) logger := app.logger.Ctx(ctx) // 20 LoC ... logger.Info("abc", "k", "v") // another 50 LoC logger.Info("xyz", "k2", "v2") }

logger.Ctx() can be a noop for zerolog. for slog we can have:

type slogLogger struct { + ctx context.Context log *slog.Logger }

and call Info() / InfoContext() based on ctx == nil

I think the rationale for all the InfoContext, etc. functions is basically to match the slog API. But your Ctx method approach also makes sense.

yeah this is much better - updated here remove contextual methods, add context attachment

swift1337 · 2026-01-07T12:24:46Z

log/options.go

+	// nil = check LoggerProvider.
+	// true = force enable
+	// false = force disable
+	EnableOTEL *bool


should be a bool → false by default. no need for a pointer

swift1337 · 2026-01-07T12:33:03Z

log/README.md

+The `cosmossdk.io/log` package provides a structured logging implementation for the Cosmos SDK using [zerolog](https://github.com/rs/zerolog) with optional OpenTelemetry integration.

-To use a logger wrapping an instance of the standard library's `log/slog` package, use `cosmossdk.io/log/slog`.
+## Features


I think we miss two more features:

Ability to set and get a logger from ctx (zerolog example: ctx = zerolog.WithContext(ctx), zerolog.Ctx(ctx))

Ability to retrieve a global logger for fallback ie use log.Info(...) (where log is the package name)

This would result in a "feature parity" with other logging libs

the global thing is interesting, i think id prefer to kick that can down the road though. esp since logging conventions in SDK are already pretty solidified imo. could be wrong though

Agree, it's not urgent + easy to implement.

I responded in the issue. Basically, I think this proposed context approach follow zerolog conventions but is quite different than the otel approach. If we're adopting otel more generally, I'd prefer we lean towards otel conventions.

swift1337 · 2026-01-08T13:28:18Z

log/logger.go

+	ctx context.Context
+}
+
+func (l slogLogger) Ctx(ctx context.Context) Logger {


Let's explicitly create a new struct

Suggested change

func (l slogLogger) Ctx(ctx context.Context) Logger {

func (l *slogLogger) Ctx(ctx context.Context) Logger {

return &slogLogger{log: l.log, ctx: ctx}

}

swift1337 · 2026-01-08T13:29:01Z

log/logger.go

+	return slogLogger{log: log}
+}
+
+func (l slogLogger) Info(msg string, keyVals ...any) {


Let's skip slogLogger allocation for each call

Suggested change

func (l slogLogger) Info(msg string, keyVals ...any) {

func (l *slogLogger) Info(msg string, keyVals ...any) {

swift1337 · 2026-01-08T13:35:38Z

log/logger.go

+//
+//	// OTEL-only (no console output)
+//	logger := log.NewLogger("cosmos-sdk", log.WithOTEL(), log.WithoutConsole())
+func NewLogger(name string, opts ...Option) Logger {


What do you think of a simpler and more idiomatic naming?

Suggested change

func NewLogger(name string, opts ...Option) Logger {

func New(name string, opts ...Option) Logger {

aaronc · 2026-01-08T19:57:47Z

log/logger.go

+
+// slogLogger satisfies Logger with logging backed by an instance of *slog.Logger.
+type slogLogger struct {
+	log *slog.Logger


This isn't quite right. We can't wrap a *slog.Logger because then file and line information will be all wrong. We can only wrap a *slog.Handler but then we need to basically reimplement the logger functionality of checking enabled and capturing the program counter

aaronc added 30 commits October 29, 2025 15:44

feat: add tracing

1cf5e6c

work on otel tracer impl

a207f94

add basic baseapp tracing

ee0bfb3

latest WIP

d5f5ea4

add trace exporter setup

47f83e8

fixes

7fafce3

simapp setup, make tracers wrap loggers

bdba035

add test setup

25e3135

fix shutdown order

5c7e464

block trace nesting

d71f7c1

update metrics config and instrumentation

56b215a

start adding otel metric config

f9ce55c

migrate to pure otel setup

3fff00f

fixes

5077567

add basic metrics

31536b6

add telemetry shutdown hook

c922688

docs, cleanup

ed891cc

WIP on removing go-metrics

f685bd4

Merge branch 'main' of github.com:cosmos/cosmos-sdk into aaronc/traci…

42da2f7

…ng-metrics

setup sim test flag

699f5d3

integrate slog logging

5df2460

update to use official env var

1c84edb

add README.md

46e4bcb

delete spaces

f0c3955

setup TestingMain

7dfb754

update suggested config in README.md

1ce344b

add otel custom config options

edbae92

add otel custom config options

0f8085a

add more instrumentation

03b6069

remove pretty print

c4dbd07

technicallyty added 3 commits January 6, 2026 11:04

lint fix

a6b7d96

fix lint

189b46e

fix lint again...

fcb9067

github-actions bot removed the C:Store label Jan 6, 2026

technicallyty added 5 commits January 6, 2026 11:29

fix options docs

3f39296

update readme

b878d77

update readme

86190db

update upgrading

f14fdca

add comment why we cant use zerolog bridge

c8daf44

technicallyty marked this pull request as ready for review January 6, 2026 19:46

technicallyty requested review from aaronc and aljo242 January 6, 2026 19:51

swift1337 self-requested a review January 6, 2026 19:56

aljo242 reviewed Jan 6, 2026

View reviewed changes

technicallyty added 9 commits January 6, 2026 15:35

reference upgrading in changelog

486d4e8

remove pointers for config

0530ec2

re-add missing test

e33d030

add with_test

e36b09e

use slog info name

b51b61f

const default logger name

79707fd

re-add app_di

f10baa3

re-add flag on app.go

32b68f9

fix import order

0aff0fd

swift1337 reviewed Jan 7, 2026

View reviewed changes

technicallyty added 2 commits January 7, 2026 14:13

remove contextual methods, add context attachment

a39c985

fix mocks

f0083d7

swift1337 mentioned this pull request Jan 8, 2026

logging: add support for ctx and global logger #25755

Open

swift1337 reviewed Jan 8, 2026

View reviewed changes

aaronc reviewed Jan 8, 2026

View reviewed changes

technicallyty closed this Jan 15, 2026


		## [Unreleased]

		* [#25701](https://github.com/cosmos/cosmos-sdk/pull/25701) Introduce log v2, enabling OpenTelemetry logging with slog. The logging interface has been updated to accommodate Context logging methods, which allows correlation of logs with traces.

-func (l slogLogger) Ctx(ctx context.Context) Logger {
+func (l *slogLogger) Ctx(ctx context.Context) Logger {
+  return &slogLogger{log: l.log, ctx: ctx}
+}

	func (l slogLogger) Info(msg string, keyVals ...any) {
	func (l *slogLogger) Info(msg string, keyVals ...any) {

	func NewLogger(name string, opts ...Option) Logger {
	func New(name string, opts ...Option) Logger {

Conversation

technicallyty commented Dec 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

swift1337 left a comment

Choose a reason for hiding this comment

Uh oh!

swift1337 Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

technicallyty Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

technicallyty Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

swift1337 Jan 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

technicallyty commented Dec 16, 2025 •

edited

Loading

swift1337 Jan 7, 2026 •

edited

Loading

technicallyty Jan 7, 2026 •

edited

Loading

technicallyty Jan 7, 2026 •

edited

Loading

swift1337 Jan 8, 2026 •

edited

Loading