在实践中，所有这些概念/术语，目标都是增强工程师对于线上系统运行情况的了解。
对工程师而言，监控/可观测性工程存在的意义，是帮助工程师发现问题，定位问题，解决问题。
对系统自身而言，这些工作都是通过数据的采集/存储/分析，以及进一步迭代来完成。
一、监控需求的产生
当程序被交付，部署到生产环境，才是其生命周期中最长的部分的开始。人们需要了解生产环境是否一切正常，监控需求自然而然产生。
互联网发展过程中涌现大量监控相关的工具/系统，Ganlia, Zabbix, RRDTools, Graphite，各自在不同的层面为“是否正常”提供答案。
监控本身，无论是业界对监控的认知，监控工具/系统自身的能力，也在以下两个方向演进着：
黑盒到白盒
资源到业务
这个阶段监控的愿景是很明确的，如何落地则各显神通。
直到 Etsy 于 2011 年通过博客公开了他们的 监控实践，利用 StatsD（已开源），以非常简单统一的方式，实现资源/业务层面的数据采集/存储/分析。后来的监控系统，尤其是基于 metrics 的监控系统，大多受过 StatsD 的启发和影响。
二、可观测性的提出
互联网工程界，Twitter 应该是最早提出可观测性 的组织。在这系列文章中，Twitter 集中阐述了他们的可观测性技术栈，其中包括了 Zipkin，Google Dapper 的开源实现。
如前言所说，本文不纠结于几个名词之间的包含关系。
抛开这些名词的辩论，可观测性相对于过去监控，最大的变化就是系统需要处理的数据，从 metrics 为主，扩展到了更广的领域。综合起来，大约有几类数据被看作是可观测性的支柱(pillar)
metrics
logging
tracing
events
因此，一个现代化的监控系统/可观测性工程系统，也就必须具备妥善存储以上几种数据的能力。
