本文永久链接 – https://tonybai.com/2025/05/26/monitor-design-with-red

大家好，我是Tony Bai。

随着业务的快速发展，越来越多的应用开始拥抱云原生。我们享受着微服务带来的解耦、容器带来的标准化、Kubernetes带来的弹性伸缩。但与此同时，一个灵魂拷问也摆在了每一位开发者和运维工程师面前：我的服务还好吗？用户用得爽吗？出问题了能快速定位吗？

传统的只盯着CPU、内存、磁盘的监控方式，在高度动态和分布式的云原生环境下，常常显得力不从心，就像“瞎子摸象”，难以窥得全貌。我们需要一种更直接、更面向用户体验、更标准化的方法来衡量服务的健康状况。

今天，我就结合一个通用的示例和大家说一套被业界广泛认可的服务监控黄金法则——RED方法，谈谈如何按照RED方法设计出简单又好用的监控指标与告警。

什么是RED方法？

RED方法并非什么高深莫测的理论，它非常简洁，由三个核心指标的首字母组成：

• R – Rate (请求速率)
• E – Errors (错误率)
• D – Duration (响应时长)

这“三板斧”虽然简单，却直击服务质量的核心。它是由Grafana Labs的VP Product，同时也是Prometheus和OpenMetrics早期贡献者Tom Wilkie于2018年提出的，旨在为现代服务（尤其是微服务）提供一套简单、一致且以服务为中心的监控指标集。

让我们逐一拆解：

R – Rate (请求速率)

• 它是什么？ 指服务在单位时间内（通常是每秒）处理的请求数量，我们常说的QPS (Queries Per Second) 或RPS (Requests Per Second) 就是它。
• 为何重要？ 它是服务负载的直接体现。请求速率的异常波动（骤增或骤降）往往预示着潜在的问题，比如突发流量、上游故障、甚至是恶意攻击。同时，它也是容量规划和弹性伸缩策略的重要依据。
• 关注什么？ 我们不仅要看服务的总请求速率，还应该关注：
  • 按API端点/服务接口划分的速率： 了解哪些接口最繁忙，哪些接口流量异常。
  • 按客户端类型划分的速率： 识别不同调用方的行为模式。

E – Errors (错误率)

• 它是什么？ 指服务在处理请求时，发生错误的请求所占的百分比，或者单位时间内的错误请求总数。在HTTP服务中，我们通常重点关注服务器端错误，即HTTP状态码为5xx的请求。
• 为何重要？ 错误率是服务可靠性的“晴雨表”，直接关系到用户体验。没有人喜欢看到“服务器开小差了”的提示。持续的高错误率是P0级故障的典型特征。
• 关注什么？
  • 整体服务错误率： 快速判断服务是否处于“亚健康”或故障状态。
  • 按API端点/服务接口划分的错误率： 精准定位是哪个功能出了问题。
  • 按错误类型/状态码划分的错误率： 帮助我们理解错误的性质，是代码bug、依赖问题还是配置错误。

D – Duration (响应时长/延迟)

• 它是什么？ 指服务处理单个请求所需的时间，也就是我们常说的“延迟”。
• 为何重要？ “天下武功，唯快不破。” 响应时长是用户体验的生命线。没有人愿意为一个需要加载半天的页面或应用买单。
• 关注什么？ 平均延迟很容易被少数极端慢请求“平均掉”，因此我们更关注延迟的百分位数 (Percentiles)，特别是：
  • P99 (99th percentile): 99%的请求都比这个值快。代表了体验最差的那1%用户的感受。
  • P95 (95th percentile): 95%的请求都比这个值快。
  • P50 (50th percentile / Median): 中位数延迟，代表了典型用户的体验。
  • 同时，也应关注不同API端点/服务接口的延迟分布。

RED方法 vs. 其他监控方法论

你可能会问，业界还有USE方法、Google SRE的“四个黄金信号”等，RED方法和它们是什么关系呢？

