Heroku分布式系统可见性策略：事件处理、指标、图表与服务质量监控的实践

SF Metrics Meetup

总结：

Heroku运营着一个庞大且动态的平台，面临着机器故障、网络问题、流量高峰等诸多运营挑战。为了有效应对这些挑战，Heroku采取了以下可见性策略：

• 整合工具： 采用Graphite进行指标存储和长期图表绘制，使用自研的Tasseo实现实时、带上下文的仪表盘，利用Umpire进行基于HTTP状态码的服务质量(QoS)监控和告警。
• 数据流处理： Backstop提供HTTP+JSON接口方便指标输入，Exprd将结构化日志事件动态聚合为全局指标，Splunk则用于对TB级半结构化日志数据进行交互式查询和分析。
• 核心理念： 将日志视为数据和真相的来源，构建一个通用且可组合的可见性管道，并分离数据生成、计算和呈现层。
• 实践应用： 这一策略支持可见性驱动的事件响应，例如通过金丝雀应用发现HTTP路由问题，并利用各工具链进行实时监控、问题定位和事后分析，最终改进告警阈值。

Heroku的运营挑战与可见性需求 [00:00:03]

Heroku作为一个平台即服务（PaaS），为用户运行着大量应用程序，这些应用程序又依赖于Heroku自身的服务和亚马逊网络服务（AWS）提供的底层基础设施。

• 庞大的软件生态系统
  • 运行用户应用：Heroku负责代表用户运行海量应用程序。
  • 内部服务与基础设施：Heroku自身的软件由多个应用和服务构成，最终依赖于AWS等基础设施原语。
• 面临的运营挑战 [00:00:43]
  • 机器故障、网络波动、第三方服务中断。
  • 流量高峰、内部与用户部署。
  • 意外的系统动态变化。
• 可见性工作目标 [00:01:04]
  • 从“对生产环境一无所知”的恐惧状态（如收到500错误但不知原因）转变为“清晰了解问题症结”。
  • 理解并有效响应运营事件，明确问题的根源及其对用户代码的影响。
  • 可见性涵盖指标、日志、告警等多个方面，且需持续投入以适应不断增长的规模。

Heroku内部工具与服务 [00:01:51]

Heroku的可见性工作依赖于一系列内部开发和开源工具，它们共同构成了一个高效的监控与分析系统。

• Graphite：指标存储与长期图表 [00:02:29]
  • 用途：主要用于指标数据存储和生成长期历史图表。
  • 存储：提供基本的分层存储，用于规范化的指标数据。Heroku将大量指标发送至Graphite，由一台大型Graphite服务器处理。
  • API：提供网络服务API，用于存储和检索指标。
  • 图表：能够将数据库中的指标数据绘制成长期历史图表，这些图表是后续其他工具可视化的基础。
• Tasseo：实时仪表盘与上下文 [00:03:40]
  • 开发背景：由Heroku工程师Jason开发，专注于提供指标的实时视图和上下文信息。
  • 解决痛点：Heroku生产环境面临数千甚至数万用户受问题影响的情况，需要快速响应。同时，其软件系统具有高度多维性，内部服务交互复杂。
  • 功能 [00:04:19]
    • 实时仪表盘：在一个网页上提供快速、简易的实时仪表盘，显示关键指标的最近五分钟数据，每三秒更新一个像素。
    • 环境感知：可作为办公室等离子显示屏的环境监控工具，也能在事件响应时实时观察配置更改的效果。
    • 灵活配置：采用简洁的配置机制，通过数据指定仪表盘显示内容，鼓励工程师部署大量自定义仪表盘。

      

    • 上下文视图：提供强大的历史上下文功能（如1小时、3小时视图），帮助工程师理解指标的长期演变趋势和相互关系，从而更好地定位问题。

      

  • 开源状态：Tasseo已开源并可在GitHub上获取，用户可在两分钟内将其部署为Heroku应用，并从Graphite后端拉取数据。

    

• Umpire：服务质量监控与告警 [00:07:00]
  • 核心目标：将告警直接绑定到指标数据，确保收到告警时能追溯到原始数据源进行响应。
  • 工作机制 [00:07:22]
    • 阈值设定：针对Graphite中的基础指标数据（如可用性百分比），设定一个阈值（例如95%可用性）。
    • HTTP接口：Umpire提供HTTP接口，接收请求后查询Graphite，根据指标数据与预设最大/最小值对比，返回200（正常）或500（异常）HTTP状态码。

      

  • 集成能力：这种设计允许Umpire与Nagios等标准化监控工具无缝集成。
  • 应用场景 [00:08:24]
    • 监控请求每秒量、每分钟错误数、延迟（P50, P95, P99）。
    • 甚至扩展到业务指标，例如平台上的免费应用数量或特定类型进程的数量。
  • 开源状态：Umpire同样开源，可快速部署为Heroku应用。

    

