statsd on steroid

Why Statsd

Statsd 模式最大的好处是两点

• 上报数据者直接是结果的受益者，并对其负责：由于上报数据的人直接是对最终的图表和监控负责的，他有最大的动机去选取合适的指标来帮助本身理解被监控的代码。这种模式能够避免“玩日志”的那帮人和那些平台出现。处理数据的人若是不负责被监控的业务，而上报数据的人不直接决定最终的图表，那么两方都作很差。

• 中心化的设计：全部的大数据平台都是基于分布式的。而最多见的问题是数据上报的时候的节点分布和业务指标统计时所须要的节点分布不一样，致使多个stage之间shuffle数据产生大量的开销。而statsd简化的设计的一个偶然的结果就是由于数据从上报是直接出结果的，因此一个指标所须要的数据是之接上报给同一个物理节点的。不少复杂的聚合计算从而变成可能。

• 数据上报和计算公式二合一：每次上报的数据里都包含了计算所须要的全部元信息（好比计算公式）。省去了注册计算公式的操做，以必定运行时开销的方式简化了使用，并且让数据和数据计算方式的定义二者同时在一块儿简化了总体的维护成本。

监控最重要的是度量整个被监控的对象是否 “is getting work done”，就是要不断关注是否有产出。而关注一个系统是否有产出，就要对这个系统的模型要有理解。statsd作为很方便的工具，具备很是多的优势。若是statsd更进一步，内置的aggregator不只仅是counter/gauge这样的对上报数据的肤浅理解，而是可以从模型的角度更深度地了解上报的数据的含义，那么statsd能够更加大放光芒~

业务指标监控：线性Funnel

最通用的关于业务的建模是所谓的Business Process，或者说是某种Funnel。好比

基于全部的业务场景均可以用上面这样的Funnel模型来建模。而从业务角度来讲就是关注两点：

• 实现这个业务流程的IT系统有没有出问题，是否是有人发了单，可是没有订单并无真正被收到，或者流程被“卡”在某一步了。

• 全部阶段的业务指标（绝对量或者转化率）是否显著低于历史同期（同比）或者前几分钟（环比）

对于一个监控系统来讲就是要提供一个方便的接口让业务直接上报每一个阶段的数据，而后自动把业务关心的指标统计出来并告警。从IT系统监控的角度来讲无需多维，无需复杂如Mixpanel或者Kissmetrics那样，能够简单的提供这样一个上报接口

1000897
sales_funnel
stage=01/estimate
f

或者

1000897
sales_funnel
stage=03/new_order
f

这些数据包含了三个信息：

• 1000897 订单id，或者说是其余某种流量id

• 对应哪一个funnel stage，这里是 new_order

• 当前时间，这个是隐含的就是收到这条消息的时间

这些数据还包含了三个元信息：

• 我须要用funnel模型对数据进行统计并告警

• 这个funnel名叫sales_funnel，全部对同一个funnel的数据上报统一计算

• 03/new_order 说明了当前stage在funnel里的位置，其实也就是用index注册了一个新的funnel，可是并不须要使用者去注册，只须要报数据就行了

利用上报的数据就能够统计出

• 每一个阶段的流量

• 每一个阶段到下一个阶段的转化率

• 每一个阶段到下一个阶段的停留时间

• 还有多少流量停留在某个具体阶段

复杂一点还须要支持超时，就是时间过去一段时间以后自动转换为另一个状态，好比新的订单若是迟迟没有到下一个阶段就自动认为做废了。这些指标去作同比环比的对比，就能够得出很是有意义的业务告警了。

业务指标监控：重复性Funnel

重复性Funnel和简单线性Funnel的区别是中间会有重复性的步骤。重复性的步骤在业务上多是相似于实时计价这样的重复性动做，也多是系统设计里相似心跳这样的设计。对于重复性Funnel，上报的时候须要添加一个标志位来讲明这个stage是否是重复性的。这样能够统计出一个关键指标

• 基于前一个stage和后一个stage得出还有多少流量应该停留在当前的stage

• 基于重复性动做以心跳的形式计算出当前stage还有多少流量active

• active流量和理论流量的比例

这样能够得出当前这个stage后面对应的IT系统是否是有故障了，好比是否是客户端上报遇到了困难，或者服务器挂掉了。

系统指标监控：RPC

另一个告警的层面是从系统架构的角度来建模。最多见的系统的模型就是一个RPC链条。A调用了B，B调用了C。能够把statsd扩展为这样的形式

0.53,error
my_srv/rpc
caller=/login
callee=http://passport.com/validate
rpc

这里包含了四个信息：

• 主调方：/login

• 被调方：协议是 http，服务 passport.com，具体的接口 validate

• 延迟：0.53 秒

• 状态码：error

利用这些信息能够统计出：

• rpc.counter：总调用量

• rpc.error.counter：分错误码调用量

• rpc.latency：延迟的分布

• rpc.error.ratio：全部错误码加和的总错误量相比总调用量的比率

利用error.ratio能够直接阈值告警，其余值相比同比和环比也能够告警。这些rpc指标是统计在某个namespace下的，好比上面是统计在my_srv/rpc下的。把A的被调和B的主调对应起来，就能够把A=>B=>C这样的串联起来。

另外全部的Access log也能够建模成RPC。好比

0.28,success
my_srv/rpc
caller=/login
callee=<self>
rpc

把callee去掉换成本身，不就是access log了，说明当前接口处理是否成功，花了多久。对当前接口处理的某个函数的耗时，也是某种pc（procedure call），只是否是rpc，好比

0.28,success
my_srv/rpc
caller=/login
callee=<self/some_func>
rpc

系统指标监控：队列

系统除了用RPC建模，另一种就是队列了（彷佛全部的架构模式最后就是这两种作选择)。队列其实比RPC要复杂，也更难监控。须要生产方在生产完以后上报数据

1000897
topic1/partition1
producer=passport
queue

这个上报包含了三个信息：

• 1000897 是offset，表明了队列里的一条消息（id），也能够度量队列的长度

• topci1/partition1 表明了排队的主体

• 生产方名叫passport

• 隐藏的信息是 1000897 的生产时间

须要消费方在消费完成以后上报数据

1000677,error
topic1/partition1
consumer=profile
queue

这个上报包含了三个信息：

• 1000677 消费到了哪一个offset

• topci1/partition1 表明了排队的主体

• 消费方名叫profile

• 隐藏的信息是 1000677 被profile消费的时间

这样就能够统计出

• 每一个消费者本身的队列长度，好比profile还有多少消息须要消费

• 每一个消费者本身队列的消费时间分布，从入队列到消费完成。这个是利用了收到产生消息和收到消费消息的时间点。

• 每一个消费者的错误率

• 每一个生产者产生了多少消息

核心点

全部以上构想的功能若是有一点吸引力，那主要是由于上报数据的人懒。这也是statsd的核心思想，它作了复杂的事情（有状态），因此你能够变得简单。好比咱们能够在订单被接了以后上报的数据包含订单是何时发出来的，这样是简化了statsd，可是对于statsd的使用方来讲就必须记录和上报这个订单是什么发出来的。也许你会说业务原本就记录了这些，可是也许你上报的地方可能没有读数据库呢？也许就是懒呢？

咱们须要一个statsd，不可是有状态，还能够理解业务和系统模型。从而使得使用方能够很是简单，在每一个节点上无状态地上报当前阶段有的信息。让statsd本身去聚合这个时间片的指标，聚合关联流程上下游的指标，聚合关联同比和环比的指标。直接出图。直接告警。just works。