• USE方法 (Utilization, Saturation, Errors): 由性能大神Brendan Gregg提出，它更侧重于分析单个系统资源的健康状况，比如CPU使用率、内存饱和度、磁盘错误等。它是RED方法的重要补充，当RED指标显示服务异常时，USE指标能帮助我们判断是不是资源瓶颈导致的。
• 四个黄金信号 (Latency, Traffic, Errors, Saturation): Google SRE实践的精华。RED方法可以看作是对前三个信号（延迟、流量、错误）的一种更聚焦、更易于落地的诠释。RED中的Rate对应Traffic，Duration对应Latency，Errors对应Errors。RED巧妙地避开了相对抽象和难以标准化的Saturation（饱和度），使其更具普适性。

简单来说，RED方法是在前人智慧的基础上，针对现代分布式服务架构，提炼出的一套“最小完备”且“以用户为中心”的服务健康度量标准。

云原生时代，为什么RED如此重要？

微服务架构中，RED方法（Rate、Errors、Duration）为每个微服务提供了独立的监控手段，使得在故障发生时能够迅速定位问题服务。这种方法能够通过服务之间的调用链，清晰地衡量每一跳的性能，从而构建出完整的端到端视图。

在动态环境中，容器和实例的频繁创建与销毁，以及弹性伸缩的特性，使得传统基于单机资源的监控变得复杂。然而，服务级的RED指标能够稳定地反映服务的整体健康状况，无论其背后有多少实例在支撑。

此外，RED指标直接关系到用户体验。Rate、Errors和Duration三个指标分别反映了用户能否正常快速地使用服务。因此，这些指标对于提升用户满意度至关重要。

RED方法还提供了一套标准化的监控语言，适用于不同类型的服务，如HTTP API、gRPC服务和消息队列处理等。这种通用的监控词汇有助于团队的协作与知识传递。

最后，基于RED指标设置的告警能够更精准地反映真实的用户影响，降低误报率，使告警变得更加可操作。这种精准的监控和告警机制不仅提升了服务的可靠性，也增强了团队对服务健康状况的把控能力。

RED简单又强大，那么我们如何将它落地呢？下面我们就用一个服务的通用指标和告警设计为例，来看看RED方法下常见的服务指标和告警都有哪些。

如何落地RED监控？（通用指标与告警设计）

虽然具体的工具选择（如Prometheus, Grafana, SkyWalking, OpenTelemetry等）多种多样，但RED指标的设计思路是通用的。我们以一个常见的HTTP服务为例，看看如何设计其RED指标（遵循Prometheus指标规范）：

通用服务RED指标设计 (HTTP服务)

• http_requests_total (Counter类型): 记录处理的HTTP请求总数。
  • 核心标签 (Labels):
    • service_name: 服务唯一标识，如 “order-service”。
    • path: API路径模板，如 “/api/v1/orders/{id}” (注意使用模板，避免基数爆炸)。
    • method: HTTP方法，如 “GET”, “POST”。
    • status_code: HTTP响应状态码，如 “200″, “404″, “503″。
• http_request_duration_seconds (Histogram或Summary类型): 记录HTTP请求的处理时长。
  • 核心标签: 同上，status_code也可以用status_code_class（如”2xx”, “5xx”）来减少基数。

基于这两个基础指标，我们就可以通过查询语言（如PromQL）派生出RED指标：

• Rate (QPS):

sum(rate(http_requests_total{service_name="<your_service>"}[5m])) by (service_name, path, method)

• Error Rate (5xx错误率):

(sum(rate(http_requests_total{service_name="<your_service>", status_code=~"5.."}[5m])) by (service_name, path, method)) / (sum(rate(http_requests_total{service_name="<your_service>"}[5m])) by (service_name, path, method))

• Duration (P99延迟):

histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket{service_name="<your_service>"}[5m])) by (le, service_name, path, method))

基于RED指标的通用告警设计

