Go kit

Blog


主页    示例    FAQ    博客    中文社区  ·   GitHub    GoDoc    Slack    邮件列表


Instrumentation 对比聚合日志?

12 October 2016

Go kit邮件列表,Chris Ford 最近问到,

我遇到Go kit中instrumentation的部分,我想知道对比聚合日志事件它有哪些的优势?比如, instrumentation中关于响应时间、请求计数和这些指标;能够简单的记录每次请求,然后统 计日志中的请求事件。我的这个假设是否正确,或者有哪些问题?因为我没看到用聚合日志无 法实现的用例,我猜测instrumentation的性能和实时性更好,除此之外还有哪些优势呢?

很好的问题,我经常看到类似问题。理论上Chris是正确的:如果你把每个请求的完整信息以可查询 的方式记录到类似ELK这种系统中,你同样可以使用非常复杂的查询语言构造同样的信息(99%延迟 时间、错误率等)。使用instrumentation的最终原因是关于复杂性、可维护性和适应性。

首先,你要考虑纯数据量:对于每个具有足够信息的请求,人机器可读取的日志行会产生大量流量。 我可以从一线经验来说,这将很快超过_实际生产流量_,完全占用各种资源:网络、日志传输、虚 拟机本身的CPU、负责存储日志和日志查询的机器/集群等。我承认,这似乎是有悖常理的,就像一开 始你觉得是没有意义的担忧一样;但是,相信我,问题来的比你想象的要早得多。

那么通过跟踪这些,您实际想要完成的任务是很复杂的。整体都是可被监测的:对构建的分布式系统 的内部工作有一些了解。这意味着在某种意义上处理延迟,分位数,错误率,top-K资源消费者等作 是最重要的,而不是在某些日志数据上map/reduce进程的文本输出。而且,理想情况下,您希望这 些东内容能够以接近秒级的实时视图查看。另外,从理论上讲,这些都可以从文本或者结构化应用 日志中计算,但不能以一种有用的方式允许这些信息作为更复杂的反馈系统、报告的基础,作为系 统操作员的工具。

最后,服务本身就有成本。回到我的第一个观点:输出一行文本到stdout或者rsyslog或者每个可跟 踪的东西比一个好用instrumentation系统做的事成本(CPU)高得多:比如,Prometheus instrumentation 只涉及更新内存中的register,累加的QPS。这里还有一点关于软件工程的东西:记录和提供关于服 务如何做好instrumentation是该服务对其运行时环境的_契约_的一部分。例如保持TP99低于10毫秒 是你服务SLA(服务水平承诺)的一部分,并且记录/发布数据以验证SLA与业务逻辑中的其他任何内 容一样重要。所有这一切都是说,你要为这种事情建立一个可靠的、专门的基本原理:很难为你的 日志行定义一个契约,或者适当的单元测试。

更多关于最新的观点,包括更多的使用instrumentation理由,请参阅O’Reilly的网站 the Site Reliability Engineering book, 更多关于logging和instrumentation的内容,请看我的同名博客文章 Logging v instrumentation


欢迎来到新的Go kit网站!

01 July 2016

Go kit诞生于一个小型会议上的一次演讲,并将其前18个月的时间花在了GitHub上,并且有很多重大 改变(对此非常抱歉)。许多设计讨论发生在最初的RFC中,然后是GitHub的issues,邮件列表,特 别是Slack频道。 虽然守则可以捕捉到这些讨论的基本原理和结果,但是它不能很容易地把握上下文: 对话本身,替代方案,所有决定的利弊,预期用法,注意事项。 这些东西往往是最有价值的,特别 是对新人来说。

所以,欢迎来到新的Go kit网站! 主要目的是捕获和记录形成Go kit的决策背景。 我将记录并保存补充信息,以帮助你理解并有效地将Go kit应用于你的组织。

最初,我着重在Slack,邮件列表等常见问题和对话的基础上构建一个广泛的FAQ。 但是,示例比任何资源都有用,所以,以后我会把repo上的示例和教程移植过来。

快乐编程 🏌