请选择 进入手机版 | 继续访问电脑版

设为首页 收藏本站
思科社区 关注
思科社区

搜索
热搜: 邮件服务器
查看: 1067|回复: 3

【原创翻译】微服务日志的各种最佳实践(1)

[复制链接]
发表于 2020-3-18 09:41:27 | 显示全部楼层 |阅读模式

引言:本文向您介绍如何为微服务应用收集有意义的日志,并妥善保存的一些最佳实践。
微服务架构(http://microservices.io/)是一种全新的应用结构,它能够帮助您通过松耦合的系统,开发、测试、部署和发布彼此相互独立的各种服务。因此微服务背后的理念是:将大型系统分解成多个独立的小部分。通常情况下,每个服务都能通过HTTP的端点与其他服务交互。它们在隐藏技术栈细节的同时,会暴露自己的契约contract)给其对应的消费者(consumer)角色。例如:服务A可以在调用服务B的同时,也去调用服务C,而只要整个请求链是完整的,那么服务A就能够对发起请求的客户端做出响应。
微服务架构能够给我们的系统带来很多方面的好处,其主要能力包括:使用不同的技术栈、独立地进行部署、一次只解决一个小问题等。但是,由于它在通信和管理上的复杂性,一般使用微服务的成本会比较高。而且在一个或多个服务出现问题时,微服务则会变得更加复杂。如果没有掌握良好的、且有意义的日志的话,你都无法回答诸如:哪个服务、为什么、和在什么情况下失败了等问题。
老实说,我本人最憎恨那些由于糟糕的日志策略,所导致的一些“未知”的系统错误。下面我们和您分享一些,自己在与微服务打交道时总结出的各种最佳实践。
用唯一性ID来关联各个请求
请回想一下我们上面提到的服务ABC之间的请求调用链。在实践中,我们应当给每一个调用分配一个唯一性的ID,以便标识出每一个请求。
设想您正在记录每个服务的访问与错误日​​志。如果您发现在服务B上有错误,那么您就能知道该错误是来自于服务A、还是服务C
如果错误信息足够详细的话,您也许不必去重现错误。但是多数情况并非如此,您必须通过正确的方式,将各个服务(如服务B)中的所有请求进行错误重现。因此,如果您发现了某个与之相关联的请求,那么您只需要在日志中寻找出它所对应的ID便可。随后,您可以顺藤摸瓜地从系统中将那些主要请求的某个部分,从服务的全量日志中截取出来。接着,您就可以知道是哪项服务的主请求花费了最多的时间。其可能性包括:可能是某项服务使用到了缓存、或是某项服务不止一次调用了其他服务、以及其他有趣的细节。
在响应中包含唯一性ID
微服务的用户可能会不止一次地碰到同一个错误。面对这样情况,您应该乘机对客户端可能接收到的响应进行编码,以便它能够将一个唯一性的ID,连同与该错误相关的任何其他有用的信息都传递出来。当然,这个唯一性的ID完全可以和我们在上面所提到的相关请求保持一致。

因此,在响应的有效载荷中包含与请求相关的唯一性ID,将有助于您和您的客户更迅速地发现各类问题。同时,您也可以获悉请求日期、时间和其他细节上的参数,以便您能够更好地理解自己所碰到的问题。另外,您还可以将请求的ID,添加到诸如“请联系服务管理员,并报告该问题。”之类的常见补充性错误信息之中,以便深入了解到底是什么原因引起该错误,进而防止它在未来再次发生。
发送日志到集中的位置
在此,让我们假设您已经对各种有用的日志信息进行了分类。下一步,我们就需要将各类日志发送到一个集中化的位置。
试想一下:如果您每次都需要登录到各个相互单独的服务器上,以来读取不同的日志信息,那么您将不得不花费更多的时间去试图关联这些问题。这远不如您登录到某一个位置,并一站式地访问到所有的日志,以定位问题。此外,您的系统通常会随着时间的推移,而变得日趋复杂,而各项微服务的数量也会节节攀升。同时,您的各种服务可能会分处不同的服务器或提供商,这都会让形势变得更为复杂。
因此,集中式存放日志正在成为业界的常规方法,特别是当您的服务工作在云端、容器、或其他混合环境之中,而某些服务器可能会在无任何通知的情况下下线的时候。例如,在出现异常错误,或是内存的消耗水平已经达到100%时,某些容器就会被终止运行。
您可以在服务器中断之前,通过设置代理,每五分钟推/拉一次日志,来解决此类问题。您也可以在服务器上配置一个cronjob(定时任务)、sidecar container、或是一个与其他进程共享的文件位置,来集中化各种日志。为了避免日志被篡改,您还可以自行构建一套解决方案,具体请参见链接:https://blog.scalyr.com/2017/11/log-management-need/
可见,将所有服务的日志都集中到一处,会有助于您更容易、且有效地定位各种关联问题。
结构化您的日志数据
在具体实践中,我们很难为所有的日志数据预先定义好格式。有些日志可能需要比其他日志更多的字段,相反这些字段可能会对那些不需要的日志来说不但多余、而且浪费字节数。微服务架构是通过使用不同的技术堆栈,来解决此类问题的。不过,这会影响每个服务的日志格式。例如:某一个服务可能是用逗号来分隔不同的字段,而其他日志则使用的是管道或命名空间。
上述方法显然比较复杂。因此,我们可以通过将自己的日志数据构建成一套标准的格式,如:JavaScript Object NotationJSONhttps://www.json.org/),来简化解析日志的过程。JSON允许您拥有多层次的数据。在必要的时候,您可以在单个日志的事件中获取更多的语义信息。
同时,此法也使得对于特定日志格式的解析更加直接。通过对数据采取结构化,就算您的日志里有各种不同的字段,其格式也会变得更加标准。籍此,您也可以在集中化的位置上创建各种搜索,例如:检索包含有500条及以上,“HTTP_CODE”字段的日志信息。可以说,使用结构化的日志方式既能让您的微服务日志实现标准化,又不失灵活性。

  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分5 (1 评价)
发表于 2020-3-18 15:50:59 | 显示全部楼层
感谢版主分享,谢谢~
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
发表于 2020-4-10 19:53:21 | 显示全部楼层
技术干货。
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
发表于 2020-4-12 22:12:39 | 显示全部楼层
认真学习。
  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5
平均得分0 (0 评价)
您需要登录后才可以回帖 思科 CCO 登录 | 思科 CCO 注册   

本版积分规则

Archiver | 思科社区  

GMT+8, 2020-8-7 20:17 , Processed in 0.158139 second(s), 36 queries .

京ICP备11014401号-17

© 2020 思科系统.版权所有 重要声明 | 保密声明 | 隐私权政策 | 商标 |

快速回复 返回顶部 返回列表