wordpress 空间商,seo是什么职业合法吗,wordpress导航框架,wordpress 分享 微信译者注Peter Bourgon原作#xff1a; Metrics, tracing, and logging译者#xff1a;吴晟原作发表时间#xff1a; 2017年2月21日这是在OpenTracing和分布式追踪领域内广受欢迎的一篇博客文章。在构建监控系统时#xff0c;大家往往在这几个名词和方式之间纠结。 通过这篇文… 译者注Peter Bourgon原作 Metrics, tracing, and logging译者吴晟原作发表时间 2017年2月21日这是在OpenTracing和分布式追踪领域内广受欢迎的一篇博客文章。在构建监控系统时大家往往在这几个名词和方式之间纠结。 通过这篇文章作者很好的阐述了分布式追踪、统计指标与日志之间的区别和关系。正文今天我很荣幸的参加了2017分布式追踪峰会2017 Distributed Tracing Summit 并和来自AWS/X-Ray, OpenZipkin, OpenTracing, Instana, Datadog, Librato以及其他更多组织的同仁进行了愉快的沟通和讨论。 其中一个重要的论点是针对监控项目的范围和定义的。作为一个分布式追踪系统应该管理日志么从不同角度看来到底什么是日志如何通过一张图形象的定位这些形形色色的系统总体说来我觉得我们是在一些通用的名词间纠结。我想我们可以通过图表来定义监控的作用域使各名词的作用范围更明确。 我们使用维恩图Venn diagram来描述Metrics, tracing, logging三个概念的定义。他们三者在某些情况下是重叠的但是我尽量尝试定义他们的不同。如下图所示Metric的特点是它是可累加的他们具有原子性每个都是一个逻辑计量单元或者一个时间段内的柱状图。 例如队列的当前深度可以被定义为一个计量单元在写入或读取时被更新统计 输入HTTP请求的数量可以被定义为一个计数器用于简单累加 请求的执行时间可以被定义为一个柱状图在指定时间片上更新和统计汇总。logging的特点是它描述一些离散的不连续的事件。 例如应用通过一个滚动的文件输出debug或error信息并通过日志收集系统存储到Elasticsearch中 审批明细信息通过Kafka存储到数据库BigTable中 又或者特定请求的元数据信息从服务请求中剥离出来发送给一个异常收集服务如NewRelic。tracing的最大特点就是它在单次请求的范围内处理信息。 任何的数据、元数据信息都被绑定到系统中的单个事务上。 例如一次调用远程服务的RPC执行过程一次实际的SQL查询语句一次HTTP请求的业务性ID。根据上述的定义我们可以标记上图的重叠部分。当然大量的被监控的应用是具有分布式能力(Cloud-native)的应用逻辑处理在单次请求的范围内完成。因此讨论追踪的上下文是有意义的。 但是我们注意到并不是所有的监控系统都绑定在请求的生命周期上的。他们可能是逻辑组件诊断信息、处理过程的生命周期明细信息这些信息和任何离散的请求时正交关系。 所以不是所有的metric和log都可以被塞进追踪系统的概念中至少在不经过数据加工处理是不行的。又或者我们可能发觉使用metric统计数据对应用监控有很大帮助例如prometheus生态可以量化的实时展现应用视图相应的如果我们将metric统计数据强行使用针对log的管道来处理将使我们丢失很多特性。那么在这里我们可以开始对已知的系统进行分类。如Prometheus 专一的metric统计系统随着时间推移也许会进化为追踪系统进而进行请求内的指标统计但不太可能深入到log处理领域。ELK生态提供log的记录滚动和聚合并在其他领域不停的积累更多的特性并集成进来。另外我发现通过维恩图的方式展现三者关系时会正巧展现出一个附加效应。在这三个功能域中metric倾向于更节省资源因为他会“天然的”压缩数据。相反日志倾向于无限增加的会频繁的超出预期的容量。有另一篇我写的关于这方面的文章查看译者注未翻译。所以我们可以在图上绘制出容量的需求趋势metrics低到logging高 而trace可能处于他们两的中间位置也许这不是最完美的方式描述这三者的管理但我从会议现场收到的反馈来看这个分类还是相当不错的随着三者的关系越清晰我们越容易建设性的讨论其他问题。如果你尝试对产品的功能进行定位你可能也需要这张图在讨论中澄清产品的位置。
