作为合格的研发人员，自己的服务一旦上线后，我们就要思考这样的问题：服务运行是否正常，服务器的负载多少，并发情况怎会样（TPS, QPS），怎么快速发现和定位故障，结合苏宁视频业务场景，今天主要讨论PP云服务的监控实践。
作者：梁杰生。PP云高级技术经理，拥有7年业务研发和架构经验，目前负责PP云视频服务研发和架构工作。
1. 为什么需要监控
视频相关的服务有以下几个特点：
1）视频业务链路长，服务多样性
2）服务分布部署，形成机器集群
3）线上故障需要及时发现，及时处理
一个典型的业务场景：
1）用户反馈到客服，视频无法播放
2）客服 -》产品 -》测试 -》技术
3）技术：客户端层 -》反向代理层 -》站点层 -》服务层 -》数据层 ...
4）2个小时过去了，用户说Goodbye
在这个场景中，出了问题技术是最后的知晓者，查找问题链路长，用户受影响周期长，最终的结果就是用户的流失。
作为合格的研发人员，自己的服务一旦上线后，我们就要思考这样的问题：服务运行是否正常，服务器的负载多少，并发情况怎会样（TPS, QPS），怎么快速发现和定位故障。由此看来，应当把监控作为产品周期内重要组成部分，实时反馈服务的当前状态，保障业务持续稳定运行。
2. 监控工具
工欲善其事，必先利其器。我们常用的监控工具如下：
1） zabbix
zabbix是一个分布式监控系统，zabbix-agent 负责收集数据并格式化，zabbix-server接收数据，并存储到mysql，通过在zabbix web管理界面上进行一系列的配置，即可看到直观的数据展示图，并且可以通过触发器配置报警阈值。
2）ELK
ELK是一个日志分析系统，ELK = ElasticSearch + Logstash +Kibana，Logstash负责日志的过滤、收集，Elasticsearch负责数据的存储和搜索，Kibana负责数据的可视化。
3）Grafana
Grafana是一个开源的时序性统计和监控平台，支持多种数据源zabbix, Elasticsearch, InfluxDB, MySQL等，根据Graph设置条件告报警，同时支持Webhook，DingDing，HTTP API等多种方式。
3. 监控指标
了解了监控的重要性和一些监控工具，我们就需要根据服务的特点制定一些监控指标，PP云的服务重点做了四方面的监控。
1）系统监控
监控起系统资源的使用情况：网卡流量是否跑满，磁盘是否有空间，CPU是否繁忙，内存是否用完，负载值是否过高等。可以使用Zabbix完成这部分的监控。
cpu负载
内存
磁盘
网卡
2）应用监控
Nginx、PHP、Memcached、Redis、MySQL、Rabbitmq等重要的应用，一旦挂掉或者出现异常，就会造成服务的不可用。这部分同样可以用Zabbix监控起来。
redis命中率
3）日志监控
苏宁线上视频服务每天会产生大量的日志，这些日志包括系统日志，应用程序的访问日志、运行日志、错误日志等，日志是我们定位线上问题的依据。通常当线上服务产生故障，技术需要登录到各服务器上，用 grep / sed /awk 等 Linux 脚本工具去日志里查找原因，这样操作的效率可想而知。如果把这些日志收集并集中存储，并可以按过滤条件快速检索，这就可以大大提升效率。ELK技术栈可以完成这个工作。
Kibana展示结果
典型的elk架构如下：
这种架构在我们使用过程中，发现两个问题：
1）占用应用服务器资源：Logstash和应用服务器同部署，Logstash的收集过滤会给服务器带来消耗。
2）数据会失：高发情况下，由于日志传输峰值大，如果没有消息队列来做缓冲，会导致Elasticsearch 集群丢失数据。
引入消息队列后架构如下：
这样当遇到Logstash接收数据的能力超过Elasticsearch集群处理能力的时候，就可以通过队列就能起到削峰填谷的作用，就不存在丢失数据的问题。
4）业务监控
zabbix，elk一般由运维体系维护和管理，适用于全平台的服务。而业务监控需要较强的定制性，一般由技术和产品商定。这种定制需要方便的添加和修改，更精细化，报警方式多样性。譬如直播流的码率、帧率监控。为此我们搭建了Grafana，将zabbix和elk的数据整合，来做我们业务级别的监控。
直播流监控
4. 监控报警
告警的有多种方式，一般使用邮件，短信和内部im通知。Grafana已经将数据整合，并提供Alert模块，可以很方便设置条件告警邮件通知组，同时用webhook方式自定义告警方式。
接口负载高监控
5. 总结
选择开源的工具搭建监控系统，比较省时省力。但监控还是需要站在公司业务角度上，针对性的选择监控技术。