【IPFS技术研究】（一）LOG篇

go-ipfs的日志库(github.com/ipfs/go-log)主要使用了github.com/whyrusleeping/go-logging和github.com/opentracing/opentracing-go两个库；其中前者用于记录离散事件，后者用于记录请求范围内的信息，用于追踪系统性能问题。

通过阅读其启动函数SetupLogging发现，go-ipfs的日志库依赖两个系统环境变量IPFS_LOGGING和IPFS_LOGGING_FMT，其中前者定义了输出日志的级别，如果在系统中将该环境变量设置为DEBUG，那么启动程序后，就可以看到所有的调试输出。如果将LogFormats中的shortfile修改为longfile，那么日志会输出全路径文件。这点对开发者来说比较有用，尤其配合emacs的evil-find-file-at-point-with-line可以很方便地在定位日志输出对应具体的代码出处（见下图）。

go-log中的trace扩展了opentracing.Tracer，我们可以在main方法里面调用opentracing.SetGlobalTracer来设置trace的服务名字以及上传地址。openTrace具体资料可以参考这里。本人利用docker搭建了jaedger的all-in-one服务，映射5775端口。测试代码如下：

    cfg := config.Configuration{
		Sampler: &config.SamplerConfig{
			Type:  "const",
			Param: 1,
		},
		Reporter: &config.ReporterConfig{
			LogSpans:           true,
			LocalAgentHostPort: "localhost:5775",
			BufferFlushInterval: 1 * time.Second,
		},
	}
	tracer, closer, error := cfg.New(
		"ipfs.sample",
		config.Logger(jaeger.StdLogger),
	)
	if error != nil {
		log.Fatal(error)
	}
	defer closer.Close()
	opentracing.SetGlobalTracer(tracer)

通过jaedger查看相关trace信息

如果要跟踪多个ipfs实例trace数据，可以修改上面的ipfs.sample为其他名称，比如ip地址之类的。具体会在我下一篇的多开环境搭建中进行介绍。

 

关于日志还有一个小插曲，我将日志输出修改成全路径后，发现日志输出定位的代码路径出错，跟踪发现其getLogger方法中增加了一个额外的堆栈，log.ExtraCalldepth = 1，我修改成0后提交的时候因为0后面多了一个空格被拒，ipfs团队在细节上的把控令人致敬！