• Backstop：HTTP+JSON指标输入 [00:09:09]
  • 目的：Heroku强烈偏好使用HTTP接口，因为它在路由、可见性、日志等方面拥有大量HTTP基础设施。
  • 功能：作为Graphite的前端服务，提供一个受HTTP授权保护的HTTP+JSON接口，允许以数据而非原始Graphite文本格式提交指标。
  • 开源状态：Backstop已开源。

    

• Exprd：事件（日志）转指标的通用聚合服务 [00:09:56]
  • 概念：作为StatsD理念的泛化，将任意日志流处理为可聚合的指标。
  • 背景：Heroku内部所有应用程序都以结构化数据的方式（而非纯文本）记录日志，这些日志本质上是键值对。
  • 功能 [00:10:48]
    • 动态聚合：允许用户动态定义规则，从日志事件中提取信息并进行聚合。
    • 示例：例如，可以从检查HTTP服务的“金丝雀应用”日志中，计算60秒窗口内成功请求的99百分位延迟。

      

  • 必要性：处理分布式基础设施的全局指标时，这些指标无法在单个节点上计算，必须依赖整个日志流。
  • 聚合类型：支持多种聚合操作，如均值、最大值、最小值、百分位等。

    

  • 状态：Exprd目前尚未开源，但团队正在努力推进。
• Splunk：日志数据交互式分析 [00:12:57]
  • 价值：Heroku将所有日志数据视为数据导向的（键值对形式），Splunk的强大之处在于能够对数TB的半结构化数据进行交互式搜索、聚合和排序。
  • 应用 [00:13:41]
    • 故障排查：例如，查找在特定时间段内，与特定键值对匹配、且延迟较高的事件，并找出最常出现这些事件的实例ID。
    • 深入分析：支持进行复杂的聚合查询，快速从海量日志中提取有价值的信息。

      

可见性管道与方法论 [00:14:20]

Heroku的可见性策略不仅关注工具本身，更强调构建一个具有凝聚力、可组合的管道和一套清晰的方法论。

• 可组合的可见性管道 [00:14:25]
  • 核心理念：摆脱传统垂直、孤立的监控系统（如实例级、业务级指标），构建一个像UNIX哲学一样通用且可组合的可见性管道。
  • 架构 [00:14:57]
    • 数据根源：以结构化日志（事件）作为可见性树的根源。
    • 服务分发：日志数据被推送给各种服务进行处理，例如：
      • 查询：Splunk等工具进行即席查询和归档（如S3）。
      • 指标：Exprd将日志处理为指标。
      • 实时图表：Tasseo提供实时可视化。
      • 告警：Umpire进行服务质量监控和告警。
    • 下采样与可视化：数据在管道中不断被处理和下采样，最终在不同层级进行可视化。

      

  • 一致的可见性故事 [00:15:27]
    • 所有工具都基于相同的根数据源（日志），确保了在处理告警、查看图表或进行即席查询时，数据来源的一致性。
    • 这种连贯性对于理解和解决平台上的任何问题都至关重要。
• 将日志作为数据处理 [00:16:11]
  • 哲学基础：这是Heroku可见性方法论中最关键的哲学层面。日志不再是供人阅读的文本字符串，而是机器可解释、可处理的结构化数据。
  • 对比传统：传统日志通常是简单的字符串文本，难以被程序自动解析和利用。
  • 实践 [00:16:40]
    • Heroku将日志以键值对或JSON等数据格式发出。
    • 这种数据导向的日志模式是整个工具链能够运作的基础，使得能够动态地从日志中提取和生成新指标。

      

• 将日志作为事实来源 [00:17:08]
  • 深入视角：将日志视为基础设施中发生的一切的完整、高保真历史流。
  • 潜在价值：日志是潜在的强大事实来源，提供了基础设施的完整视图。
  • 工具需求：需要相应强大的工具才能从这种数据流中提取所有有价值的信息。
• 分离数据生成、计算和呈现 [00:17:48]
  • 解决痛点：传统的可见性系统往往是紧耦合的，一个应用的特定语言插件连接到一个特定的可见性服务，再以特定方式呈现。这导致了工具的孤立和碎片化。
  • 优势：通过将数据生成、数据计算和数据呈现层分离，Heroku能够独立改进这些组件，实现工具的插拔和替换。
  • UNIX哲学：这种方法论类似于UNIX哲学，即构建小巧、精良的工具，然后通过组合它们来解决复杂问题。