告警的目的是及时发现问题并驱动行动。以下是一些基于RED的通用告警规则思路：

1. Rate告警 (请求速率异常)：
   • 规则： 服务总请求速率在过去10分钟内，与1小时前同一时刻相比，骤降70%以上（或骤增数倍）。
   • 级别： P1/P2 (视业务敏感度)
   • 告警提示： “[服务名]请求速率异常波动！”
2. Error告警 (错误率超标)：
   • 规则： 服务整体5xx错误率在过去2分钟内持续高于5%。
   • 级别： P0
   • 告警提示： “严重：[服务名]5xx错误率飙升至[当前值]！”
   • 规则： 某个关键API端点的5xx错误率在过去3分钟内持续高于10%。
   • 级别： P1
   • 告警提示： “警告：[服务名]接口[API路径]错误率过高！”
3. Duration告警 (延迟超标)：
   • 规则： 服务整体P99延迟在过去5分钟内持续高于2秒。
   • 级别： P0
   • 告警提示： “严重：[服务名]P99延迟高达[当前值]，用户体验受损！”
   • 规则： 某个关键API端点的P95延迟在过去5分钟内持续高于1秒。
   • 级别： P1
   • 告警提示： “警告：[服务名]接口[API路径]P95延迟过高！”

RED并非银弹：构建全面的可观测性

虽然RED方法非常强大，但它也不是万能的。一个完善的云原生可观测性体系，还需要：

• USE方法： 监控底层基础设施和节点的资源使用情况。
• 业务指标： 监控与业务直接相关的指标，如订单成功率、在线用户数等。
• 分布式追踪： 理解请求在复杂调用链中的完整路径和每一跳的耗时。
• 日志管理： 详细的日志是问题排查的“最后防线”。

将RED指标与这些数据源关联起来，才能形成从宏观到微观、从用户体验到系统内部的完整排查路径。

小结

在纷繁复杂的云原生世界，RED方法为我们提供了一套简洁、有效且以用户为中心的“导航系统”。它帮助我们聚焦于真正重要的服务健康指标，快速发现问题，优化性能，最终保障并提升用户体验。

希望今天的入门RED分享能对你有所启发。不妨现在就开始思考，如何在你的服务中实践RED监控吧！

你对RED方法有什么看法？在你的监控实践中，还有哪些好用的“三板斧”？欢迎在评论区留言交流！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/05/16/energy-savings-if-abandon-https

大家好，我是Tony Bai。

如今，当我们浏览网页时，地址栏那把绿色的小锁和 HTTPS 前缀已是司空见惯。从网上银行到个人博客，再到每一个SaaS服务，HTTPS/TLS 加密几乎覆盖了互联网的每一个角落。它像一位忠诚的数字保镖，守护着我们在虚拟世界中的数据安全与隐私。

然而，这位保镖并非“免费服务”。HTTPS/TLS 在带来安全的同时，也无可避免地引入了额外的计算和传输开销，直观感受便是连接速度可能略有减慢，传输数据量也略有增加。而且，随着我们对安全的追求永无止境，为了抵御更强大的计算破解能力，加密算法的密钥长度也在不断增加（例如从 RSA 1024位到2048位甚至更高，ECC 曲线的复杂度也在提升），这无疑进一步加剧了这些开销。

那么，今天我们不妨来做一个大胆的，甚至有些“异想天开”的思想实验：如果在一夜之间，全球所有的网站都决定弃用 HTTPS/TLS，回归到“裸奔”的 HTTP 时代，理论上能为我们的地球节省多少电力呢？

重要声明： 这纯粹是一个思想实验，旨在通过一个极端的假设，引发我们对技术成本（特别是能源成本）和安全效益之间平衡的思考。我们绝非鼓吹放弃 HTTPS/TLS，其在现代互联网安全中的基石地位无可替代。

HTTPS 的“能源账单”：开销源自何方？

