但是你是如何使用 Golang 日誌監控你的應用程式的呢？ Golang 沒有異常，只有錯誤。因此你的第一印象可能就是開發 Golang 日誌策略並不是一件簡單的事。不支援異常事實上並不是什麼問題，異常在許多程式語言中已經失去了其異常性：它們過於被濫用以至於它們的作用都被忽視了。
在進一步深入之前，我們首先會介紹 Golang 日誌的基礎，並討論 Golang 日誌標準、元資料意義、以及最小化 Golang 日誌對效能的影響。透過日誌，你可以追蹤使用者在你應用程式中的活動，快速辨識你專案中失效的元件，並監控整體效能以及使用者體驗。
Golang 為你提供了一個稱為 “log” 的原生日誌庫。它的日誌器完美適用於追蹤簡單的活動，例如透過使用可用的選項在錯誤訊息之前添加一個時間戳記。
以下是一個 Golang 中如何記錄錯誤日誌的簡單範例：
package main
import (
"log"
"errors"
"fmt"
)
func main() {
/* 定义局部变量 */
...
/* 除法函数，除以 0 的时候会返回错误 */
ret,err = div(a, b)
if err != nil {
log.Fatal(err)
}
fmt.Println(ret)
}
如果你嘗試除以 0，你就會得到類似下面的結果：
為了快速測試一個 Golang 函數，你可以使用go playground。
為了確保你的日誌總是能輕易訪問，我們建議你把它們寫到一個檔案：
package main
import (
"log"
"os"
)
func main() {
// 按照所需读写权限创建文件
f, err := os.OpenFile("filename", os.O_WRONLY|os.O_CREATE|os.O_APPEND, 0644)
if err != nil {
log.Fatal(err)
}
// 完成后延迟关闭，而不是习惯!
defer f.Close()
//设置日志输出到 f
log.SetOutput(f)
//测试用例
log.Println("check to make sure it works")
}
你可以找到 Golang 日誌的完整指南，以及 “log”庫內可用函數的完整列表。
現在你就可以記錄它們的錯誤以及根本原因啦。
另外，日誌也可以幫你將活動流程拼接在一起，尋找需要修復的錯誤上下文，或調查在你的系統中單一請求如何影響其它應用層和 API。
為了獲得更好的日誌效果，你首先需要在你的專案中使用盡可能多的上下文來豐富你的 Golang 日誌，並標準化你使用的格式。這就是 Golang 原生函式庫能達到的極限。使用最廣泛的函式庫是glog和logrus。必須承認還有很多好的函式庫可以使用。如果你已經在使用支援 JSON 格式的函式庫，你就不需要再換其它函式庫了，後面我們會解釋。
在一個專案或多個微服務中結構化你的 Golang 日誌可能是最困難的事情，但一旦完成就很輕鬆了。結構化你的日誌能讓機器可讀（參考我們收集日誌的最佳實務部落格文章）。靈活性和層級是 JSON 格式的核心，因此資訊能夠輕易被人類和機器解析以及處理。
以下是使用Logrus/Logmatic.io如何用 JSON 格式來記錄日誌的範例：
package main
import (
log "github.com/Sirupsen/logrus"
"github.com/logmatic/logmatic-go"
)
func main() {
// 使用 JSONFormatter
log.SetFormatter(&logmatic.JSONFormatter{})
// 使用 logrus 像往常那样记录事件
log.WithFields(log.Fields{"string": "foo", "int": 1, "float": 1.1 }).Info("My first ssl event from golang")
}
會輸出結果：
{
"date":"2016-05-09T10:56:00+02:00",
"float":1.1,
"int":1,
"level":"info",
"message":"My first ssl event from golang",
"String":"foo"
}
同一个错误出现在你代码的不同部分，却以不同形式被记录下来是一件可耻的事情。下面是一个由于一个变量错误导致无法确定 web 页面加载状态的例子。一个开发者日志格式是：
message: 'unknown error: cannot determine loading status from unknown error: missing or invalid arg value client'</span>
另一个人的格式却是：
unknown error: cannot determine loading status - invalid client</span>
强制日志标准化的一个好的解决办法是在你的代码和日志库之间创建一个接口。这个标准化接口会包括所有你想添加到你日志中的可能行为的预定义日志消息。这么做可以防止出现不符合你想要的标准格式的自定义日志信息。这么做也便于日志调查。
由于日志格式都被统一处理，使它们保持更新也变得更加简单。如果出现了一种新的错误类型，它只需要被添加到一个接口，这样每个组员都会使用完全相同的信息。
最常使用的简单例子就是在 Golang 日志信息前面添加日志器名称和 id。你的代码然后就会发送 “事件” 到你的标准化接口，它会继续讲它们转化为 Golang 日志消息。
// 主要部分，我们会在这里定义所有消息。
// Event 结构体很简单。为了当所有信息都被记录时能检索它们，
// 我们维护了一个 Id
var (
invalidArgMessage = Event{1, "Invalid arg: %s"}
invalidArgValueMessage = Event{2, "Invalid arg value: %s => %v"}
missingArgMessage = Event{3, "Missing arg: %s"}
)
// 在我们应用程序中可以使用的所有日志事件
func (l *Logger)InvalidArg(name string) {
l.entry.Errorf(invalidArgMessage.toString(), name)
}
func (l *Logger)InvalidArgValue(name string, value interface{}) {
l.entry.WithField("arg." + name, value).Errorf(invalidArgValueMessage.toString(), name, value)
}
func (l *Logger)MissingArg(name string) {
l.entry.Errorf(missingArgMessage.toString(), name)
}
因此如果我们使用前面例子中无效的参数值，我们就会得到相似的日志信息：
time="2017-02-24T23:12:31+01:00" level=error msg="LoadPageLogger00003 - Missing arg: client - cannot determine loading status" arg.client=<nil> logger.name=LoadPageLogger
JSON 格式如下：
{"arg.client":null,"level":"error","logger.name":"LoadPageLogger","msg":"LoadPageLogger00003 - Missing arg: client - cannot determine loading status", "time":"2017-02-24T23:14:28+01:00"}
现在 Golang 日志已经按照特定结构和标准格式记录，时间会决定需要添加哪些上下文以及相关信息。为了能从你的日志中抽取信息，例如追踪一个用户活动或者工作流，上下文和元数据的顺序非常重要。
例如在 logrus 库中可以按照下面这样使用 JSON 格式添加hostname、appname和session 参数：
// 对于元数据，通常做法是通过复用来重用日志语句中的字段。
contextualizedLog := log.WithFields(log.Fields{
"hostname": "staging-1",
"appname": "foo-app",
"session": "1ce3f6v"
})
contextualizedLog.Info("Simple event with global metadata")
元数据可以视为 javascript 片段。为了更好地说明它们有多么重要，让我们看看几个 Golang 微服务中元数据的使用。你会清楚地看到是怎么在你的应用程序中跟踪用户的。这是因为你不仅需要知道一个错误发生了，还要知道是哪个实例以及什么模式导致了错误。假设我们有两个按顺序调用的微服务。上下文信息保存在头部（header）中传输：
func helloMicroService1(w http.ResponseWriter, r *http.Request) {
client := &http.Client{}
// 该服务负责接收所有到来的用户请求
// 我们会检查是否是一个新的会话还是已有会话的另一次调用
session := r.Header.Get("x-session")
if ( session == "") {
session = generateSessionId()
// 为新会话记录日志
}
// 每个请求的 Track Id 都是唯一的，因此我们会为每个会话生成一个
track := generateTrackId()
// 调用你的第二个微服务，添加 session/track
reqService2, _ := http.NewRequest("GET", "http://localhost:8082/", nil)
reqService2.Header.Add("x-session", session)
reqService2.Header.Add("x-track", track)
resService2, _ := client.Do(reqService2)
….
当调用第二个服务时：
func helloMicroService2(w http.ResponseWriter, r *http.Request) {
// 类似之前的微服务，我们检查会话并生成新的 track
session := r.Header.Get("x-session")
track := generateTrackId()
// 这一次，我们检查请求中是否已经设置了一个 track id，
// 如果是，它变为父 track
parent := r.Header.Get("x-track")
if (session == "") {
w.Header().Set("x-parent", parent)
}
// 为响应添加 meta 信息
w.Header().Set("x-session", session)
w.Header().Set("x-track", track)
if (parent == "") {
w.Header().Set("x-parent", track)
}
// 填充响应
w.WriteHeader(http.StatusOK)
io.WriteString(w, fmt.Sprintf(aResponseMessage, 2, session, track, parent))
}
现在第二个微服务中已经有和初始查询相关的上下文和信息，一个 JSON 格式的日志消息看起来类似如下。
在第一个微服务：
{"appname":"go-logging","level":"debug","msg":"hello from ms 1","session":"eUBrVfdw","time":"2017-03-02T15:29:26+01:00","track":"UzWHRihF"}
在第二个微服务：
{"appname":"go-logging","level":"debug","msg":"hello from ms 2","parent":"UzWHRihF","session":"eUBrVfdw","time":"2017-03-02T15:29:26+01:00","track":"DPRHBMuE"}
如果在第二个微服务中出现了错误，多亏了 Golang 日志中保存的上下文信息，现在我们就可以确定它是怎样被调用的以及什么模式导致了这个错误。
如果你想进一步深挖 Golang 的追踪能力，这里还有一些库提供了追踪功能，例如Opentracing。这个库提供了一种简单的方式在或复杂或简单的架构中添加追踪的实现。它通过不同步骤允许你追踪用户的查询，就像下面这样：
在每个 goroutine 中创建一个新的日志器看起来很诱人。但最好别这么做。Goroutine 是一个轻量级线程管理器，它用于完成一个 “简单的” 任务。因此它不应该负责日志。它可能导致并发问题，因为在每个 goroutine 中使用 log.New() 会重复接口，所有日志器会并发尝试访问同一个 io.Writer。
为了限制对性能的影响以及避免并发调用 io.Writer，库通常使用一个特定的 goroutine 用于日志输出。
尽管有很多可用的 Golang 日志库，要注意它们中的大部分都是同步的（事实上是伪异步）。原因很可能是到现在为止它们中没有一个会由于日志严重影响性能。
但正如 Kjell Hedström 在他的实验中展示的，使用多个线程创建成千上万日志，即便是在最坏情况下，异步 Golang 日志也会有 40% 的性能提升。因此日志是有开销的，也会对你的应用程序性能产生影响。如果你并不需要处理大量的日志，使用伪异步 Golang 日志库可能就足够了。但如果你需要处理大量的日志，或者很关注性能，Kjell Hedström 的异步解决方案就很有趣（尽管事实上你可能需要进一步开发，因为它只包括了最小的功能需求）。
一些日志库允许你启用或停用特定的日志器，这可能会派上用场。例如在生产环境中你可能不需要一些特定等级的日志。下面是一个如何在 glog 库中停用日志器的例子，其中日志器被定义为布尔值：
type Log bool
func (l Log) Println(args ...interface{}) {
fmt.Println(args...)
}
var debug Log = false
if debug {
debug.Println("DEBUGGING")
}
然后你就可以在配置文件中定义这些布尔参数来启用或者停用日志器。
没有一个好的 Golang 日志策略，Golang 日志可能开销很大。开发人员应该抵制记录几乎所有事情的诱惑 - 尽管它非常有趣！如果日志的目的是为了获取尽可能多的信息，为了避免包含无用元素的日志的白噪音，必须正确使用日志。
如果你的应用程序是部署在多台服务器上的，这样可以避免为了调查一个现象需要连接到每一台服务器的麻烦。日志集中确实有用。
使用日志装箱工具，例如 windows 中的 Nxlog，linux 中的 Rsyslog（默认安装了的）、Logstash 和 FluentD 是最好的实现方式。日志装箱工具的唯一目的就是发送日志，因此它们能够处理连接失效以及其它你很可能会遇到的问题。
这里甚至有一个Golang syslog 软件包帮你将 Golang 日志发送到 syslog 守护进程。
在你项目一开始就考虑你的 Golang 日志策略非常重要。如果在你代码的任意地方都可以获得所有的上下文，追踪用户就会变得很简单。从不同服务中阅读没有标准化的日志是已经很痛苦的事情。一开始就计划在多个微服务中扩展相同用户或请求 id，后面就会允许你比较容易地过滤信息并在你的系统中跟踪活动。
你是在构架一个很大的 Golang 项目还是几个微服务也会影响你的日志策略。一个大项目的主要组件应该有按照它们功能命名的特定 Golang 日志器。这使你可以立即判断出日志来自你的哪一部分代码。然而对于微服务或者小的 Golang 项目，只有较少的核心组件需要它们自己的日志器。但在每种情形中，日志器的数目都应该保持低于核心功能的数目。
你现在已经可以使用 Golang 日志量化决定你的性能或者用户满意度啦！
以上是如何使用 Golang 日誌監控你的應用程式？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
