前几天在提交一个MR的Code Review时，遇到了一个关于日志级别的有趣讨论。我的原始代码是一个获取标签列表的方法，实现如下：
public async Task<TagInfo[]> GetTagListAsync()
{
try
{
return await _apiClient.GetTagListAsync();
}
catch (Exception ex)
{
Logging.Error(ex.Message, ex);
}
}
Reviewer提了一个令我没想到的问题：“为什么要在这里使用Error级别的日志？”
问题探讨
我最初的反应是：“捕获了异常，难道不应该用Error级别吗？“我们就日志级别适用场景 「讨论」了约5分钟。
Reviewer的观点：
- 谁会去看这个日志？
- 这个接口异常是否会阻塞主流程继续执行？
- 如果真的出现了异常，我们如何主动监控这类异常？
他随后分享了一个Stack Overflow上关于日志级别的讨论：When to use the different log levels
解决方案
经过讨论，我被说服了，在这种情况下使用Warning级别更为合适。修改后的代码如下：
public async Task<TagInfo[]> GetTagListAsync()
{
try
{
return await _apiClient.GetTagListAsync();
}
catch (Exception ex)
{
// remoteLog参数会将日志上传到ELK，便于后续通过关键字进行分析
Logging.Warn($"Failed to get tag list, msg:{ex.Message}", ex, remoteLog: true);
}
}
日志级别的最佳实践
Stack Overflow上的高票回答提供了一个清晰的日志级别使用指南图表，非常值得参考。
- Error：用于确实影响程序正常执行的严重错误
- Warning：适用于非关键路径上的异常或可恢复的错误
- Info：记录程序正常运行的重要信息
- Debug：开发调试期间的详细信息
- Trace：最详细的日志信息，通常用于问题诊断
在这个案例中，获取标签列表失败不会影响核心业务流程，因此使用Warning级别更为恰当。这种区分有助于运维人员快速定位真正严重的问题，避免在大量Error日志中遗漏关键错误。
下面这个图是高赞回答的博主贴的，很清晰的说明了何时使用什么级别的日志。
The remaining content of your post.