生产案例：HTTP路由问题响应 [00:18:40]

讲者展示了一个真实的生产事件，说明其可见性策略如何驱动事件响应。

• 问题发现：金丝雀应用与告警 [00:19:12]
  • 金丝雀应用：Heroku部署了大量金丝雀应用，持续检查生产环境。
  • 数据生成：这些检查进程会发出关于检查结果的日志数据。
  • 指标计算：Exprd服务根据这些日志计算HTTP堆栈不同切片的可用性百分比。
  • 告警触发：Umpire监控这些可用性指标，当特定切片的可用性低于预设阈值（如95%）时，触发告警（即向工程师发送寻呼）。

    

• 实时响应与仪表盘 [00:20:07]
  • 工程师收到告警后，能够立即调出Tasseo仪表盘。
  • 仪表盘上显示了触发告警的指标，以及一系列相关的实时指标（例如，同一堆栈的延迟变化）。
  • 实时查看仪表盘有助于工程师快速了解问题当前演变情况，判断是自动恢复还是持续恶化。

    

• 问题定位与深入分析 [00:20:42]
  • 对比分析：通过对比不同HTTP堆栈的可用性，工程师确认了特定切片确实存在问题。
  • 日志查询：为了深入挖掘根本原因，工程师转向数据导向的日志，使用Splunk查询并提取数百个错误示例。
  • 模式识别：日志分析揭示了与特定IP地址相关的错误模式。
  • 图表验证：工程师绘制了这些IP模式随时间变化的图表，进一步确认了问题与特定IP地址有关，从而定位到HTTP堆栈解析到的某个具体IP。

    

• 事后分析与预防 [00:21:24]
  • 根因追溯：事件解决后，团队进行事后分析，查看更长时间段内的指标历史图表。
  • 发现潜在问题：他们发现在事件真正对用户产生影响之前，某个特定指标就已经出现了缓慢的增长。
  • 改进告警：基于这一发现，团队可以在该指标上设置新的告警阈值，以便在未来类似问题早期阶段就能被发现并响应。

问答环节亮点 [00:22:12]

• 可见性团队规模 [00:22:12]
  • 平台工程团队大约有十几个成员，其中约1-2名全职人员专注于可见性工作。
  • Heroku之所以能以较少的人力维护如此庞大的基础设施，关键在于其追求通用且灵活的工具。平台拥有约100个内部服务、10种语言/框架，运行在数千台机器上，若为每个维度单独开发工具将不可行。
• 监控工具自身的负载问题 [00:23:37]
  • 解决方案是避免在同一台机器上运行监控工具和被监控应用。
  • 将监控工具构建为网络服务，从而将负载分散到网络上。
  • 通过在数据流中进行足够的下采样，可以有效管理网络负载。
• 日志保留策略 [00:24:20]
  • 不同的数据节点有不同的数据保留时间。
  • 例如，S3归档的日志可保留数月（海量数据，TB级别）。
  • Exprd聚合工具的缓冲区可能只保留数分钟或数小时的数据。
  • 实时网页（如Tasseo）通常只缓存五分钟左右的数据。
  • 原始日志作为根数据源，Heroku尽可能长时间地保留它们，因为在需要时可以从中重新提取任何信息。
• 客户应用的可见性 [00:25:26]
  • Heroku大部分内部服务运行在Heroku平台自身上，因此其内部可见性工具也适用于这些服务。
  • 客户理论上可以通过其日志插件（log drains）获取日志流，并自行搭建类似的可见性系统。
  • 但目前缺少将这些能力产品化、易于使用的解决方案（例如Exprd尚未开源，Splunk设置复杂）。未来Heroku计划通过附加组件（add-ons）的形式，提供更多集成化的可见性仪表盘。
• 可见性流程中的手动环节 [00:26:22]
  • 当前仍存在一些手动环节：
    • 告警阈值设定：目前需要手动设置指标的阈值，尽管未来可能实现自动计算和演进（例如根据平台流量增长自动调整阈值）。
    • Splunk查询生成：进行深入的故障排查时，手动编写Splunk查询语句来钻取数据。
• 节点配置管理 [00:27:14]
  • Heroku使用Chef进行节点配置，但其方法论与可见性策略类似，强调通用性。
  • 开发者遵循通用的应用程序接口规范，即可自动获得日志收集、可见性服务接入等一系列免费功能，而无需为每个应用编写特定的Chef配方。