其它的log日志都有Field操作,klog没有封装，导致用起来很不方便，还要使用底层的比如logrus.Field

[systemview2018]

Describe the bug

A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior

A clear and concise description of what you expected to happen.

Screenshots

If applicable, add screenshots to help explain your problem.

Kitex version:

Please provide the version of Kitex you are using.

Environment:

The output of go env.

Additional context

Add any other context about the problem here.

[li-jin-gou]

你这种场景直接用 logrus 就可以，klog 主要是为了打印框架日志，简单场景，你保证框架打印日志也能收集到即可。

[systemview2018]

我是从java转过来。目前在设计一个微服务整体结构。
日志这边的考虑：

1. 从一个微服务的整体结构设计来看，肯定是希望一套日志架构从开始一直应用到底层，这样输出的日志都是统一的标准。
2. 作为编码的人，也是希望日志在写的时候，也只会用一个入口。
3. OTEL也是这样的方式
   既然klog可以作为这样的入口，那么希望klog可以丰富一下功能，类似java SLF4j这的facade能力。 要不然我还是要重新写一套日志标准重头替换klog，包括klog对otel的封装。 这样的话，kitex作为微服务的提供方我感觉失去在日志方面的作用了。

[li-jin-gou]

cc @rogerogers

[li-jin-gou]

我是从java转过来。目前在设计一个微服务整体结构。 日志这边的考虑：

1. 从一个微服务的整体结构设计来看，肯定是希望一套日志架构从开始一直应用到底层，这样输出的日志都是统一的标准。
2. 作为编码的人，也是希望日志在写的时候，也只会用一个入口。
3. OTEL也是这样的方式
   既然klog可以作为这样的入口，那么希望klog可以丰富一下功能，类似java SLF4j这的facade能力。 要不然我还是要重新写一套日志标准重头替换klog，包括klog对otel的封装。 这样的话，kitex作为微服务的提供方我感觉失去在日志方面的作用了。

目前 klog 的接口设计很简单，不能满足用户的需求，之前一直的解决方案都是复杂需求直接使用日志库，而不是框架的包装库,如果想满足需求的话现在看势必会有 break changg ，对用户和维护者造成一定的迁移用法压力。长期我们打算重构掉&统一 klog 和 hlog（hertz 的实现)，短期的话我们看下具体场景有没有方案可以快速解决你的问题 @systemview2018 。

[rogerogers]

1. klog 是框架自身使用的日志打印组件，同时基于标准库的 log 提供一个基础的日志库实现，对于没有复杂打印逻辑的用户可以很方便地使用。
2. 同时 klog 提供了接口，可以方便的配置具体的日志库实现，我们也提供了几种常见日志库的实现，这个主要是统一业务和框架的的日志，方便日志收集等情况
3. golang 没有类似 java slf4j 这种高流行度的通用接口，日志库选型一般也是在 zap 、logrus 、zerolog 、slog 等日志组件中做选择，opentelemetry 项目后续也会对日志有一些规划 https://github.com/open-telemetry/opentelemetry-go/issues/4696
4. 其他的常见组件的比如 orm 等等也是通过配置具体的日志实现来实现日志的格式统一。
5. 业务日志有自定义需求的话，直接使用具体日志库即可

[welkeyever]

我是从java转过来。目前在设计一个微服务整体结构。 日志这边的考虑：

1. 从一个微服务的整体结构设计来看，肯定是希望一套日志架构从开始一直应用到底层，这样输出的日志都是统一的标准。
2. 作为编码的人，也是希望日志在写的时候，也只会用一个入口。
3. OTEL也是这样的方式
   既然klog可以作为这样的入口，那么希望klog可以丰富一下功能，类似java SLF4j这的facade能力。 要不然我还是要重新写一套日志标准重头替换klog，包括klog对otel的封装。 这样的话，kitex作为微服务的提供方我感觉失去在日志方面的作用了。

@systemview2018 “java SLF4j这的facade能力” 是指的占位符参数日志吗？这个目前的接口定义应该是有的 & 所有的实现库都支持，Golang 里是通过 format 的方式引入的这类能力，类似 Errorf(format string, v ...interface{}) 这种接口；如果可以的可以详细展开看看目前的日志抽象有哪些地方不能够满足当前的需求🫡

[systemview2018]

我是从java转过来。目前在设计一个微服务整体结构。 日志这边的考虑：

1. 从一个微服务的整体结构设计来看，肯定是希望一套日志架构从开始一直应用到底层，这样输出的日志都是统一的标准。
2. 作为编码的人，也是希望日志在写的时候，也只会用一个入口。
3. OTEL也是这样的方式
   既然klog可以作为这样的入口，那么希望klog可以丰富一下功能，类似java SLF4j这的facade能力。 要不然我还是要重新写一套日志标准重头替换klog，包括klog对otel的封装。 这样的话，kitex作为微服务的提供方我感觉失去在日志方面的作用了。

@systemview2018 “java SLF4j这的facade能力” 是指的占位符参数日志吗？这个目前的接口定义应该是有的 & 所有的实现库都支持，Golang 里是通过 format 的方式引入的这类能力，类似 Errorf(format string, v ...interface{}) 这种接口；如果可以的可以详细展开看看目前的日志抽象有哪些地方不能够满足当前的需求🫡

其实就是一个统一对外接口，只是这个接口包含的比较全面。 底层是可以其它的框架实现。https://blog.csdn.net/trh_csdn/article/details/127098291

[systemview2018]

1. klog 是框架自身使用的日志打印组件，同时基于标准库的 log 提供一个基础的日志库实现，对于没有复杂打印逻辑的用户可以很方便地使用。
2. 同时 klog 提供了接口，可以方便的配置具体的日志库实现，我们也提供了几种常见日志库的实现，这个主要是统一业务和框架的的日志，方便日志收集等情况
3. golang 没有类似 java slf4j 这种高流行度的通用接口，日志库选型一般也是在 zap 、logrus 、zerolog 、slog 等日志组件中做选择，opentelemetry 项目后续也会对日志有一些规划 https://github.com/open-telemetry/opentelemetry-go/issues/4696
4. 其他的常见组件的比如 orm 等等也是通过配置具体的日志实现来实现日志的格式统一。
5. 业务日志有自定义需求的话，直接使用具体日志库即可

其实引出这个问题也是想看看klog是不是有这个打算做一个通用的facade库，包含各个方面的。 确实可以直接使用具体的库，但是这个不是我的本意。
我的一个思路是业务层的代码不给开发同学太多的选择，这样减少犯错误的概率。

[welkeyever]

嗯嗯，看起来是对的上的，目前这套接口其实就是一个类似 facade 的作用，你可以看看上面提到的 formatLogger 的定义，这个也是 klog 的接口的一部分，看看是否除了 format(占位符)以外还有别的无法满足的诉求哈

[CoderPoet]

我是从java转过来。目前在设计一个微服务整体结构。 日志这边的考虑：

1. 从一个微服务的整体结构设计来看，肯定是希望一套日志架构从开始一直应用到底层，这样输出的日志都是统一的标准。
2. 作为编码的人，也是希望日志在写的时候，也只会用一个入口。
3. OTEL也是这样的方式
   既然klog可以作为这样的入口，那么希望klog可以丰富一下功能，类似java SLF4j这的facade能力。 要不然我还是要重新写一套日志标准重头替换klog，包括klog对otel的封装。 这样的话，kitex作为微服务的提供方我感觉失去在日志方面的作用了。

@systemview2018 otel 这块的集成目前确实也存在一些 hertz & kitex 的 overlap，可观测相关生态缺少一个统一集成，这块我们正在开始努力解决哈：#1247