第 1 章 引言

第 1 章 引言

让我们从Example公司的故事讲起。Example以前有一个系统管理员,她负责管理数据中心的基础设施。每当数据中心增加新的主机时,她都要相应地安装监控代理并设置一些监控埋点。时不时就会有主机崩溃,触发一个监控埋点,并向她发送通知。于是,她就要从睡梦中爬起来去运行rm - fr /var/log/*.log来解决问题。

多年来,这种方法一直很有效。当然并非完美,偶尔也会出现一些问题,比如没有触发埋点,没有及时发通知,或者主机上的一些应用程序和服务根本就没有受到监控。但总体上来说,监控还是很有效的。

信息技术行业逐渐开始改变,引入了虚拟化和云计算,需要监控的主机增加了一个甚至几个数量级。其中一些主机由非专业系统管理员来管理,一些主机甚至外包给第三方管理。数据中心的一些主机被迁移到了云上,甚至被“软件即服务”(Software as a Service,SaaS)应用程序所取代。

最重要的是,信息技术(information technology,IT)成为了企业与客户沟通以及销售的核心渠道。以前只被视为纯技术的应用程序和服务,现在对客户满意度和提供高质量的客户服务来说至关重要。IT不再只是成本中心,更是公司的收入来源。

因此,监控的各个方面都开始出现问题。跟踪主机变得更困难(主机数量大大增多),应用程序和基础设施变得更加复杂,对可用性和质量的期望变得更高。

用现有的系统检查所有可能出现问题的地方变得越来越困难。告警通知堆积如山,更多的主机和服务意味着对监控系统的要求更高,大多数监控系统只能通过添加更大、更强的主机来进行扩展,但很难扩展为分布式系统。在这样的负载下,检测和定位故障和业务中断的速度越来越慢,难度也越来越大。

组织开始要求用更多的数据来证明他们正在向客户提供高质量的服务,并证明增加IT服务支出的合理性。这些需求中,有许多数据是现有监控系统无法测量或者无法生成的。由于这些需求,系统管理员的监控系统变得越来越复杂和混乱。

对许多从业者来说,这就是监控系统的现状,显然不尽如人意。它不应该如此,你可以构建更好的方案来解决当前的问题和应对未来的变化。

1.1 内容概览

本书使用最新的工具和技术,为构建可扩展的现代监控框架提供实用指南。书中将从头开始构建监控框架,为开发人员和系统管理员提供最佳实践。开发人员可以了解如何更好地使用监控和指标,系统管理员可以掌握如何利用指标更好地进行故障检测,并深入了解性能。另外,虚拟化、容器化和云引入了动态基础设施,使IT环境发生变化,书中将对此提出解决方案。本书旨在提供一个监控框架,帮助你和你的客户更好地管理IT基础设施。

在进入正题之前,有必要讨论监控的定义、监控存在的意义,以及每个监控领域中存在的一些挑战。然后,我们将讨论本书的主要内容、阅读过程中将会收获的技能,以及如何改变理解和实现监控的方式。

1.2 监控的定义

从技术的角度来看,监控是度量和管理IT系统的工具和过程,但实际上监控远不止这些。监控可以在业务价值与系统或应用程序产生的指标之间提供转换,监控系统将这些指标转换为可度量的用户体验。可度量的用户体验为业务提供反馈,帮助确保其交付客户想要的内容。用户体验还会向IT部门提供反馈,指出失误和不足。因此,监控系统有两类客户。

  • 业务客户
  • IT客户

1.2.1 业务客户

监控系统的首要客户是业务部门。监控系统的存在就是支撑业务,确保业务持续运行,其提供的用户体验数据,可以帮助企业更好地进行产品开发和技术投资。另外,监控还有助于业务度量技术交付的价值。

1.2.2 IT客户

IT客户就是指你、你的团队以及管理和维护技术环境的人。借助监控,可以了解技术环境的状态。同时,大量的监控能够检测、诊断和帮助解决技术环境中的故障和其他问题。监控提供了许多数据,帮助你做出关键的产品决策和技术决策,并度量这些项目是否成功。它是产品管理生命周期的关键组成部分,也是你与内部客户关系的重要一环,它有助于证明企业的投入落到实处。没有监控,工作价值无从谈起。

1.3 监控的实际存在形式

我们设想的这种监控与现实中大多数监控系统的实际情况相吻合吗?那得看情况。不同组织中的监控系统发展变化非常大,正如William Gibson所说:未来并不是均匀分布的。为了探究这个问题,我们创建了一个三层成熟度模型,它反映了不同组织的监控系统演进的各个阶段。

  • 手动、用户发起或无监控阶段
  • 被动式监控阶段
  • 主动式监控阶段

这个模型并不完美。关于阶段的定义很宽泛,组织可能发现他们处于这些阶段之间的某处。此外,这种成熟度难以度量,并不是所有组织都以线性或全盘的方式进行这种演化。这可能是因为不同阶段的员工的技能水平和经验参差不齐,也可能是因为组织的不同部门、业务单元以及职能划分具有不同的成熟度级别,或者两者兼而有之。

1.3.1 手动、用户发起或无监控阶段

这个阶段的监控在很大程度上是手动执行的,或是由用户发起的,抑或根本没有监控。如果需要执行监控,则往往通过检查列表、简单的脚本和其他非自动化流程对其进行管理。监控往往变成了事后行为,只监控已经出故障的组件。往往通过生搬硬套,重复执行“之前就这么干”的步骤来修复这些组件中的故障。

这个阶段的重点是缩短停机时间和管理资产。以这种方式进行监控在度量质量或服务方面提供的价值很少(甚至没有),并且只能提供少量(甚至不能提供)数据来帮助IT部门证明预算、成本或新项目的合理性。

这种情况在小型组织中较为常见,这类组织的IT人员有限,或者没有专业的IT人员,甚至由非IT人员(如财务团队)履行和管理IT职能。

1.3.2 被动式监控阶段

被动式监控大多是自动的,但还残留一些手动的或无监控的组件。这个阶段已经部署了各种复杂的工具来执行监控,通常会看到像Nagios这样的工具对硬盘、CPU和内存的基本问题进行余量检查。它可以采集一些性能数据,大多基于简单的阈值,并通过电子邮件或消息服务发送告警提示。可能有一个或多个集中的控制台显示监控状态。

人们广泛关注如何度量可用性和管理IT资产。可能会有使用监控数据来度量客户体验的趋势。监控系统提供数据来度量质量或服务,也提供数据来帮助IT部门证明预算、成本或新项目的合理性。在使用这些数据之前,需要对其中的大部分进行加工或转换,有一些提供了可供操作的数据看板。

被动式监控在中小型企业中很普遍,在大型企业的IT部门中也很常见。通常,被动式监控由运维团队构建和部署。你经常会发现大量的通知积压、陈旧的埋点配置和架构,对监控系统的更新往往是被动地响应事故和中断,添加监控埋点通常是应用程序或基础设施部署中的最后一步。

1.3.3 主动式监控阶段

在主动式监控阶段中,监控通常被认为是管理基础设施和业务的核心。监控是自动的,由配置管理工具生成。你会看到Nagios、Sensu、Graphite等工具,以及广泛使用的度量标准。埋点将更加趋向于以应用程序为中心,验证多数应用程序变为开发工作的一部分。埋点还更侧重于度量应用程序性能和业务结果,而不仅仅是硬盘和CPU之类的余量问题。性能数据被频繁地收集并用于分析和解决故障,告警会标注上下文信息,可能会自动扩大告警范围和自动响应。

关注的重点是衡量服务质量和客户体验。监控提供了度量质量或服务的数据,并提供了帮助IT部门证明预算、成本或新项目合理性的数据。大部分数据通过数据看板和报告直接提供给业务部门、应用程序团队和其他相关方。

主动式监控在以Web为中心的组织和许多成熟的创业公司中较为常见,采用DevOps文化和方法论的组织通常也使用这种方法。监控在很大程度上仍将由运维团队管理,但监控新应用程序和服务的责任可能会交给应用程序开发人员。一个产品如果没有监控,将被认为是不完整的,还不能部署。

1.4 模型分布

基于对监控的广泛研究,我们总结出了监控成熟度模型的分布,如图1-1所示。

图1-1 监控成熟度模型分布

可以看到,绝大多数环境处于被动式监控阶段,这对大多数工程师来说并不奇怪。被动式监控成熟度相对容易实现,并且可以满足大多数基本的监控需求。

如前所述,模型和所谓的分布都不是完美的。但是,即使考虑到潜在分布的广泛性,在处于被动式监控阶段的组织中,我们也可以针对其监控系统的实现进行一些架构上的假设。

图1-2展示了在处于被动式监控阶段的组织中常见的经典监控配置。

图1-2 传统的监控配置

一个Nagios实例对主机和服务进行检查,在某处出现异常时发送短信或电子邮件通知,并作为与通知交互的主要数据看板。借助开源工具和商业工具,这个基本配置可以有许多变体,但它仍然是处于被动式监控阶段的组织常用的基本配置。

从根本上来说,这个基本配置是有缺陷的。我们之前讨论了监控的两个客户:业务和IT。然而,被动式监控环境根本不能为前者服务,也几乎不为后者服务。

1.5 实施主动式监控

被动式监控环境生成以基础设施为中心的监控输出:主机停机,服务中断。因为并没有生成以业务或应用程序为中心的输出,所以就不能依赖监控为业务决策提供有用信息。当然,也不能使用监控数据证明用来改进或更新基础设施的预算是合理的。更重要的是,不能使用监控数据证明对团队进行投资是有价值的。

由于被动式监控环境以基础设施为中心,因此它只服务于部分技术客户(一般指运维团队),不能向开发人员提供有用的、以应用程序为中心的数据。结果,非运维人员不了解受监控的基础设施和应用程序的实际性能和可用性。开发人员通常只能收到二手信息,这削弱了他们对消除问题和故障的责任感。

注意:需要指出的是,这里对被动式监控模型的批判不涉及工具和技术的选择。我并不是要对工具或工具链吹毛求疵,而纯粹是为了帮助你满足客户的需求,方便开展工作。

如何将典型的被动式监控环境转变成更容易接受的主动式监控环境呢?利用指标。升级被动式监控环境,以关注事件、指标、日志。用事件和以指标驱动的检查替换许多现有的监控基础设施,例如服务和以主机为中心的检查。

在我们的监控框架中,事件、指标、日志将成为解决方案的核心。组成事件、指标、日志的数据点将为以下方面提供可信赖的数据源。

  • 环境的状况
  • 环境的性能

因此,我们既不会对主机执行ping操作来检查其可用性,也不会通过监控进程来确认服务还在运行。相反,我们将用指标替代大多数以基础设施为中心的故障检查。

如果一个指标正在测量中,说明服务是可用的。如果它停止测量,则很可能说明该服务不可用。

将事件、指标、日志可视化还有助于直观地表达和理解复杂的想法,免去了长篇大论或大费口舌的解释。

第2章将详细介绍监控框架,包括设计方案,以及工具和技术的选择。

为了阐明这个框架,我虚构了Example公司,以说明如何在实际中运用它。接下来快速了解一下Example,该公司有3个主要站点。

  • 生产环境A
  • 生产环境B(DRP)
  • 任务控制环境

每个站点的地理位置彼此分离。我们将关注生产环境A中的应用程序,但同时会展示如何跨站点构建尽可能有弹性的应用程序。Example还有一个DRP站点(生产环境B),以及一个包含管理基础设施(包括控制台和数据看板)的任务控制环境。相应地,我将演示如何将这些站点连接到监控框架中。

Example也有测试环境。在现实世界中,我们也会在测试环境中重复监控。这有助于定位回归问题和性能问题,并且在构建应用程序和服务时,有助于确保监控是高优先级的需求。

Example主要是Linux环境,运行最新版本的Red Hat Enterprise Linux和Ubuntu,并运行大量面向客户的内部应用程序和外部应用程序。几乎所有应用程序都基于Web,所用技术包括以下几项。

  • 基于Java和JVM的应用程序
  • Ruby on Rails
  • LAMP技术栈的应用程序

它们的数据库技术栈包含MySQL/MariaDB、PostgreSQL、Redis。

大部分环境使用配置管理工具进行管理,每个环境都有用于监控的Nagios服务器。

最近,Example开始尝试使用Docker等工具,并且使用GitHub、PagerDuty等SaaS产品。

这种环境提供了具有代表性的技术样例,它适用于其他多种环境和技术栈。

1.6 本书内容

在本书中,你将了解如何构建监控框架。第2章将描述该框架,之后的各章将逐步构建它,并最终使用该框架监控基础设施、服务、应用程序。

本书并不是所有技术栈的监控圣经,理解这一点很重要。书中确实会使用许多涵盖广泛技术的示例应用程序来展示如何监控不同的组件,但是,本书并没有详细列出每个技术栈应有的监控项目。每个环境和应用程序的开发、构建、编码都是不同的,同样,每个组织都有自己的架构、监控目标、阈值、关注点。

本书将探讨大部分需要监控的内容,确定关键检查点,并介绍一系列可以采用或修改的模式。通过阅读本书,你应该能够为组织的框架构建解决方案,满足组织的特定需求。

下面是每一章的要点。

  • 第1章:引言。
  • 第2章:介绍监控框架,内容包括监控、指标、度量。这一章为监控框架的相关决策和架构提供所需的背景知识。
  • 第3章:使用名为Riemann的事件路由器管理事件和指标。
  • 第4章:使用Graphite和Grafana存储和可视化指标。
  • 第5章:使用collectd进行主机监控。
  • 第6章:在Riemann和Graphite中使用collectd事件。
  • 第7章:讨论如何监控容器,主要是监控Docker。
  • 第8章:采集诊断日志和状态日志,涵盖ELK技术栈。
  • 第9章:构建受监控的应用程序,并了解如何向应用程序添加插装点、指标、日志记录、事件。
  • 第10章:构建与上下文有关且可读性良好的通知。
  • 第11~13章:监控技术栈。这部分将把所有的组件放在一起监控示例主机、服务、应用程序栈,并全面介绍监控框架的工作原理。
  • 附录:介绍Clojure,Riemann将它作为配置语言。(建议在阅读第3章之前先阅读附录。)

本书没有直接讨论对非主机设备的监控,包括网络设备、存储设备、数据中心设备。不过,书中探索的许多技术可以用于这些设备。现代设备有助于推送指标、提供指标和状态端点,并生成适当的事件和日志。

1.7 工具的选择

本书主要讨论免费和开源的监控工具及解决方案,其中会涉及许多提供监控服务的商业工具和在线服务,但不会一一展开介绍。

必须认识到,书中所涉及的内容并不是一成不变的。你可能会看着书中介绍的工具列表,想着必须学习和管理很多软件。为了解决这个问题,本书精心组织内容结构,尽可能地帮助你实现监控框架的各个部分,而不是整个框架。大多数章节会有一个独立的组件,可以与其他组件集成,也可以独立使用。

基于研究、经验和与业内同事的咨询,本书还选择了几种工具,我认为这些工具在其领域中性能最佳。如果你发现所介绍的工具不适合你或不满足需求,针对这种情况,每一章都尽可能地列出了可以探索的替代工具。选择这些工具仅仅是为了阐明本书中提出的监控方法,它们是树林里的树,还有更多的树等待着你去发现。如果你找到更好的工具,并取得相同的结果,那么可以写一篇博客文章,做一次演讲,或者分享你的配置。我很乐意听取你的意见。

目录

  • 版权声明
  • 前言
  • 第 1 章 引言
  • 第 2 章 监控框架
  • 第 3 章 使用Riemann管理事件和指标
  • 第 4 章 Graphite和Grafana
  • 第 5 章 监控主机
  • 第 6 章 在Riemann中使用collectd事件
  • 第 7 章 容器——另一种类型的主机
  • 第 8 章 日志
  • 第 9 章 构建可监控的应用程序
  • 第 10 章 通知
  • 第 11 章 监控之巅:监控Tornado
  • 第 12 章 监控Tornado:应用程序层
  • 第 13 章 监控Tornado:数据层
  • 附录 浅谈Clojure和函数式编程
  • 作者简介