要估算节省的电量，首先得理解 HTTPS/TLS 的主要开销在哪里。这些开销主要体现在两个方面：计算开销和数据传输开销。

计算开销 (CPU 的额外负担)

• TLS 握手阶段： 这是计算密集型操作的重灾区。
  • 非对称加密/密钥交换： 如 RSA、Diffie-Hellman 或 ECC (椭圆曲线加密)，用于安全地协商后续通信所用的对称密钥。密钥长度的增加，使得这些运算的计算量呈指数级或更高阶的增长。 例如，一个 RSA 2048 位操作的计算量远超 1024 位。
  • 证书验证： 客户端需要验证服务器证书链的有效性，这涉及到一系列的数字签名验证操作，同样消耗 CPU 资源。
  • 对称密钥生成与哈希计算： 用于生成会话密钥、消息认证码 (MAC) 等。
• 数据传输阶段：
  • 对称加解密： 建立连接后，所有应用数据的传输都需要经过对称加密算法（如 AES）的加密和解密。虽然对称加密比非对称加密快得多，但对于海量数据流，累积的 CPU 开销依然可观。
  • 消息认证码 (MAC) 计算： 为确保数据完整性，需要为每个数据包计算和验证 MAC。

这些计算开销不仅发生在服务器端（数据中心），也发生在每一个发起 HTTPS 请求的客户端设备上（我们的电脑、手机等）。

数据传输开销 (网络带宽的额外占用)

• TLS 握手数据包： 完整的 TLS 握手过程（尤其是在未使用会话复用或 TLS 1.3 的 0-RTT 时）需要多个数据包的往返，这些数据包承载了证书、加密套件协商信息、密钥交换参数等，本身就构成了额外的网络流量。
• TLS 记录层头部： 每个 TLS 记录包都会增加一个小的头部，指明内容类型、版本和长度。
• 填充数据 (Padding)： 某些块加密模式可能需要填充数据以满足块大小要求。

这些额外的字节虽然对单个请求来说可能不多，但考虑到全球互联网的流量规模，累积起来也是一个惊人的数字。这些额外的数据不仅消耗了网络设备（路由器、交换机、基站）的传输和处理电力，也增加了数据中心内部的存储和带宽压力。

尝试量化：一个极度简化的估算

精确计算全球弃用 HTTPS 能节省多少电量几乎是不可能的，因为这涉及到太多动态和难以获取的数据。但我们可以尝试进行一个基于合理假设的粗略数量级估算，目的在于理解其可能的影响范围。

请注意：以下估算高度简化，仅为引发思考，不代表任何精确的科学结论。

• 假设一：全球每日 HTTPS 请求数。 据一些行业报告估计，全球每日的 HTTP(S) 请求量可能达到数百万亿甚至更高。我们不妨取一个相对保守的中间值。
• 假设二：单次 TLS 握手与数据加解密的平均额外能耗。 这取决于多种因素，包括密钥长度、加密算法、硬件加速能力等。我们可以参考一些研究中关于 CPU 执行加密操作的功耗数据，或者服务器因处理 TLS 产生的额外负载百分比。
• 假设三：TLS 协议的平均数据开销。 TLS 握手通常会增加几KB的开销，后续记录层头部等开销相对较小，我们可以估算一个平均的额外数据传输百分比。
• 假设四：全球数据中心和网络基础设施的总能耗。 这同样是一个巨大的数字，数据中心本身就是能源消耗大户。

基于这些高度简化的假设，即使我们只考虑由于 TLS 计算和额外数据传输导致的 全球数据中心电力消耗增加 1%-5% （这已经是一个非常大胆且可能偏低的估计，因为 TLS 的影响是端到端的），考虑到全球数据中心年耗电量已达数百太瓦时 (TWh，1太瓦时=10亿度电) 的量级，这意味着：

理论上，弃用 HTTPS 每年节省的电力可能达到数个乃至数十个太瓦时。

