Anti-patterns and common pitfalls

初创企业在时间和预算压力下采用可观测性时，很容易陷入当时看似合适但长期来看成本高昂且脆弱的模式。

这些反模式源于以初创企业为中心的经验和客户洞察，但它们广泛适用于各种规模的公司。

将可观测性视为一次性项目

将可观测性定位为有明确结束日期的有限项目，会导致 dashboard 过时、告警不对齐或静默、以及在引入新服务、环境和 AWS 账户时覆盖不完整。可观测性必须作为一种持续性能力来管理，定期审查并进行与架构演进、部署模式以及不断变化的业务和合规要求相关的迭代增强。

未遵循分阶段的渐进式方法

在早期设计高度复杂的可观测性技术栈——例如多区域、多租户的遥测管道，包含大量自定义的数据丰富和路由功能——会在没有证明业务价值的情况下引入显著的运维开销和认知负担。初创企业应首先建立一个最小但健壮的 metrics、logs、traces 和服务级告警基线，然后随着工作负载复杂性和流量的增长，逐步引入高级功能。

在没有明确目标的情况下收集大量遥测数据

初创企业应定义明确的可观测性目标，将遥测数据收集范围限定在这些目标内，并应用采样、聚合和过滤策略来平衡监控深度与性能和成本。

在没有定义可观测性用例的情况下以全保真度摄取所有 logs、metrics 和 traces，会导致基数过高、查询性能下降以及存储和摄取成本高企，尤其是在高吞吐量的 AWS 工作负载中。例如，减少或过滤非必要的标签（如粒度请求 ID 或动态用户标识符）有助于控制基数。这不仅降低了摄取和存储费用，还加速了查询并简化了 dashboard，使可观测性在系统扩展时更加可持续。

过早锁定单一可观测性供应商

在早期阶段将插桩库、数据模式和 runbook 耦合到单一可观测性供应商会增加迁移风险，同时也限制了随着数据量增长的成本和架构灵活性。

为保持技术和经济选择的灵活性，初创企业应从一开始就使用遵循 OpenTelemetry 等开放标准进行插桩和数据传输的托管服务。他们应采用可移植的遥测模式，并保留将数据发送到多个或替代后端的选项。这种灵活性允许在早期轻松切换到更具成本效益的选项，并使得在规模和预算变化时更容易重新设计、分层或多样化可观测性工具。

通过使用 OpenTelemetry SDK 和 exporter 发出 metrics、logs 和 traces，服务可以将相同的遥测流发送到 Amazon CloudWatch 或 Application Signals，并在需要时通过更改 collector 或 exporter 配置而非应用程序代码将其发送到另一个后端。例如，使用 OpenTelemetry 进行插桩的结账服务可以将 OpenTelemetry 数据发送到 AWS Distro for Open Telemetry collector，该 collector 将数据分发到 CloudWatch 用于日常运维，同时发送到备用 endpoint 用于专门的长期存储（如 Amazon S3），使初创企业能够在不被锁定于供应商 API 和技术以及大规模重新插桩工作的情况下发展其可观测性架构。

采用以工具为中心而非以文化为中心的可观测性模型

仅仅启用 Amazon CloudWatch、AWS X-Ray 或第三方 APM（Application Performance Monitoring）集成等服务和功能，而工程团队不主动对代码路径进行插桩并在工作流中使用遥测数据，并不能产生有效的可观测性。工程团队必须将可观测性融入开发和运维实践——定义和拥有健康信号、将 dashboard 和告警嵌入事件响应和 runbook 中、并使用遥测数据来指导设计、容量规划和事后回顾。

缺乏遥测和元数据标准的治理

允许每个团队独立定义 metric 名称、标签集、log 格式和 trace 属性会产生分散的数据集，难以跨服务和环境进行连接、查询和关联。组织应建立并执行遥测治理，包括标准化的命名约定、必需的维度（如服务、环境、区域和租户）以及通过通用库和模板实现的共享模式。

忽视以客户为中心和用户体验指标

主要关注 CPU、内存和磁盘 metrics 等基础设施级信号，而忽略以用户为中心和业务 KPI，会掩盖事件对客户的实际影响。例如，一个 API 可能在主机级别看起来健康，而客户却因关键流程（如电子商务应用中的结账或注册）上的延迟升高、超时或错误率增加而体验到降级的服务。这些信号应作为与用户体验相关的一等服务和业务级 SLO 进行建模。

缺乏已定义的数据保留和分层策略

依赖 logs 和 metrics 的默认或无限保留会导致存储和分析成本不可控增长，并可能随时间推移降低查询和 dashboard 的性能。初创企业应按遥测类别定义分层保留策略——例如，短期高分辨率数据用于事件响应，降采样或聚合的 metrics 用于长期趋势分析，以及生命周期规则用于按照监管、运维和成本要求归档或清除过时数据。