---
title: 立体监控
canonical: "https://xiaofeng.dev/en/writing/three-dimensional-monitoring/"
pubDate: 2016-10-15
author: 唐小锋 Xiaofeng TANG
description: 按照一般的实践，对于需要724小时运作的在线系统，光靠开发人员小心谨慎是完全不够的，势必引入一些监控工具，每次监控的失败报警都可以作为一种反馈机制，增强系统的可用性。再进一步会发现，监控的意义可以远不止于此。 什么是“立体”？ 监控的目的：
tags: [Observability, Operations]
---

![图片](/writing/wechat-tech-assets/three-dimensional-monitoring/27e2f604643455c3.jpg)

按照一般的实践，对于需要7*24小时运作的在线系统，光靠开发人员小心谨慎是完全不够的，势必引入一些监控工具，每次监控的失败报警都可以作为一种反馈机制，增强系统的可用性。再进一步会发现，监控的意义可以远不止于此。

什么是“立体”？

监控的目的：

7*24可用性、收集性能数据、收集bug数据、检测异常事件

监控的对象：

服务器、组件、接口调用、配置、业务统计数据等

监控的深度：

http code、负载高低、响应速度、分支逻辑正确性

把以上混合在一起，就有了“立体监控“的说法：“立体”就是指不限目的、不限对象、不限深度地实施多维度监控：外部监控，内部监控，用户视角，服务器视角，组件视角，多网络多地域，多终端，技术监控，运营监控，风险监控等等。我不准备给出一个精确的定义，仅稍加描述，希望扩宽下思路，以实用为主。

**服务器基础监控：**

服务器的几项基本指标：CPU、内存、IO、流量、负载等。

**外部域名监控：**

从全国各地网络监测点对域名的http和https站点实施监控，如果有DNS解析失败、或者任何不正确的http code返回码，都会立即报警。考虑到中国的网络环境，各大运营商（长城宽带、铁通、电信通、移动、联通、电信）都需要设有监控点，有国外的就更好了。（例如阿里云监控、监控宝、pingdom等）

**内部组件监控：**

坚持“所有组件必须监控”的原则，从nginx、memcached、redis、rabbitmq、uwsgi到各种自定义的crontab、daemon程序等等，都需要有状态监控、进程负载监控，如果有必要，还可以做到自动重启。（例如VeryNginx、Supervisior）

**500监控：**

500错误收集工具可以将在代码内部发生的500错误和调用栈保存下来，方便后续的bug重现和修复。（例如Sentry，最早支持Django，现在可以支撑多种语言）

**404监控：**

浏览器中大量出现的图片404会显著降低用户端性能；404也有可能是某个关键文档和调用路径出现了bug。

**CDN/静态资源监控：**

虽然现在的CDN很成熟，但仍然需要关注CDN的流量、命中率、回源策略等统计监控指标。

**外部依赖监控：**

比如某个关键逻辑依赖于某个外部api接口。一旦它的逻辑出现问题或者性能出现严重波动，都会影响到服务的可用性，这时就需要对它监控起来。

**接口调用监控（上报）：**

可用性监控通常不能满足对性能有苛刻要求对场景。于是需要在调用端代码中植入上报代码，每次调用都将执行时间上报给监控服务，确保一旦性能有下滑，技术人员能够立即得到通知，并联系接口提供方调整。

**用户访问监控：**

用户访问行为是运营人员和产品经理都非常感兴趣的数据，可以借助前端埋点和后端日志来发现一些用户行为特征。（例如cnzz，growthio，verynginx统计监控）

**业务逻辑监控：**

对于某些关键逻辑，需要通过一定深度地操作步骤（比如登录、选择、下单、付款）才能到达，也可以自己撰写监控逻辑脚本来实现。

**业务数据监控：**

库存告警、订单延迟发货告警、每日订单交易量监控、余额告警

监控系统的其他要素

具备aggregation功能：不会因为一时故障，狂发几百条告警信息

丰富、及时的通知方式：邮件、SMS、电话等

“谁应该收到告警”的可能人选：测试人员、技术人员、运维、业务方

“谁来录入监控规则”的可能人选：测试人员、技术人员、运维