mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-23 21:20:42 +08:00
PRF&PUB:20170308 Our guide to a Golang logs world.md
@ictlyh
This commit is contained in:
wxy
parent
fc3fef84d2
commit
753dd5fc51
@ -1,17 +1,17 @@
|
||||
Go 日志指南
|
||||
Go 语言日志指南
|
||||
============================================================
|
||||
|
||||
|
||||
|
||||
|
||||
你是否厌烦了那些使用复杂语言编写、难以部署、总是在构建的解决方案？Golang 是解决这些问题的好方法，它和 C 语言一样快，又和 Python 一样简单。
|
||||
你是否厌烦了那些使用复杂语言编写的、难以部署的、总是在不停构建的解决方案？Golang 是解决这些问题的好方法，它和 C 语言一样快，又和 Python 一样简单。
|
||||
|
||||
但是你如何使用 Golang 日志监控你的应用程序呢？Golang 没有异常，只有错误。因此你的第一印象可能就是开发 Golang 日志策略并不是一件简单的事情。不支持异常事实上并不是什么问题，异常在很多编程语言中已经失去了特殊用处：它们过于被滥用以至于它们的作用都被忽视了。
|
||||
但是你是如何使用 Golang 日志监控你的应用程序的呢？Golang 没有异常，只有错误。因此你的第一印象可能就是开发 Golang 日志策略并不是一件简单的事情。不支持异常事实上并不是什么问题，异常在很多编程语言中已经失去了其异常性：它们过于被滥用以至于它们的作用都被忽视了。
|
||||
|
||||
在进一步深入之前，我们首先会介绍 Golang 日志基础并讨论 Golang 日志标准、元数据意义、以及最小化 Golang 日志对性能的影响。通过日志，你可以追踪用户在你应用中的活动，快速识别你项目中失效的组件，并监控总的性能以及用户体验。
|
||||
在进一步深入之前，我们首先会介绍 Golang 日志的基础，并讨论 Golang 日志标准、元数据意义、以及最小化 Golang 日志对性能的影响。通过日志，你可以追踪用户在你应用中的活动，快速识别你项目中失效的组件，并监控总体性能以及用户体验。
|
||||
|
||||
### I. Golang 日志基础
|
||||
|
||||
### 1) 使用 Golang "log" 库
|
||||
#### 1) 使用 Golang “log” 库
|
||||
|
||||
Golang 给你提供了一个称为 “log” 的原生[日志库][3] 。它的日志器完美适用于追踪简单的活动，例如通过使用可用的[选项][4]在错误信息之前添加一个时间戳。
|
||||
|
||||
@ -39,9 +39,9 @@ if err != nil {
|
||||
}
|
||||
```
|
||||
|
||||
如果你尝试除以0，你就会得到类似下面的结果：
|
||||
如果你尝试除以 0，你就会得到类似下面的结果：
|
||||
|
||||
|
||||
|
||||
|
||||
为了快速测试一个 Golang 函数，你可以使用 [go playground][5]。
|
||||
|
||||
@ -59,11 +59,11 @@ func main() {
|
||||
if err != nil {
|
||||
log.Fatal(err)
|
||||
}
|
||||
// 完成后延迟关闭，而不是你认为这是惯用的!
|
||||
// 完成后延迟关闭，而不是习惯!
|
||||
defer f.Close()
|
||||
//设置日志输出到 f
|
||||
log.SetOutput(f)
|
||||
//测试例
|
||||
//测试用例
|
||||
log.Println("check to make sure it works")
|
||||
}
|
||||
```
|
||||
@ -73,13 +73,14 @@ func main() {
|
||||
现在你就可以记录它们的错误以及根本原因啦。
|
||||
|
||||
另外，日志也可以帮你将活动流拼接在一起，查找需要修复的错误上下文，或者调查在你的系统中单个请求如何影响其它应用层和 API。
|
||||
|
||||
为了获得更好的日志效果，你首先需要在你的项目中使用尽可能多的上下文丰富你的 Golang 日志，并标准化你使用的格式。这就是 Golang 原生库能达到的极限。使用最广泛的库是 [glog][8] 和 [logrus][9]。必须承认还有很多好的库可以使用。如果你已经在使用支持 JSON 格式的库，你就不需要再换其它库了，后面我们会解释。
|
||||
|
||||
### II. 你 Golang 日志的统一格式
|
||||
### II. 为你 Golang 日志统一格式
|
||||
|
||||
### 1) JSON 格式的结构优势
|
||||
#### 1) JSON 格式的结构优势
|
||||
|
||||
在一个项目或者多个微服务中结构化你的 Golang 日志可能是最困难的事情，但一旦完成，它看起来就微不足道了。结构化你的日志能使机器可读（参考我们 [收集日志的最佳实践博文][10]）。灵活性和层级是 JSON 格式的核心，因此信息能够轻易被人类和机器解析以及处理。
|
||||
在一个项目或者多个微服务中结构化你的 Golang 日志可能是最困难的事情，但一旦完成就很轻松了。结构化你的日志能使机器可读（参考我们 [收集日志的最佳实践博文][10]）。灵活性和层级是 JSON 格式的核心，因此信息能够轻易被人类和机器解析以及处理。
|
||||
|
||||
下面是一个使用 [Logrus/Logmatic.io][11] 如何用 JSON 格式记录日志的例子：
|
||||
|
||||
@ -110,9 +111,9 @@ func main() {
|
||||
}
|
||||
```
|
||||
|
||||
### 2) 标准化 Golang 日志
|
||||
#### 2) 标准化 Golang 日志
|
||||
|
||||
出现在你代码不同部分的同一个错误以不同形式被记录下来是一件可耻的事情。下面是一个由于一个变量错误导致无法确定 web 页面加载状态的例子。一个开发者日志格式是：
|
||||
同一个错误出现在你代码的不同部分，却以不同形式被记录下来是一件可耻的事情。下面是一个由于一个变量错误导致无法确定 web 页面加载状态的例子。一个开发者日志格式是：
|
||||
|
||||
```
|
||||
message: 'unknown error: cannot determine loading status from unknown error: missing or invalid arg value client'</span>
|
||||
@ -124,13 +125,13 @@ message: 'unknown error: cannot determine loading status from unknown error: mis
|
||||
unknown error: cannot determine loading status - invalid client</span>
|
||||
```
|
||||
|
||||
强制日志标准化的一个好的解决办法是在你的代码和日志库之间创建一个接口。这个标准化接口会包括所有你想添加到你日志中的可能行为的预定义日志消息。这么做可以防止不符合你想要的标准格式的自定义日志信息。这么做也便于日志调查。
|
||||
强制日志标准化的一个好的解决办法是在你的代码和日志库之间创建一个接口。这个标准化接口会包括所有你想添加到你日志中的可能行为的预定义日志消息。这么做可以防止出现不符合你想要的标准格式的自定义日志信息。这么做也便于日志调查。
|
||||
|
||||
|
||||
|
||||
|
||||
由于日志格式都被统一处理，使它们保持更新也变得更加简单。如果出现了一种新的错误类型，它只需要被添加到一个接口，这样每个组员都会使用完全相同的信息。
|
||||
|
||||
最长使用的简单例子就是在 Golang 日志信息前面添加日志器名称和 id。你的代码然后就会发送 “事件” 到你的标准化接口，它会继续讲它们转化为 Golang 日志消息。
|
||||
最常使用的简单例子就是在 Golang 日志信息前面添加日志器名称和 id。你的代码然后就会发送 “事件” 到你的标准化接口，它会继续讲它们转化为 Golang 日志消息。
|
||||
|
||||
```
|
||||
// 主要部分，我们会在这里定义所有消息。
|
||||
@ -170,10 +171,10 @@ JSON 格式如下：
|
||||
|
||||
现在 Golang 日志已经按照特定结构和标准格式记录，时间会决定需要添加哪些上下文以及相关信息。为了能从你的日志中抽取信息，例如追踪一个用户活动或者工作流，上下文和元数据的顺序非常重要。
|
||||
|
||||
例如在 logrus 库中可以按照下面这样使用 JSON 格式添加 Hostname、appname 和 session 参数：
|
||||
例如在 logrus 库中可以按照下面这样使用 JSON 格式添加 `hostname`、`appname` 和 `session` 参数：
|
||||
|
||||
```
|
||||
// 对于元数据，通常做法是通过复用重用日志语句中的字段。
|
||||
// 对于元数据，通常做法是通过复用来重用日志语句中的字段。
|
||||
contextualizedLog := log.WithFields(log.Fields{
|
||||
"hostname": "staging-1",
|
||||
"appname": "foo-app",
|
||||
@ -182,7 +183,7 @@ JSON 格式如下：
|
||||
contextualizedLog.Info("Simple event with global metadata")
|
||||
```
|
||||
|
||||
元数据可以视为 javascript 片段。为了更好地说明它们有多么重要，让我们看看几个 Golang 微服务中元数据的使用。你会清楚地看到在你的应用程序中跟踪用户的决定性。这是因为你不仅需要知道一个错误发生了，还要知道是哪个实例以及什么模式导致了错误。假设我们有两个按顺序调用的微服务。上下文信息被传输并保存在头部（header）：
|
||||
元数据可以视为 javascript 片段。为了更好地说明它们有多么重要，让我们看看几个 Golang 微服务中元数据的使用。你会清楚地看到是怎么在你的应用程序中跟踪用户的。这是因为你不仅需要知道一个错误发生了，还要知道是哪个实例以及什么模式导致了错误。假设我们有两个按顺序调用的微服务。上下文信息保存在头部（header）中传输：
|
||||
|
||||
```
|
||||
func helloMicroService1(w http.ResponseWriter, r *http.Request) {
|
||||
@ -229,7 +230,7 @@ io.WriteString(w, fmt.Sprintf(aResponseMessage, 2, session, track, parent))
|
||||
}
|
||||
```
|
||||
|
||||
现在第二个微服务中已经有和初始查询相关的上下文和信息，一个 JSON 格式的日志消息看起来类似：
|
||||
现在第二个微服务中已经有和初始查询相关的上下文和信息，一个 JSON 格式的日志消息看起来类似如下。
|
||||
|
||||
在第一个微服务：
|
||||
|
||||
@ -245,26 +246,27 @@ io.WriteString(w, fmt.Sprintf(aResponseMessage, 2, session, track, parent))
|
||||
|
||||
如果在第二个微服务中出现了错误，多亏了 Golang 日志中保存的上下文信息，现在我们就可以确定它是怎样被调用的以及什么模式导致了这个错误。
|
||||
|
||||
如果你想进一步深挖 Golang 的追踪能力，这里还有一些库提供了追踪功能，例如 [Opentracing][12]。这个库提供了一种简单的方式在复杂（或简单）的架构中添加追踪实现。它通过不同步骤允许你追踪用户的查询，就像下面这样：
|
||||
如果你想进一步深挖 Golang 的追踪能力，这里还有一些库提供了追踪功能，例如 [Opentracing][12]。这个库提供了一种简单的方式在或复杂或简单的架构中添加追踪的实现。它通过不同步骤允许你追踪用户的查询，就像下面这样：
|
||||
|
||||
|
||||
|
||||
|
||||
### IV. Golang 日志对性能的影响
|
||||
|
||||
### 1) 不要在 Goroutine 中使用日志
|
||||
#### 1) 不要在 Goroutine 中使用日志
|
||||
|
||||
在每个 goroutine 中创建一个新的日志器看起来很诱人。但最好别这么做。Goroutine 是一个轻量级线程管理器，它用于完成一个 “简单的” 任务。因此它不应该负责日志。它可能导致并发问题，因为在每个 goroutine 中使用 `log.New()` 会重复接口，所有日志器会并发尝试访问同一个 io.Writer。
|
||||
|
||||
在每个 goroutine 中创建一个新的日志器看起来很诱人。但最好别这么做。Goroutine 是一个轻量级线程管理器，它用于完成一个 “简单的” 任务。因此它不应该负责日志。它可能导致并发问题，因为在每个 goroutine 中使用 log.New() 会复用接口，所有日志器会并发尝试访问同一个 io.Writer。
|
||||
为了限制对性能的影响以及避免并发调用 io.Writer，库通常使用一个特定的 goroutine 用于日志输出。
|
||||
|
||||
### 2) 使用异步库
|
||||
#### 2) 使用异步库
|
||||
|
||||
尽管有很多可用的 Golang 日志库，要注意它们中的大部分都是同步的（事实上是伪异步）。原因很可能是到现在为止它们中没有一个由于日志对性能有严重影响。
|
||||
尽管有很多可用的 Golang 日志库，要注意它们中的大部分都是同步的（事实上是伪异步）。原因很可能是到现在为止它们中没有一个会由于日志严重影响性能。
|
||||
|
||||
但正如 Kjell Hedström 在[他的实验][13]中展示的，使用多个线程创建成千上万日志，在最坏情况下异步 Golang 日志也会有 40% 的性能提升。因此日志是有开销的，也会对你的应用程序性能产生影响。如果你并不需要处理大量的日志，使用伪异步 Golang 日志库可能就足够了。但如果你是处理大量的日志，或者很关注性能，Kjell Hedström 的异步解决方案就很有趣（尽管事实上你可能需要进一步开发，因为它只包括了最小的功能需求）。
|
||||
但正如 Kjell Hedström 在[他的实验][13]中展示的，使用多个线程创建成千上万日志，即便是在最坏情况下，异步 Golang 日志也会有 40% 的性能提升。因此日志是有开销的，也会对你的应用程序性能产生影响。如果你并不需要处理大量的日志，使用伪异步 Golang 日志库可能就足够了。但如果你需要处理大量的日志，或者很关注性能，Kjell Hedström 的异步解决方案就很有趣（尽管事实上你可能需要进一步开发，因为它只包括了最小的功能需求）。
|
||||
|
||||
### 3）使用严重等级管理 Golang 日志
|
||||
#### 3）使用严重等级管理 Golang 日志
|
||||
|
||||
一些日志库允许你启用或停用特定日志器，这可能会派上用场。例如在生产环境中你可能不需要一些特定等级的日志。下面是一个如何在 glog 库中停用日志器的例子，其中日志器被定义为布尔值：
|
||||
一些日志库允许你启用或停用特定的日志器，这可能会派上用场。例如在生产环境中你可能不需要一些特定等级的日志。下面是一个如何在 glog 库中停用日志器的例子，其中日志器被定义为布尔值：
|
||||
|
||||
```
|
||||
type Log bool
|
||||
@ -279,14 +281,15 @@ if debug {
|
||||
|
||||
然后你就可以在配置文件中定义这些布尔参数来启用或者停用日志器。
|
||||
|
||||
没有一个好的 Golang 日志策略，Golang 日志可能开销很大。开发人员应该抵制记录几乎所有事情的诱惑 - 尽管它非常有趣！如果日志的目的是为了获取尽可能多的信息，为了避免包含没用元素的日志的白噪音，必须正确使用日志。
|
||||
没有一个好的 Golang 日志策略，Golang 日志可能开销很大。开发人员应该抵制记录几乎所有事情的诱惑 - 尽管它非常有趣！如果日志的目的是为了获取尽可能多的信息，为了避免包含无用元素的日志的白噪音，必须正确使用日志。
|
||||
|
||||
### V. 集中 Golang 日志
|
||||
### V. 集中化 Golang 日志
|
||||
|
||||
|
||||
如果你的应用程序是部署在多台服务器上的，可以避免为了调查一个现象需要连接到每一台服务器的麻烦。日志集中确实有用。
|
||||
|
||||
|
||||
使用日志装箱工具，例如 windows 中的 Nxlog，linux 中的 Rsyslog（默认安装了的）、Logstash 和 FluentD，是最好的实现方式。日志装箱工具的唯一目的就是发送日志，因此它们管理连接失效以及其它你很可能会遇到的问题。
|
||||
如果你的应用程序是部署在多台服务器上的，这样可以避免为了调查一个现象需要连接到每一台服务器的麻烦。日志集中确实有用。
|
||||
|
||||
使用日志装箱工具，例如 windows 中的 Nxlog，linux 中的 Rsyslog（默认安装了的）、Logstash 和 FluentD 是最好的实现方式。日志装箱工具的唯一目的就是发送日志，因此它们能够处理连接失效以及其它你很可能会遇到的问题。
|
||||
|
||||
这里甚至有一个 [Golang syslog 软件包][14] 帮你将 Golang 日志发送到 syslog 守护进程。
|
||||
|
||||
@ -294,11 +297,11 @@ if debug {
|
||||
|
||||
在你项目一开始就考虑你的 Golang 日志策略非常重要。如果在你代码的任意地方都可以获得所有的上下文，追踪用户就会变得很简单。从不同服务中阅读没有标准化的日志是已经很痛苦的事情。一开始就计划在多个微服务中扩展相同用户或请求 id，后面就会允许你比较容易地过滤信息并在你的系统中跟踪活动。
|
||||
|
||||
你是构架一个很大的 Golang 项目还是几个微服务也会影响你的日志策略。一个大项目的主要组件应该有按照它们功能命名的特定 Golang 日志器。这使你可以立即判断出日志来自你的哪一部分代码。然而对于微服务或者小的 Golang 项目，较少的核心组件需要它们自己的日志器。但在每种情形中，日志器的数目都应该保持低于核心功能的数目。
|
||||
你是在构架一个很大的 Golang 项目还是几个微服务也会影响你的日志策略。一个大项目的主要组件应该有按照它们功能命名的特定 Golang 日志器。这使你可以立即判断出日志来自你的哪一部分代码。然而对于微服务或者小的 Golang 项目，只有较少的核心组件需要它们自己的日志器。但在每种情形中，日志器的数目都应该保持低于核心功能的数目。
|
||||
|
||||
你现在已经可以使用 Golang 日志量化决定你的性能或者用户满意度啦！
|
||||
|
||||
_如果你有想阅读的特定编程语言，在 Twitter [][1][@logmatic][2] 上告诉我们吧。_
|
||||
_如果你有想阅读的特定编程语言，在 Twitter [@logmatic][2] 上告诉我们吧。_
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
@ -307,7 +310,7 @@ via: https://logmatic.io/blog/our-guide-to-a-golang-logs-world/
|
||||
|
||||
作者：[Nils][a]
|
||||
译者：[ictlyh](https://github.com/ictlyh)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
Loading…
Reference in New Issue
Block a user