按照一般的实践，对于需要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、电话等
“谁应该收到告警”的可能人选：测试人员、技术人员、运维、业务方
“谁来录入监控规则”的可能人选：测试人员、技术人员、运维