基于形变分析模型的异常检测系统建设与实践
写在前面
外卖业务持续高速成长，业务迭代快，逻辑复杂，关联服务多。如何快速准确识别系统各项指标的异常，发现问题根因，并快速解决显得尤为重要。在常规业务指标监控工作中需要手动维护上万业务指标报警阈值，不仅成本高，效果也不佳。我们尝试使用“形变分析模型”对业务指标自动进行异常检测，无需人工设置阈值。在实践过程中与外卖全链路压测，服务保护等稳定性保障系统进行内联，目前已覆盖绝大部分美团外卖C端核心业务指标，效果不错。
异常检测学习笔记-STL（一）
写在前面
最近在做业务指标异常检测与服务故障诊断，参考了腾讯、阿里等互联网大厂的解决方案，觉得有必要整理一下。我们生长于外卖业务，并不是专门做系统运维的团队，也是希望先从外卖业务特点进行分析。外卖业务并不会出现像双十一购物网站那样的流量暴增，它呈现出很强的季节性（一段时间内的周期性变化，外卖业务正常是7天一个周期）、趋势性（时间序列数据总体变化情况，是一直下降还是一直上升）。之前只是简单的使用Holt-winter算法对业务监控指标进行预测，基于预测值与真实值的比较，识别异常数据点，但是我们呈现出季节性的时间序列数据中还存在季节成分，有时也会因为天气等外力因素使时间序列数据存在比较明显的随机与误差成分，需要根据实际情况实时调整异常识别参数。STL方法给我们提供了一个思路，本文主要针对STL进行简单的总结，希望内容通俗易懂。
常用算法学习笔记
写在前面
上学时的数学课会介绍很多定理、公式，但是少有介绍在日常生活中运用的案例。任何一个设计模式、算法都应该是从生活中来，又可以回到生活中去。最近一直在做异常检测与故障诊断相关的事情，越来越觉得算法的重要性，这里记录一下，最近学习的一些常用算法与应用场景。尽量描述的短小、通俗。
2017-11-26 给糖果的一封信
亲爱的糖果：
这是爸爸第一次给你们写信，心里非常高兴。从出生给你们起大名、小名开始，希望名字上口、不包含宏大的含义，希望你们可以一直做一个健康平凡的人。爸爸对你们的要求只有一个：做什么事情都要以不伤害自己、不伤害影响别人为前提，在这个原则下爸爸不会限制你们、要求你们，这也是爸爸和妈妈在你们出生之前就达成一致的事情。
美团外卖自动化业务运维系统建设
写在前面
美团外卖作为O2O领域领先的电商平台, 到现在具有业务流程复杂, 业务增长迅猛等特点。在对业务系统稳定性与时效性都有较高要求的前提下，单纯靠人工排查解决问题，存在较多的局限性。下面给大家主要介绍一下从外卖业务自身特点出发，围绕业务展开问题发现，根因分析，问题解决等自动化运维体系建设历程与相关设计原则。
统计学作业-Stroop(未完)
背景
在一个 Stroop （斯特鲁普）任务中，参与者得到了一列文字，每个文字都用一种油墨颜色展示。参与者的任务是将文字的打印颜色大声说出来。这项任务有两个条件：一致文字条件，和不一致文字条件。在一致文字条件中，显示的文字是与它们的打印颜色匹配的颜色词，如“红色”、“蓝色”。在不一致文字条件中，显示的文字是与它们的打印颜色不匹配的颜色词，如“紫色”、“橙色”。在每个情况中，我们将计量说出同等大小的列表中的墨色名称的时间。每位参与者必须全部完成并记录每种条件下使用的时间。
2017-03-21 阴天
最近在知乎上查了一些和机器学习相关的资料, 最后决定在udacity付费挑选了机器学习入门课程. 也是由于最近工作的原因, 苦于没有很好的数据分析思路. 在选择udacity课程之前, 比对了国内的小象学院, 九章等网络授课平台, 基于各种评价, 还是觉得udacity课程更靠谱一些, 具体有多靠谱, 还需要我自己去亲身体验一下. 这个世界是残酷的, 自己已经处在被淘汰的边缘, 如果不对自己的知识结构持续更新, 太容易就失去了追赶的能力, 而对自己知识结构进行更新的快捷方式之一就是站着别人的肩膀上付费学习. 我在udacity的优惠码:
|
|
使用该优惠码可以使你减免300块钱学费, 同时,我也会得到300块钱的优惠劵. 既然花钱了, 持续投入时间了, 我打算将在udacity学习的过程记录下来, 以备之后的巩固复习.
DIGGER业务监控
写在前面
目前看到业界介绍贴近业务监控的整理还比较少, 更多的是一些对系统层级的监控, 所以把自己针对业务监控的一些思路整理记录在这, 以便后续翻阅修正.
业务监控, 主要侧重对业务状态数据的实时监控, 收集数据后对业务数据进行深入的统计分析, 帮助业务方发现问题, 定位问题根源. 这其中数据分为: 业务自身输出的业务日志(比如: 提单, 推单, 接单等状态数据), 业务异常, 报警事件等.
发现问题原因之后我们需要解决问题, 最终目的是可以基于我们分析的结果给运维动作做出决策, 以达到自动化运维的目的. 另外, 明确系统用户将有助于把控业务监控产品的设计方向, 业务监控系统的第一用户是RD, 不是老板, 我们是要帮助RD更快的发现问题, 预知问题, 提供标准化解决问题的建议.
通过Packetbeat抓取Finagle协议数据包(自定义Thrift协议)总结
写在前面
最近一年多一直在做服务治理相关的开发工作. 起初服务监控采用了成本比较低的方式来实现(提供者,消费者自己按分钟维度上报健康数据到Redis,但是这种方式只是在Java的服务提供者和消费者做到了很好的实现, 其他语言目前只能上报很少部分的监控数据). 因为公司的开发语言是多样的, 其中包括: Nodejs, Ruby, Golang, Java, Scala等, 那么将来要对监控数据的模型拓展, 需求变更等, 将很难快速推广实现. 随着公司业务的高速发展, 以及将来所有服务部署Docker化, 服务的监控预警已经是服务治理工作中的重中之重. 服务监控最好可以同时监控基础服务(Mysql, Redis等),业务服务. 我们的业务服务是采用的Twitter的Finagle-thrift实现多语言之间的RPC调用. Balabala说了这么多, 就是我们现在要做全链路监控, 做监控首先第一步是需要可以收集到这些网络调用的原始数据, 这个时候ElasticStack中的Beats项目进入了我们的视线, Beats项目中的Packetbeat子项目可以抓取到像Mysql, Redis, Thrift等协议的数据包. 但是,我们业务使用的通信协议是Finagle-thrift, 这里面为了满足一些拓展(比如:用于RPC调用链跟踪的Zipkin),Finagle-thrift在原生Thrift上做了二次封装, 接下来需要让Packetbeat对Finagle-thrift协议支持. 下面我将分析过程整理如下, 方便以后温习回顾.
基于Zipkin的Thrift服务RPC调用链跟踪
概述
我们现在所处的生产环境是一个集Nodejs, Go, Java, Ruby, Scala等多种语言程序的混合场景.Twitter的Finagle框架, 是一个基于Thrift协议的RPC框架,其中Zipkin是针对Finagle框架的一个基于Thrift协议的RPC调用链跟踪的工具，可搜集各服务调用数据，并提供分析查询展示功能。帮助识别分布式RPC调用链里，哪一个调用比较耗时，性能有问题，以及是否有异常等，使得诊断分布式系统性能成为可能。
