微服务中的数据库可观测性面临三个主要挑战：分布式数据复杂性、动态基础设施扩展和碎片化的监控工具。 这些问题源于微服务的架构设计，该架构强调具有自己的数据存储的去中心化、独立的服务。
分布式数据复杂性 在微服务中，每个服务通常管理自己的数据库，从而导致数据孤岛。 跨多个服务跟踪事务变得困难，因为单个用户请求可能涉及与多个数据库的交互。 例如，电子商务订单可能会更新库存 (MySQL)、处理付款 (PostgreSQL) 和记录活动 (MongoDB)。 专为单体系统设计的传统监控工具难以映射跨服务依赖关系或识别此类场景中的延迟瓶颈[1][8]。 此外，数据库类型（SQL 与 NoSQL）的不一致会产生不匹配的查询模式和日志记录格式，从而使统一分析变得复杂。
动态基础设施扩展 诸如 Amazon DynamoDB[1] 之类的云原生数据库和容器化服务会根据需求自动扩展，从而导致短暂的数据库实例。 可观测性工具可能无法跟踪短时连接或关联来自瞬态资源的指标。 例如，如果监控代理未与编排层同步，则在流量高峰期间水平扩展的 Kubernetes 管理的 PostgreSQL pod 可能会生成不完整的查询延迟指标。 这种不稳定性也会影响异常检测，因为基线性能指标会不可预测地变化。
工具碎片化 团队通常使用专门的工具来记录日志（例如，Elasticsearch）、指标（例如，Prometheus）和跟踪（例如，Jaeger），但是将这些工具集成以实现数据库可观测性需要自定义管道。 发出慢查询日志的 PostgreSQL 服务可能不会将这些日志链接到 API 网关跟踪，从而延迟了根本原因分析。 此外，多租户环境中的安全策略通常会限制直接数据库访问以进行监控，从而迫使依赖部分元数据。
为了应对这些挑战，工程师需要服务网格集成的可观测性平台，该平台可以标准化跨提供商的数据库指标、自动执行依赖关系映射，并在扩展事件期间保留上下文。
[1] 数据库服务 [8] Web 服务