通过 Kibana 查询日志

微服务工程中的实例启动后，日志都可以在 Kibana 中查看。如果想再仔细验证，则可以在搜索框中输入关键字进行更精准的匹配。比如，笔者分别搜索了订单微服务和用户微服务的启动类名称，搜索结果如图 13-2 和图 13-3 所示。

另外，搜索的时候一定要注意时间和区间，有时搜索不到结果可能是因为时间选择不对，页面右上角有时间选择器，单击 “切换” 按钮即可。

当然，有些读者会有疑问，页面里的日志怎么不刷新？明明打印了日志且时间选择也是正确的，但是 Kibana 页面中就是没有显示。因为在默认情况下，Kibana 中的 Discover 页面不会定时刷新，需要手动单击右上角的 “刷新” 按钮，如果想设置自动刷新，则可以按照图 13-4 中的示意进行配置。

除输入一些关键字外，还可以根据一些关键字段搜索日志。比如，直接搜索最近 15 分钟 error 级别的日志，就可以在输入框中输入 “level：error” 来搜索，相关的信息就会出现，如图 13-5 所示。

当然，如果想要更精确，那就加上一些条件。比如，搜索最近 15 分钟 GoodsServiceExceptionHandler 输出的 error 日志，就可以在输入框中输入 “level：error andlogger_name："ltd.goods.cloud.newbee.config.GoodsServiceExceptionHandler"”，相关的信息就会显示出来，如图 13-6 所示。

除此之外，还可以使用在代码中自定义的一些字符，如 “mamimamihong”、“zhimakaimen”，都是一些自定义的信息。如果觉得哪里可能会出问题，就打印一下日志，这样定位问题也更快一些。当然，也不要打印太多日志，没问题后就把一些没用的日志输出代码及时删掉。

笔者在平时上班的时候，到工位上的前两件事肯定是查看邮件和查看负责业务的错误日志，在浏览器中一直打开着 Kibana 页面，时不时地刷新一下，在遇到问题时赶紧定位，然后处理。

使用 Sleuth 和 Zikpin 可以完成一套链路追踪系统的搭建，帮助开发人员串联调用链中的上下游访问链路，快速定位线上异常出现在哪个环节。不过，仅仅只是日志打标和追踪还不够，如果想要更加详细的信息，还要借助程序中输出的日志信息。这样，链路追踪加上日志中心，整个链路追踪就实现了闭环，有日志打标、日志收集、日志索引、日志精确搜索、链路可视化和日志的统计报表等。

简单举一个例子。看到 error 日志之后，想要查看上下游微服务实例的一些情况，就可以把这条 error 日志中的 traceId 或 spanId 作为搜索条件在 Kibana 中查询所有相关的日志信息，查询条件就输入 “traceId：××××××××” 或 “spanId：××××××××”，或者直接搜索 traceId 或 spanId 的值，如图 13-7 所示。

拔出萝卜带出泥，与之相关的一些日志就都显示出来了。

为了代码演示需要及展现出更好的效果，笔者在代码里把一些日志级别调成了 debug 级别。在私下测试时可以这样做，在企业开发中千万不能这样做，因为 debug 级别的日志真的太多了。这可不是开玩笑的，把太多 debug 级别的日志弄到日志中心很麻烦。

好的，ELK 日志中心的整合及配置也讲解完毕了，整个链路追踪过程和 ELK 日志中心的搭建及整合的知识点也完成了闭环。

虽然新蜂商城项目微服务版本的功能模块已经全部讲解完毕，但是新蜂商城的优化和迭代工作不会停止，更新和优化的内容都会上传到开源仓库中供读者学习和使用。行文至此，笔者万般不舍。在本书的最后，诚心地祝愿读者能够在编程的道路上寻找到属于自己的精彩！