---
schema_version: "1"
id: cbbac28bfbe16de32260ad876c89cdf73ad1f6490d01bad0dc2cb64902d200a3
title: 可观察性和监控 - 模式
collection: architect
version: current
locale: zh-cn
portal_url: https://docs.salesforce.com/architect/current/zh-cn/well-architected/guides/operational-excellence-observability-patterns.md
canonical_url: https://architect.salesforce.com/docs/architect/zh-cn/well-architected/guide/operational-excellence-observability-patterns.html
source_site: architect.salesforce.com
content_type: documentation
content_hash: 570388b02c54a0b6b0d72d50856c7e248d067180d80ed7cfcce59d950070b142
products:
  - 架构良好的框架
  - Architect Site Content Repo
---
# 可观察性和监控 - 模式

了解有关架构良好的[卓越运营](/docs/architect/zh-cn/well-architected/guide/operational-excellence.html)的更多信息 → 可[观察性和监控](/docs/architect/zh-cn/well-architected/guide/operational-excellence.html#observability-and-monitoring)

## 可观察性框架

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 平台 \| Event Monitoring | ✅ Event Monitoring 设计为初始架构，捕获通过异步处理链和外部集成跟踪请求的相关 ID |
| 平台 \| Event Monitoring | ✅ 可观察性基础设施包含在初始阶段，而不是在生产事故被证明无法诊断后进行改造 |
| 平台 \| 集成 | ✅ 集成检查点是有意放置的，以支持跨系统边界的请求跟踪 |
| 平台 \| 平台事件 | ✅ 平台事件负载针对具有事务标记和上下文的运营可见性进行构建 |
| 平台 \| 自定义日志记录 | ✅ 自定义日志框架捕获离散事件，其中包含完整的上下文信息，包括用户身份、时间戳、持续时间和结果 |
| 平台 \| 度量 | ✅ 度量汇总了一段时间内的数值测量，揭示了 API 消耗率、Apex CPU 时间分布和批处理作业成功率等趋势 |
| 平台 \| 分布式跟踪 | ✅ 跟踪将同步 API 调用连接到异步处理链，将平台事件连接到订阅者执行，并将集成请求连接到外部系统响应 |
| 平台 \| 可观察性 | ✅ 可观察性使操作员能够回答有关系统行为的任意问题，而无需为每个调查部署新的仪器 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 平台 \| Event Monitoring | ⚏ 在没有自定义日志的情况下启动解决方案，当生产事件被证明无法单独使用平台日志诊断时，需要在六个月后进行重大重构 |
| 平台 \| Event Monitoring | 将可观察性改造到现有解决方案中，需要在操作改进工作中对大部分组件进行仪器更改，并存在缺陷风险 |
| 平台 \| 集成 | ⚏ 集成失败，但没有全面的遥测，请求路径无法跨系统边界跟踪 |
| 平台 \| 平台事件 | ⚏ 平台事件负载缺乏操作上下文，导致事件调查依赖于搜索多个系统 |
| 平台 \| 自定义日志记录 | 日志捕获的上下文不足；调查需要重现问题，以收集更多信息 |
| 平台 \| 可观察性 | 预定义仪表板无法回答有关生产中出现的系统行为的意外问题 |

## 平台运行状况监控

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 平台 \| Event Monitoring | ✅ 为捕获 API 使用情况、登录活动、Apex 执行、SOQL 查询、Visualforce 页面、Lightning 页面和报表运行的生产环境启用 Event Monitoring |
| 平台 \| Event Monitoring | ✅ 事件日志文件每小时导出一次到集中日志平台，支持本地平台保留之外的历史分析 |
| 平台 \| Event Monitoring | ✅ 外部日志聚合支持与其他系统的企业遥测进行端到端交易跟踪 |
| 平台 \| Event Monitoring | ✅ 保留事件日志文件，匹配合规报告和长期趋势分析的监管要求 |
| 平台 \| Proactive Monitoring | ✅ Proactive Monitoring 阈值会根据特定组织的正常工作范围进行有意调整，而不是接受默认值 |
| 平台 \| Proactive Monitoring | ✅ Proactive Monitoring 警报在用户可见的事件之前检测 API 限制峰值、并发 Apex 故障、SOQL 行限制方法和行锁定冲突 |
| 平台 \| Proactive Monitoring | ✅ 调整后的阈值产生团队Trust的可操作信号，并采取行动创造持续改进的良性循环 |
| 平台 \| 比例中心 | ✅ 规模中心基线在解决方案稳定期间建立，并在每个主发布后重新访问 |
| 平台 \| 比例中心 | ✅ 规模中心显示哪些操作消耗资源最多，哪些事务接近超时阈值，以及优化投资在哪些方面产生最大影响 |
| 平台 \| 比例中心 | ✅ 基线提示调查揭示了最新部署中引入的无意 N+1 查询模式，导致事务时间增加 |
| 平台 \| 设置审计跟踪 | ✅ 设置审计跟踪跟踪配置更改，包括权限修改、元数据部署和安全设置更新，最多保留 180 天 |
| 平台 \| 设置审计跟踪 | ✅ 当合规性或合同要求需要更长的历史窗口时，设置审计跟踪条目将被导出以保留 180 天以上 |
| 平台 \| Shield | ✅ 对于包含敏感数据、需要变更历史的受管数据或关键业务数据的字段，有选择地启用字段审计跟踪 |
| 平台 \| Shield | ✅ 字段审计跟踪为了解历史值有助于运营和合规报告的字段提供长达 10 年的保留期 |
| 平台 \| 健康检查 | ✅ 健康检查审查计划每季度进行一次，并根据环境的风险优先级对调查结果进行补救 |
| 平台 \| 健康检查 | ✅ 健康检查发现得到有意的审查，而不是被动接受;补偿控制或不同的风险容忍被记录下来 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 平台 \| Event Monitoring | 事件监控已启用，但日志从未导出，将调查限制为本机保留窗口，并阻止历史趋势分析 |
| 平台 \| Event Monitoring | 事件日志文件保留在平台存储中；不实施外部聚合会阻止长期容量规划 |
| 平台 \| Proactive Monitoring | Proactive Monitoring 使用过于敏感或过于宽松的默认阈值，生成团队学习忽略的干扰警报 |
| 平台 \| Proactive Monitoring | 警报噪音会破坏对监控系统的Trust；团队停止响应有效信号 |
| 平台 \| 比例中心 | 规模中心已启用，但从未主动审查；性能缓慢下降，直到用户在几个月的增量降级后抱怨 |
| 平台 \| 比例中心 | ⚠ 绩效指标缺乏基线上下文；不清楚 3 秒的事务时间是典型的、改善的还是降级的 |
| 平台 \| 设置审计跟踪 | 设置审计跟踪不会导出；保留限制会阻止超过 180 天的安全调查或合规验证 |
| 平台 \| Shield | 为所有字段启用字段审计跟踪，而不是有选择地启用，这会产生没有相应合规值的存储成本 |
| 平台 \| 健康检查 | 运行状况检查结果从不审核；安全配置偏离基准建议，未经有意接受 |

## 应用程序和集成监控

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 平台 \| 用户流 | ✅ 根据业务影响定义关键用户流，并端到端地监控成功率、完成时间、放弃点和错误率 |
| 平台 \| 用户流 | ✅ 关键流包括创收活动（订单提交、合同执行、业务机会完结）、高用量活动（登录、搜索、记录创建）和合规要求的活动（同意捕获、数据主体权利履行） |
| 平台 \| 用户流 | ✅ 流带有事务标记，指示每个重要步骤的开始、完成、放弃和失败 |
| 平台 \| 用户流 | ✅ 订单提交流在每个阶段（购物车验证、库存检查、付款处理、履行触发器）使用平台事件进行测量，按阶段显示成功率 |
| 平台 \| 用户流 | ✅ 流级监控揭示了组件级监控中不可见的问题，因为故障可能发生在任何过渡点 |
| 平台 \| 用户流 | ✅ 在流成功率低于可接受阈值或持续时间超过延迟目标时触发警报 |
| 平台 \| 集成 | ✅ 集成健康监控在级联到面向用户的故障之前，检测外部系统故障、网络问题、身份验证问题和速率限制方法 |
| 平台 \| 集成 | ✅ 关键同步集成的成功率监控警报低于 99% |
| 平台 \| 集成 | ✅ 出现基准中不存在的新错误类型时的错误分布监控警报 |
| 平台 \| 集成 | ✅ 同步面向用户的呼叫超过 3 秒时的延迟百分位数监控 (p95) 警报 |
| 平台 \| 集成 | ✅ 当超过已知速率限制或 SLA 阈值的 80% 时，吞吐量监控警报 |
| 平台 \| 集成 | ✅ 断路器状态监控报警,当任何电路断开指示外部系统降级 |
| 平台 \| 集成 | ✅ 重试率监控警报，当持续重试率超过 5% 表示可靠性问题 |
| 平台 \| 集成 | ✅ 将遥测路线集成到集中监控平台，实现跨系统边界的关联 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 平台 \| 用户流 | ⚏ 组件被独立监控，显示运行正常，而 12% 的用户放弃关键流，看不到原因 |
| 平台 \| 用户流 | 当用户无法完成显示监控架构失败的关键工作流时，组件运行状况仪表板显示绿色 |
| 平台 \| 用户流 | 用户接触多个 Apex 类、流、平台事件和外部集成的过程缺乏端到端的可见性 |
| 平台 \| 用户流 | 关键业务旅程缺少工具；成功率和放弃点未知 |
| 平台 \| 集成 | ⚏ 集成失败仅在级联到面向用户的失败后检测，而不是主动检测 |
| 平台 \| 集成 | ⚠ 集成遥测在单个系统中仍处于隔离状态，阻止了跨边界的相关性和根本原因分析 |
| 平台 \| 集成 | ⚠⸏ 在损坏后监控下游症状的警报，而不是尽早揭示根本原因 |

## 服务级别指标和目标

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 平台 \| SLI | ✅ 可用性滑块衡量从用户角度成功执行时间关键流的百分比（接收预期结果，而不仅仅是 200 个状态代码） |
| 平台 \| SLI | ✅ 延迟 CLI 衡量 p50（中位数）、p90（排除异常值的第 90 百分位数）、p95（排除最差异常值的第 95 百分位数）和 p99（显示最差情况体验的第 99 百分位数）的完成操作的时间 |
| 平台 \| SLI | ✅ 延迟目标因操作关键度和用户期望而异（500ms 的搜索感觉是即时的，输入输入的相同延迟感觉是缓慢的） |
| 平台 \| SLI | ✅ 吞吐量 SLI 衡量每个时间单位的成功操作量，揭示容量利用率和增长趋势 |
| 平台 \| SLI | ✅ 吞吐量与延迟相结合，可以揭示系统是否在负载增加的情况下保持性能，或随着容量的增长而下降 |
| 平台 \| SLI | ✅ 错误率 SLI 区分错误类型（验证失败等用户错误与调控器限制异常等系统错误） |
| 平台 \| SLO | ✅ 在选择架构模式之前，根据业务需求确定服务级别目标，定义可接受的 SLI 阈值 |
| 平台 \| SLO | ✅ 业务需求“销售代表必须在 5 秒内看到业务机会更新”推动了 SLO“业务机会详细信息页面加载在 p95 时在 3 秒内完成”，这推动了架构决策 |
| 平台 \| SLO | ✅ SLO 来自业务需求，并推动架构决策，而不是根据系统当前实现的目标来定义 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 平台 \| SLI | 可用性从技术角度（200 状态代码）而不是用户角度（接收预期结果）来衡量 |
| 平台 \| SLI | 延迟仅在中值测量，而不了解 p95 或 p99 百分位数的最坏用户体验 |
| 平台 \| SLI | 错误率 SLI 不区分用户错误和系统错误，屏蔽了需要不同解决方案的不同问题 |
| 平台 \| SLO | 首先构建架构，然后 SLO 被定义为“我们当前实现的一切”，导致接受 12 秒的页面加载，因为系统设计从未考虑用户的要求 |
| 平台 \| SLO | SLO 是架构驱动的，而不是业务驱动的，根据系统实现的目标而不是用户的需求来设定目标 |

## 警报架构

**模式**

| 何处查看 | 好样的 |
| --- | --- |
| 平台 \| 提醒 | ✅ 严重性分类将关键事件（生产不可用、数据损坏风险、安全妥协）立即发送给随叫随到的工程师 |
| 平台 \| 提醒 | ✅ 严重事件（性能下降、部分停机）会在工作小时内生成及时调查的通知 |
| 平台 \| 提醒 | ✅ 警告（接近阈值、配置偏差）生成每日摘要通知，以便进行主动补救 |
| 平台 \| 提醒 | ✅ 警报上下文包含受影响的用户计数、错误消息、堆栈跟踪、最近部署、相关警报和相关仪表板的链接 |
| 平台 \| 提醒 | ✅ 富上下文通过启用即时严重性评估和调查，无需收集基本信息，从而减少了平均确认时间 |
| 平台 \| 提醒 | ✅ 警报分组防止警报风暴，数百个相关警报针对单个基本问题触发 |
| 平台 \| 提醒 | ✅ 集成失败会触发一个按集成端点分组的警报，显示过去 5 分钟内 156 个失败的请求，其中包含延迟图、错误分布和仪表板链接 |
| 平台 \| 提醒 | ✅ 警报抑制防止已知瞬态条件在预期的维护时段或自动修复期间生成警报 |
| 平台 \| 提醒 | ✅ 在定期维护期间、缓存升温时部署后的最初几分钟以及重试逻辑成功的短暂暂时性故障期间，警报会被抑制 |

**反模式**

| 何处查看 | 什么不好的样子 |
| --- | --- |
| 平台 \| 提醒 | ⚠ 所有警报都路由到同一渠道，没有严重性分类；重要事件没有与常规警告区分开来 |
| 平台 \| 提醒 | ⚏ 警报缺乏诊断上下文；随叫随到的工程师必须通过单独的查询收集基本信息，然后才能评估严重性 |
| 平台 \| 提醒 | 集成失败在 5 分钟内生成 156 个单独的警报，使随叫随到的工程师的电话无法接听，每个警报都相同，但时间戳除外 |
| 平台 \| 提醒 | 警报风暴阻止响应者从数百个相关症状中区分单个潜在问题 |
| 平台 \| 提醒 | 在已知维护时段内发出火灾警报，以及产生噪音的瞬态条件，从而削弱对监控的Trust |
| 平台 \| 提醒 | ⚏ 对噪音误报的警报疲劳导致团队忽略通知，降低了响应效率 |