程序猿当了快七年, 从多媒体开发入大数据的坑, 慢慢的发现了这块天地的美, 希望以后可以坚持分享一些心得.因为最近几个月在系统的运维监控方面做了大量的尝试和工作, 所以先聊聊这块. 这里需要感谢下祝威廉大牛分享的一些文章.
背景, 公司的其实是一个以音视频通信为核心技术的SAAS服务公司, 同时也有大量的自主研发设备, 配合各种行业定制方案, 可以说业务相当的复杂多变, 数据这块能做的事情也就相当的丰富.
进入主题, 因为运维这方面的业务资历并不多, 也不了解各大站是怎么做的, 所以这里更偏重技术, 讲的是将大数据处理的方式和思维应用到运维工作的一些实践.
1 运维的理解:
从内容分享的完整性考虑, 还是要说说基础的运维, 从实现方式上, 我理解传统的一般性做法:
1 服务器基础指标的监控, CPU, 内存, 磁盘等相关数据的监控和报警. 通常通过zabbix, nagios等集成实现, 这其实是服务器运行的基础, 重要不必多说. 但局限性很大, 基本上都是基于阈值或者很简单的逻辑触发原则.
2 在分析业务问题时, 通常还是通过各种复杂的shell分析日志, 每每看到一些能力很强的同事写出来一大串的awk, 一是佩服, 二是不解. 佩服是因为我写不了, 不解是在想, 如何解决分布式的数据分析和统计问题. 因为我理解大部分的业务异常都属于时间序列的数据分析分析问题, 并且需要高效的结合维度钻取, 指标聚合才能快速的定位.
3 第三方的监控平台, 之前研究过小米的open-falcon, 考虑是不是应该把监控报警, 历史查询等部分的功能集成过去, 不过并没有得以实施. 我想最主要的原因还是, 从发展的角度, 恐怕没有坚定的支持, 很难在创业初期就有魄力在这块投入过多的精力.
不过随着数据处理技术的普及, 我觉得所谓传统也在改变, 我们现在做的也会慢慢变为传统.
2 正题:
这边负责的监控, 其实就是由我设计的数据系统衍生出的一部分结构, 所以监控的主体也是业务及服务, 包括整体的微服务系统, 呼叫系统, 以及客户端数据业务. 上图, 本来想给运维监控这块单独画一个图, 但发现其实数据的处理使用思想完全和整个数据系统的设计是吻合的, 所以这里就直接上数据处理与服务框架了.
图中两条红线是目前监控的线路, 包含两个重要的部分:
一, 监控报警线路
负责业务数据的实时分析监控和报警, 提供多种模式的数据处理, 包括阈值, 频率, 变化率, 事件等等, 通知形式包括短信, 邮件. 可以方便的扩展到语音. 这条线的开发工作都集中在业务数据的处理, 主要是时间序列. 数据的收集使用logstash居多, 也有基于jenkins的任务调度的数据抽取.
二, Dashboard&分析线路
这条线路是为了报警之后, 分析问题用的, 主要由kibana提供, kibana是ELK套件中的一员, 和ES结合的很好, 支撑了我们数据检索, 和看板的功能, 而且最重要的是, 设计良好的看板可以实现维度的钻取, 而且可以通过一些关联字段可以把不同的index数据join倒一起分析.
2.1 Mongo & Elasticsearch
说一下数据存储的选择, 就运维相关的需求来说, 底层的存储是mongo和ES.
首先, Mongo的mapreduce可以灵活的处理数据, 结合python提供的各种快速处理数据的组件, 可以说快速支撑了我们前期的数据采集, 分析的需求. Mongo在某种程度上被赋予的角色类似于HDFS, 得益于比较好的数据采集规范定义, 我们大部分的数据都有比较一致的数据结构, 对后期的ETL, 分析等需求响应的非常快.
然后, ES是后期引入日志分析后才建立起来的, ES在我们这里的角色是时间序列数据库, OLAP分析仓库和搜索引擎, 当然每种角色对应的设计不尽相同. 对于监控运维而言, 基本上三个角色都占了. 在目前的监控体系里, ES的角色要更重.
ES是个很美的时间序列, 可以通过阈值, 频率, 变化率, 事件等等多种模式方便的分析, 基本涵盖了业务数据可以出现各种情况. 结合自己设计的一个自动报表生成和通知架构, 可以方便的添加监控通知 (SMS, MAIL)
OLAP分析的方面, 因为ES是kv存储的, 所以要求我们在分析之前需要对需要处理的维度提前处理好, 并且由于es不支持index的join查询, 这也要求我们在设计主题的时候要考虑清楚, 合理添加需要冗余字段. 关于展现的部分其实可以单独开奖, 比较过kibana和grafana, 虽说grafana画出来的图更有现代气息, 好看一些, 但是他并不支持数据的透视分析功能. 比如我想看出现503的服务集中在哪些内部服务, 哪些api, 哪些外部ip, 哪些设备, 在kibana只需要简单点击就可以. 这一点对于快速分析和定位问题很有意义. 下图是一个基本服务的监控看板.
ES的日志搜索功能, 这个其实不必多说, 因为他本身就是搜索引擎. 数据汇聚过来后, 对于分析分体很有帮助, 比如我们可以清楚的了解设备的网络质量, 媒体质量等, 这个信息不论对研发还是客服其实都很有意义的.
2.2 数据
对于监控相关的日志, 不仅仅是指log文件, 可以理解为对象行为的事件描述信息, 但通常会带有时间信息. 数据源可以有很多种, 可能是log, 消息数据, sql数据库历史表, 甚至是excel, 这些数据的收集和汇集其实是做数据的人的财富根源, 当让也是最耗时的部分.
其实这也是一个数据系统设计的根本, 其中日志的格式设计, 业务的跟踪系统设计是关键. 这种集中处理日志, 监控分析的架构其实就是数据思维的体现, 好的模型设计可以使很多系统问题不在依靠各种专家, 相关的人员都可以快速的定位和分析问题, 这也为后端开发减轻了不少压力.
需要的改进
目前监控这块的设计抽象的力度还是不够, 导致很多需求还是需要数据人员的干预, 业务人员还不能很方便的通过简单配置引入数据, 添加报警. 所以这个是改进的一个主要方向.
另外, 数据分析的接口, 理想的状态是希望提供类SQL的操作, 还没有做到完全统一, 一旦统一起来, 数据的表现形式, 和应用场景会更多, 可以不限于监控业务, 也可以包括系统的改进.