测量所有，量化一切！
Esty 当年发布 statsd 写过一篇文章： Measure Anything, Measure Everything 。 这篇文章对性能监控领域影响很大，系统监控工具如果能够做到 All in One，那真的可以解决人力和时间成本上的问题。OneAPM 的工程师对这篇经典文章进行了编译整理，希望能对大家有所启发:
如果 Etsy 社区也有信仰，那一定是图表，Ian Malpass 在 Code as Craft 发表的文章中这么描述: 只要是变化的事件，我们就追踪它。有时候，为了记录事件的变化，我们从它不变时就用图表进行记录。通常，我们会从三个层面进行测量：网络、设备以及应用。
应用指标往往是这三者中最难测量却又最重要的。应用指标与业务息息相关，随着应用的变化而变化。在此，我们不会早早地规划要测量的所有指标，将它们放在经典的测量管理系统中，我们只会将工程师可能测量或计时的指标以最简便的方式做成图表。（我们可以 随时随地 修改代码并部署它，因此，测量“ X 的发生频率”，“ X 在过去半小时内的发生情况”，只要有需求，就能很快实现。）
StatsD 简介
StatsD 是一种简单的监听 UDP 端口消息的 NodeJS 守护程序，NodeJS 对于基于事件的系统监控真的很简单。该程序会分析这些消息，抽取中其中的测量数据，并定期将数据推送给 Graphite 。
我们选择 Graphite 的原因很多：它使用简便，图形化和数据处理能力强大。我们可以结合通过 StatsD 或其他指标收集系统收集到的数据来了解系统运行情况。最重要的是，对于 StatsD 来说，可以根据传输给 Graphite 的数据自动创建指标。这意味着，工程师们在追踪新的指标时无需担心管理成本，只要告诉 StatsD：“我想要追踪 grue.dinners ”，该指标就会自动出现在 Graphite 中。此外，向 Graphite 推送数据的频率为10秒，因此，StatsD 测量的指标数据几乎可以做到实时。
因此，有了 StatsD，抓取比率、速度等数据值就变得很简单了，再通过 Graphite 对数据进行处理，对数据的查看、分析也很容易实现。
为什么使用 UDP?
前面也说了, Statsd 是通过 UDP 传输数据的，那么有人会问为什么选 UDP 而不选 TCP 呢? 首先，UDP 速度很快。任何人都不想为了提高应用性能而减慢其速度。此外，UDP 包遵循“发送后不管（fire-and-forget）”机制。所以要么 StatsD 接收了这个包，要么没有，应用不会在意 StatsD 是运行、宕机还是着火了。它单纯地相信一切运行正常。即便并非如此，stats 进程出现了问题，应用也不受影响。因为我们也信仰“正常运行时间（uptime）”概念，所以这不成问题。（当然，我们可以通过图表追踪 UDP 包接收失败的情况。）
测量任意事件
以下是我们使用 PHP StatsD 函数库的实现方式：
StatsD::increment("grue.dinners"); 通过这样一行代码，就在进程中创建了一个新的计数器，在每次执行后增加计数。接下来，就可以只关注图表的展现，而不去考虑其他了。
我们可以使用 Graphite 提供的数据处理工具来处理上面的数据，创建异常偏离标准值的图表。
（有时，我们会使用 Graphite 中的 rawData=true 选项获取能自动推送给监控系统的数字流，这一类型的图表非常容易被监控。）
我们不仅监控诸如“有多少人登陆了这个网站”这类重要的事情，我们也会追踪一些琐碎的事件，比如“厨房里还剩多少咖啡”：
为所有事件计时
除了计数，我们还可以追踪时间。
$start = microtime(true); eat_adventurer(); StatsD::timing("grue.dinners", (microtime(true) - $start) * 1000); StatsD 可以自动追踪次数，平均值，最大/小值，以及百分之 90 时间值。在下面的例子中，我们测量了部分搜索设备的执行时间。 
数据采样
我们很早就发现，如果受追踪的某些事件发生的频率非常高，UDP 包就会溢满 StatsD。为了解决这个问题，我们增加了数据采样的选项——只在一段时间内传送数据包。但对于那些异常活跃的事件，即便这么做还是会带来过多的数据。
为此，我们只记录十个事件中的一个事件，可以采取以下方法：
StatsD::increment(“adventurer.heartbeat”, 0.1); 测量所有事件
追踪所有事件是提高效率的关键。有了 StatsD，工程师们可以轻松追踪他们需要关注的事务，而无需费时地修改配置。
Cloud Insight 集监控、管理、计算、协作、可视化于一身，帮助所有 IT 公司，减少在系统监控上的人力和时间成本投入，让运维工作更加高效、简单。想阅读更多技术文章，请访问OneAPM 官方技术博客。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
