Dynatrace 是一款功能强大且智能的全栈监控平台，用于应用性能管理和基础设施监控。它可以为各种应用程序组件、服务和基础设施提供深入的可观察性。在 Dynatrace 中，服务是指通过特定的应用程序或基础设施提供的逻辑功能或操作，例如 HTTP 请求、数据库查询等。Opaque Service（不透明服务）是 Dynatrace 中一个重要但稍显复杂的概念，这种类型的服务是由于服务的调用方式、代理的监控方式等原因，使得部分服务的细节信息对 Dynatrace 变得模糊不清，无法深入到底层了解更为具体的调用和上下文细节。
简单来说，Opaque Service 是指那些无法被 Dynatrace 探针直接探测和分辨的服务，这种不透明性可能源于服务架构的特殊性、技术栈的限制或者是因为这种服务的调用方式不符合传统的 HTTP 或 RPC 模式，导致 Dynatrace 无法识别其完整的事务链路。
举个例子，假如你的系统里有一个通过外部中间件调用的微服务，或者是某种以独特协议通讯的自定义组件，Dynatrace 可能无法探测出其内部的详细信息，而只能通过间接的方式捕捉部分数据，这种情况下，这些服务就会被定义为 opaque service。
Opaque Service 的定义和分类
在 Dynatrace 中，当某个服务由于某些原因变得无法完全被监控，它就会被归类为 Opaque Service。具体来说，Opaque Service 分为以下几种类型：
-
外部 API 调用：如果服务通过外部 API 进行调用，而这些 API 并未被 Dynatrace 直接监控，则该服务可能被视为不透明的。例如，如果你的应用程序调用了一个第三方支付接口，但是该第三方服务没有安装 Dynatrace 探针，或者该 API 使用了自定义加密的方式，这使得 Dynatrace 无法获取调用的详细信息。
-
基于消息队列的服务：有些服务是通过消息队列（如 Kafka、RabbitMQ）进行通信的，消息在生产者和消费者之间传递，且 Dynatrace 无法对消息队列中的每条消息进行追踪，因此，服务的部分处理会成为 Opaque Service。比如，一个生产订单信息的微服务通过 Kafka 发送订单数据给消费者服务，由于消息在队列中传输，这个部分的详细交互对于 Dynatrace 来说是难以直接追踪的。
-
代理服务：当某些服务存在代理层（如 API Gateway 或负载均衡器），Dynatrace 可能只能看到代理层的存在，而看不到代理之后的服务细节。比如，某个请求经过一个负载均衡代理，Dynatrace 只能识别负载均衡器，但看不到它之后连接的实际服务细节。
-
内部服务调用的封装：在一些复杂的微服务架构中，服务之间可能使用非常特殊的通信协议或者进行过多层的封装，这些使得 Dynatrace 无法识别各个服务之间的完整调用链。这种封装可能是为了提高安全性或者优化性能，但也增加了监控工具识别的难度。
实例分析：Opaque Service 的实际案例
为了更好地解释 Opaque Service 的概念，我们可以通过一个真实世界的例子来理解其运作方式。
案例：电商平台中的支付系统
想象你正在管理一个大型电商平台，平台的各个部分是通过微服务架构构建的。整个支付流程非常复杂，因为它涉及多个不同的外部服务和内部处理逻辑，包括支付验证、风险控制、交易授权等。而这些支付环节不仅依赖于你自己开发的服务，还包括多个外部支付提供商，比如 PayPal、Stripe 或者某个银行的支付网关。
在这个例子中，客户在进行支付时，应用程序调用了第三方支付提供商的 API。由于这个支付 API 是第三方提供的，并且支付过程涉及很多敏感信息，因此支付服务使用了 HTTPS 加密通信，且支付提供商的服务器上没有安装任何 Dynatrace 的探针。在这种情况下，Dynatrace 无法直接监控第三方支付提供商服务器内部的事务处理细节，因此这些支付 API 就会被标记为 Opaque Service。
再举一个内部架构的例子，假设在订单确认之后，系统需要通过消息队列将订单信息发送到一个物流服务中去完成物流安排。在这种情况下，订单服务将信息通过 Kafka 发送出去，而物流服务通过订阅 Kafka 消息来处理这些订单。在这个过程中，Dynatrace 只能看到订单服务向 Kafka 发送了消息，但消息队列本身并不会被 Dynatrace 跟踪，因此，从消息进入队列到被物流服务接收到的这段时间和过程，都是不透明的，导致物流服务被认为是 Opaque Service。
如何处理和优化 Opaque Service 的监控
Opaque Service 的存在会影响对系统全貌的监控和深入分析。Dynatrace 提供了多种方法来优化对这些服务的监控，尽量减少它们的不透明性。
1. 分布式追踪结合日志监控
为了更好地追踪 Opaque Service 的运行，Dynatrace 建议对这些服务的日志进行深入的集成分析。通过对分布式系统中各服务的日志进行集中化管理，并与可用的分布式追踪数据进行关联，可以更好地补足对这些不透明部分的监控。例如，对于使用 Kafka 进行通信的服务，可以配置 Kafka 的生产者和消费者在日志中打印消息 ID，这样可以通过日志的分析来间接跟踪消息的去向，了解完整的调用链。
2. 使用开放标准（OpenTelemetry 或 OpenTracing）
如果服务本身使用的是不被 Dynatrace 支持的通信协议或传输方式，可以考虑使用开放的标准，比如 OpenTelemetry 或 OpenTracing。这些标准化的工具可以将一些动态度量和调用信息传递给 Dynatrace，使得系统的透明度得到提升。例如，你可以在微服务内通过 OpenTelemetry 打点，将每次与外部 API 的交互记录下来，这样即便外部 API 是不可见的，但交互的数据和延迟情况仍可以被追踪和分析。
3. 增强与第三方 API 的集成
对于涉及到外部 API 调用的服务，建议尽可能使用 Dynatrace 提供的扩展集成功能。例如，Dynatrace 提供了对许多云服务和第三方平台的专用集成模块，通过这些集成模块可以获取到更多的详细信息。例如，AWS、Azure 等云平台的 API Gateway，如果配置恰当，Dynatrace 可以获取到关于 API 的更多性能指标，减少 Opaque Service 的存在。
案例分析：从不透明到透明的优化过程
以下是一个通过优化操作使得 Opaque Service 得以更好监控的案例分析：
案例：旅游预定平台的优化过程
某旅游预定平台在业务扩展时遇到了一些问题，尤其是在处理第三方旅行社和航空公司的预定接口时，这些接口很多都成了 Opaque Service，导致整体事务的性能分析和故障排查变得非常困难。
旅游平台通过以下几步对系统进行了优化：
-
开放标准打点：开发团队通过在服务与第三方接口交互的地方加入 OpenTelemetry 打点，将每次 HTTP 请求的相关信息（包括请求开始时间、结束时间、状态码等）记录下来，并将这些数据发送给 Dynatrace 进行分析。这使得原本无法探测的部分得以显示在整个事务的时间轴上，帮助技术团队理解调用延迟发生在哪个部分。
-
日志集成与上下文关联：平台开发团队将与第三方服务的交互日志都收集并集中发送给 Dynatrace，通过对这些日志的分析，Dynatrace 可以将不同服务之间的关联信息补充到事务跟踪中。在出现问题时，开发人员可以通过日志来找到具体出错的接口请求，并迅速定位问题根源。
-
API Gateway 的监控增强：由于这些第三方服务大多数是通过云平台的 API Gateway 进行的，开发团队增加了对云服务 API Gateway 的监控，将 Gateway 本身的性能数据（如请求延迟、失败率等）也集成到了 Dynatrace 中，形成了一个更完整的监控链路。
通过这些改进措施，旅游预定平台将原本 Opaque 的部分服务转换为更易于监控和分析的透明状态。这样做不仅大幅提升了监控的效果，还极大缩短了在发生问题时的响应时间。
总结
在 Dynatrace 中，Opaque Service 代表那些由于各种原因无法完全被探针和监控工具探测到详细信息的服务。它们的存在会给整体的可观察性带来一定的挑战，但通过使用分布式追踪、日志管理、开放标准打点和与外部 API 的深度集成，可以有效地减少服务的不透明性。
例如，在一个复杂的支付系统中，可能有多个与外部支付服务的交互，因为这些交互涉及敏感的支付信息以及第三方服务的限制，使得这些部分的监控相对不透明；而通过对这些部分增加打点、集成日志系统以及增强 API Gateway 的监控，可以将这些 Opaque Service 变得更透明和易于管理。
Opaque Service 的概念对于理解现代微服务架构中的监控挑战非常重要。通过采取适当的措施，可以逐步减少这些不透明服务的存在，使得整个系统的性能和可靠性得以提升。在实际的项目中，理解如何识别这些不透明部分以及如何进行优化，是确保系统稳健性和高效运营的关键之一。
网友评论