软件开发中的设计模式是解决常见问题的可重复解决方案和最佳实践。即使在服务监控的情况下，如果使用得当，设计模式也可以帮助团队接受服务所有权并解决生产中的服务故障。您可以将服务监控设计模式分为三类：
- 健康检查你怎么知道你的服务正在运行——如果是的话——也在做它应该做的事情？是否及时响应？您是否可以在影响客户之前解决潜在的服务问题？
- 实时警报当出现问题时（例如您的服务变得无响应、爬行速度变慢或使用了太多资源），您是否配置了警报以通知您该问题？
- 故障排除您的服务出现问题了吗？如果有，您可能需要知道三件事：何时发生、发生在何处以及导致它发生的原因。在问题发生后使用日志和跟踪来诊断问题，并更新您的服务，使这些问题不会对客户产生持久的影响。
健康检查
健康检查的两种模式是由外而内的健康检查，它验证您的服务是否正在运行并确定您的服务的响应时间/延迟，以及由内而外的健康检查，它密切关注应用程序和系统指标，以便您可以在潜在问题（包括性能问题）引起事件之前检测到它们。
- 1.由外而内的健康检查
在此模式中，您使用健康检查服务或综合测试工具 ping 您的服务端点。我们使用我们内部构建的工具，但其他选项包括 NewRelic、Gomez 和 DataDog。您的服务响应 ping，它将检查的输出记录为时间序列度量系统中的度量，例如Argus或您用于此类服务的任何系统。数据可用后，您可以在一段时间内可视化服务的运行状况和其他关键指标，和/或选择在满足特定条件时向您发送警报。
此模式可用于检查两组主要指标：
- 正常运行时间——这个指标回答了一个由来已久的问题，“我的服务是否正在运行，它是否在做它应该做的事情？” 健康检查调用程序 ping 您的服务后，如果您的服务响应，则它已启动；如果它没有响应，则它已关闭，您需要开始修复工作
- 用户感知延迟— 您必须从全球多个位置检查服务延迟。例如，对于从日本访问您的服务的客户而言，用户感知的延迟可能与从西班牙和美国访问服务的客户不同。您可以将运行状况检查 API 调用的延迟用作用户感知延迟的代理。
上述两组的组合也可用于确定您的服务的基于合成的可用性信号。
- 2.由内而外的健康检查
在此模式中，您可以使用系统和应用程序指标在潜在问题导致服务中断之前检测到它们——为您的服务和您的客户！
要确定是否存在可能影响服务性能或可用性的潜在问题，请收集有关应用程序及其运行的底层基础架构的指标。
那么您应该关注哪些应用程序指标？至少，收集这四个信号。
- 请求率——你的服务有多忙？
- 错误率——您的服务中是否有任何错误？如果有，有多少，它们发生的频率是多少？
- Duration (of requests) ——你的服务响应请求需要多长时间？
- 饱和度——你的服务有多过载？它有多大的成长空间？
此外，为您的服务使用的每种资源类型（例如 CPU、内存、磁盘空间、IOPS）收集这些系统指标。
- 利用率——这个资源有多忙？
- 饱和度——影响应用程序性能/正常运行能力的应用程序中最受限制的资源的利用率如何？
- 错误— 资源的错误计数是多少？
收集这些指标还允许您计算服务的可用性指标，这回答了关键问题 — 我的服务或功能是否被认为对我的客户可用？在大多数情况下，正常运行时间、持续时间（延迟）和错误率指标的组合可用于以代表客户服务体验的方式计算服务的可用性。例如，如果您仅根据正常运行时间计算服务的可用性，那么即使查询需要很长时间才能响应/网页需要很长时间才能加载，您仍然会认为自己可用。因此，采用其他指标（例如错误率和持续时间）对于适当定义可用性至关重要。
反模式：使用日志建模指标
使用日志数据建模指标的计算成本很高（这意味着在货币方面很昂贵），并且增加了摄取、处理和反应的时间，从而增加了 MTTD（平均检测时间）。这些结果都不是可取的。在 Salesforce，我们的团队构建了高效的指标收集工具供我们的开发人员使用。
- 3. 修复问题
警报的一般模式涉及确定问题是否可以自动修复，或者是否需要人工采取某些措施以避免违反公司与客户的服务水平协议 (SLA)。
警示反模式
- 不要做玻璃观察。随着系统规模的扩大和复杂性的增加，我们不能依靠人类24小时盯着显示器来寻找服务的健康趋势，并在违反阈值的情况下打电话给某人来修复问题。我们需要依靠机器和算法在出错时通知我们。这也把人为错误排除在外。尽可能多地实现流程的自动化。
- 所有的警报都是不一样的。因此，不要以同样的方式对待所有警报。把服务的每一个小问题都作为警报发送到电子邮件/Slack频道，结果不过是垃圾邮件，并大大降低了信噪比。对于每一个服务问题，如果有可能导致客户问题/SLA违反（关键问题），请呼叫值班工程师（使用类似PagerDuty的东西）。其他所有的事情都应该被记录为票据（如果需要采取行动），或者应该被记录为日志条目。
故障排除
当您的服务确实出现问题时，您需要有关出现问题、出现问题的时间以及出现问题的位置的信息。对您的服务进行编码，以便此类信息可用于解决问题。有两种关键方法可以使这些信息可用。
- 记录错误情况和相关信息
- 在您的服务中启用分布式跟踪（尤其是在微服务环境中）
- 4. 记录错误情况
日志是您找出服务出现问题以及何时出现问题的最佳朋友，因此请务必记录服务的错误情况。在您的服务中包含一个日志库以捕获应用程序日志并将这些日志发送到日志服务。在 Salesforce，我们使用Splunk，但其他一些选项可能是 DataDog、NewRelic 等。
进行故障排除时，您可以使用应用程序日志和基础架构日志来帮助您确定导致事件的原因以及如何减少事件再次发生的机会。
- 5. 微服务的分布式跟踪
在微服务架构中，当发生事件或性能下降时，您需要了解的不仅仅是问题所在。您还需要知道您的哪些微服务导致或促成了该问题。
分布式跟踪允许您通过使用 requestID 标识每个请求来获取该信息。当问题发生时，您可以查明它在请求流中发生的位置以及问题是与您的服务相关联还是与相关服务相关联。在 Salesforce，我们已经将我们所有的各种应用程序与自主开发的分布式跟踪服务（构建在 Zipkin 之上）Tracer 集成在一起。生成的 span 被发送到 Tracer，并使用B3 headers将上下文传播到下游应用程序。对于检测，我们使用Zipkin或OpenTelemetry库。