这是什么概念？一个太瓦时的电力，足以供应数十万个普通家庭一年的用电。数十太瓦时，其能源足迹和碳排放影响将是巨大的。

再次强调，这只是一个非常粗略的“思想实验”级别估算。实际情况远比这复杂，例如：

• 现代 CPU 对 AES 等对称加密有硬件指令加速，大大降低了数据传输阶段的加密开销。
• TLS 1.3 显著优化了握手过程，减少了 RTT 和计算量。
• 会话复用技术能避免重复的完整握手。
• CDN 和边缘节点分担了部分 TLS 终结的压力。

但即便如此，考虑到密钥长度持续增加带来的计算压力，以及全球网络流量的爆炸式增长，HTTPS/TLS 的“能源税”依然是一个不容忽视的议题。

安全的代价：我们为何“心甘情愿”支付这笔账单？

既然 HTTPS/TLS 有如此“隐形”的能源成本，为何我们还要坚定不移地推动全网 HTTPS 化呢？

答案不言而喻：安全！

• 数据保密性： 防止敏感信息（如登录凭证、支付信息、个人隐私）在传输过程中被窃听。
• 数据完整性： 确保数据在传输过程中未被篡改。
• 身份认证： 验证通信对方（主要是服务器）的真实身份，防止中间人攻击。

在一个充斥着网络钓鱼、数据泄露、恶意劫持的数字时代，这些安全保障是我们进行在线活动的基础信任。与可能遭受的经济损失、声誉损害、隐私侵犯相比，HTTPS/TLS 的能源成本可以说是“必要的代价”。

追求平衡：我们能为“绿色安全”做些什么？

这次思想实验的目的，绝非要我们因噎废食，放弃安全。恰恰相反，它应该促使我们更积极地思考：如何在保障同等级别安全的前提下，追求更高的效率和更低的能耗？

1. 持续优化协议与算法： TLS 1.3 就是一个很好的例子(Go标准库crypto/tls已经默认采用TLS 1.3)。未来是否还会有更轻量级、更高性能的安全协议或加密算法出现？
2. 硬件加速的普及： 推动和利用 CPU、专用加密芯片对加密运算的硬件加速能力。
3. 智能的会话管理： 更有效地利用会话复用、0-RTT 等技术，减少不必要的握手开销。
4. 内容分发与边缘计算的优化： 在离用户更近的地方进行 TLS 终结，减少长距离加密传输的开销。
5. 代码层面的优化： 对于应用开发者，合理设计 API，避免不必要的加密数据传输，选择合适的加密库和配置。
6. 关注“适度安全”： 对于某些内部系统或低风险场景，是否可以采用与公网不同强度的、但依然安全的加密策略？（这需要非常谨慎的评估）。

小结：思想实验的价值在于警醒与前瞻

“如果全球网站弃用 HTTPS，能为地球节省多少电？” 这个问题的答案可能永远无法精确计算，但它像一面镜子，照见了我们为构建一个更安全的数字世界所付出的“隐形成本”之一。

这提醒我们，安全并非没有代价，技术进步需要在多个维度上寻求平衡。 在坚定不移地拥抱和强化网络安全的同时，我们也应该持续关注其对性能、资源和环境的影响，积极探索和实践更绿色、更高效的安全技术。

聊一聊，也帮个忙：

• 在你的日常工作中，是否感受过 HTTPS/TLS 带来的性能或资源开销？你是如何应对的？
• 对于未来网络安全技术的发展，你认为在“更安全”与“更高效/更绿色”之间，我们应该如何权衡？
• 除了电力消耗，你认为 HTTPS/TLS 还带来了哪些“隐性”成本或效益？

欢迎在评论区留下你的思考和问题。如果你觉得这篇文章提供了一个有趣的视角，也请转发给你身边的朋友和同事，一起参与这个“思想实验”！

想与我进行更深入的 Go 语言、网络安全与 AI 技术交流吗？ 欢迎加入我的“Go & AI 精进营”知识星球。

我们星球见！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。