如何构建一个交易系统（十四）

最近一段时间流行一句话叫做蒙眼狂奔， 笔者不由自主的想到一个蒙上眼睛投刀子扎美女的表演。

美女别怕，我还没有蒙眼呢

蒙眼狂奔，其实没有什么问题， 估计现在道路宽阔，人人都可能给你让路， 但是一旦自己掉坑里，连回去的路恐怕都找不到， 是时间停下来， 仔细看看自己的仪表盘(Dashboard)，到哪了， 方向对不对，各项指标正常否？

飞机仪表盘

此篇主要讨论下系统监控相关的东西， 以及我们的IT系统里面的实践。

所有代码都写好，环境搭建好， 该接的都接了，就好像家装修好， 地板铺了，水电煤通了；就拎包入住了， 住了一个月确实不错; 系统运行了三个小时候有余了， 调用API 能通，订单能下， 数据库录入也都正常， 突然某天系统就嗝屁了！

监控可以根据不同的层来区分， 也可以根据时效比如有的需要实时， 而其他可能对实时性需求没有那么高。

1. 系统监控-基础设施层
   1. OS, 网络 etc
2. 服务监控-中间件层
   1. MQ, redis, Mysql，Nginx etc
3. 应用层
   1. 根据你业务模型来分
4. 其他等等

监控， 就是不停抽样系统的各项运行指标：

1. 确保都在监控可控范围内， 还需要
2. 完善的周边解决方案， 指标不正常后可以自动化走备案。
3. 训练有素的团队快速响应

这样才能有可能保证你的系统健康的运行下去 --- 一个系统完美正常的运行下去还有诸多其他的因素， 终极目标可能是一个自动化无人值守的系统 :-)

当我用现代化科技开拉面馆的时候

基础设施的监控

这部分的都有非常成熟的解决方案， 这里不再描述， 可以查询网上很多的解决方案， 比如 Zabbix, Nagios,Pandora 等等

三大开源运维监控工具zabbix、nagios和open-falcon优缺点详细比较

这套系统， 如果在云上， 一般都成套的工具帮你实现， 如果自己搭建，需要一个经验比较丰富的运维团队。

业务部分的监控

业务日记的扫描整理可以借鉴ELK 的解决方案。 这里更多注重关键网关上面的性能和效率监控。 监控信息的收集方式无外乎 : 主动push, 或被动的pull； 而收集的机制，一般都是在宿主机器上装相应的agent 汇聚、加工原始的信息到分析的机器上， 比如fileBeat、logstash 等。这样的做法对现有的应用侵入性少一点， 业务开发人员几乎可以无知这样的基础设施的存在。

我们这里采用还是在代码里面加上锚点， 这样可以达到更粒度的控制， 然后采用主动push 的方式，采用的技术栈：

1. Dropwizard Metrics 在API, gateway 采集指标， 比如Timer, Counter 等等
2. InfluxDB 存储时序数据
3. Grafana 展示

是不是很简单暴力， Dropwizard 采集指标， 这个比较简单，配合InfluxDB Reporter 将指标发送到InfluxDB, 大家可能觉得现在InfluxDB开源部分不在包含集群功能， 有点质疑， 其实你可以将不同模块的指标输送到多个 InfluxDB instance上面去， 在一个不是太复杂的系统， InfluxDB 还是够用的。

InfluxDB

InfluxDB 本身包含自己一套的，采集， 聚合和展示套件， 展示这一块我们使用 Grafana。 Grafana 支持从多种数据源导入展示数据， 简单容易上手。

Grafana 展示

这样一套系统，搭建起来，技术要求没有那么高， 成本也很有限， 使用维护的成本也低， 可谓物美价廉， 当然我们把一些其他的监控， 比如JVM 等也都放上去了。

报价系统监控

JVM 监控

GoXTX 下一代交易平台技术供应商
GoXTX one-stop solution for neXT generation eXchange

参考

1. Zabbix vs Nagios vs PandoraFMS: an in depth
2. 开源监控系统中 Zabbix 和 Nagios 哪个更好？
3. Open-Falcon
4. OpenTSDB监控系统的研究和介绍
5. Dropwizard Metrics
6. InfluxDB
7. Opentsdb
8. Grafana
9. Graphite的百万Metrics实践之路
10. 基于StatsD+Graphite的智能监控解决方案
11. 使用graphite来监控业务系统