1、背景
我所负责实时支付项目，生产环境出现几次重大问题，比如，网络硬件设备故障、银联方面问题、消息队列异常、网络阻塞等问题。对于稳定运行运行两年系统，对它关注度会习惯性松懈，往往出现问题由客户反馈到IT，再安排技术人员排查。从这一年经验来看，等到客户反馈到我们这，生产已经挤压大量问题单，只能通过运维处理，后知后觉。这样状况给我们带来两方面的压力，一、客户不友好，不管问题是不是出在我们身上，只要整条线出了问题影响到业务流程，客户都认为服务不可用。二、运维压力，这样一个7×24h集群服务，每个人海有其他任务，不会时时盯着日志、db看看业务流程健康状况。一旦出现问题，带来身心压力是巨大的，费时费力修复线上问题。
从几次深刻教训中，我们心里知道缺少有效手段管控生产应用，实时监控线上业务情况。对于影响正常业务的不确定性因素，希望做到先知先觉，或者实时反馈给技术人员，即使出现问题，我们能提供有效方式补偿回来，而且尽量由程序做这个工作，减少人运维参与。由此，我们的监控插件应运而生。
2、架构简介
经过反复论证，监控应定位现有业务零侵入，并扮演watcher角色。我司田老师提出字节码插桩也是极好的方式（在加载类之前修改类文件，加入日志监控逻辑），
最终选择开源框架ELK，自写监控逻辑。ELK帮助我们收集、存储日志。
2.1、ELK
由Elasticsearch、Logstash和Kibana三部分组件组成；
Elasticsearch是个开源分布式搜索引擎，它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。
Logstash是一个完全开源的工具，它可以对你的日志进行收集、分析，并将其存储供以后使用
kibana 是一个开源和免费的工具，它可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面，可以帮助您汇总、分析和搜索重要数据日志。
参考资料：
logstas部署:
Shipper：日志收集者。负责监控本地日志文件的变化，及时把日志文件的最新内容收集起来，输出到Redis暂存。
Indexer：日志存储者。负责从Redis接收日志，写入到本地文件。
Broker：日志Hub，用来连接多个Shipper和多个Indexer
ELK部署：
上述架构利用redis订阅者模式扛压、解耦，也见过用消息队列kafka，异曲同工用意一样。
2.2、日志格式化
elk能够帮助我们监控日志文件每行输出，并输出到elasticsearch中，完成落地。elasticsearch基于lucene搜索服务器，搜索时效性高。
这里需要我们定制业务日志输出格式，便于解析与存储，logstash支持预定日志格式转化成键值对json数据格式。
例如我们支付业务格式：|时间|监控类型|日志等级|耗时（ms）|订单号|流水号|业务渠道|结果码|结果信息|银联|银行|账号|姓名|金额|
3、监控控件
3.1、策略介绍
我们希望搭建一个全链路监控，涵盖基础设施、插件、web容器、负载、业务、性能等，主要有以下四类；
一、基础设施，包括cpu、mem、net、df、io等指标
二、服务器，包括web容器、各插件、各附属服务（运维平台、数据报表服务等）、nginx等存活性
三、业务，模拟用户做黑盒测试，整个业务线跑下来预定结果和测试结果对比。http服务可发送head请求，根据http status判断服务有效性、可用性等，排除应用僵死状态。
四、性能，从流量、UV、容量、平响等指标，例：从监控nginx日志，检测流量、平响
以上指标，根据生产应用设定阈值，检测同环比、突升/突降情况
3.2、组成模块
监控组件主要分为三个模块，各模块之间通过redis订阅者模式解耦、异步化，并同一数据交互格式；
一、采集模块，后台批处理采集lucene日志内容，并作格式化数据
二、计算模块，对数据处理，计算检测指标阈值，同环比、突升/突降等
三、告知模块，通知用户，微信公众号/短信/邮件等，对于用户参数可配置化处理，制定通知策略（避免短信炸弹）
微信企业号我们目前首选方案，
