> For the complete documentation index, see [llms.txt](https://zhangguanzhang.gitbook.io/prometheus-up-running/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://zhangguanzhang.gitbook.io/prometheus-up-running/part-i-introduction/what-is-prometheus/what-is-monitoring-1/a-brief-and-incomplete-history-of-monitoring.md).

# A Brief and Incomplete History of Monitoring

        近几年包括prometheus，监控都在向工具转变。但主要的解决方案仍然是Nagios和Graphite或其他一些工具的某种组合\
        Nagios主要通过定期执行称为检查的脚本来工作，如果返回非零退出码则认为检查失败，生成警报。 Nagios最初由Ethan Galstad于1996年创建，作为用于执行ping的MS-DOS应用程序。 它于1999年首次作为NetSaint发布，并于2002年更名为Nagios。\
        谈到Graphite的历史，Tobias Oetiker在1995年创建了一个Perl脚本，该脚本成为Multi Router Traffic Grapher(MRTG 1.0)。如名称所示，它主要用于通过简单网络管理协议（SNMP）来监控网络 。 它还可以通过执行脚本来获得指标。1997年，随着一些代码移动到C，以及用于存储度量数据的循环数据库（RRD）的创建，1997年带来了很大的变化。 这带来了显着的性能改进，RRD是其他工具（包括Smokeping和Graphite）的基础。\
        Graphite始于2006年，使用Whisper进行度量存储，具有类似的功能 设计到RRD。 Graphite本身不收集数据，而是通过集合发送。诸如collectd和Statsd之类的工具，则分别于2005年和2010年创建。\
        这里的关键点是图形和警报曾经是不同工具执行的完全独立的问题。 您可以编写一个检查脚本来评估Graphite中的查询并在此基础上生成警报，但大多数检查往往处于意外状态，例如进程未运行。\
        这个时代的另一个障碍就是如何管理计算机服务。 服务部署在单独的机器上，并由运维负责。 专门的工程师会跳过可能表明存在问题的警报。 随着云和云原生技术如EC2，Docker和Kubernetes的出现，对待每个机器和服务，每个都需要独特的去关注，不能扩展。 相反，他们应该更多地被视为集群，并作为一个群体进行管理和监督。 就像行业从做管理一样，对于像Chef和Ansible这样的工具，现在开始使用像Kubernetes这样的技术，监控还需要从单个机器上的各个流程的检查到基于整个服务健康状况的监控。\
        您可能已经注意到我没有提到日志记录。 历史上已经在监控日志，例如你手工使用tail，grep和awk。 你可能有过 AWStats等分析工具每小时或每天生成一次报告。 在最近 多年来，它们也被用作监测的重要组成部分，例如 Elasticsearch，Logstash和Kibana（ELK）组合。\
        现在我们已经看了一下图形和警报，让我们看看指标和日志如何适应事物。 是否有比这两种更多的监测类别？