指标、日志、链路三个支柱，加上托管与自建的取舍。

一、自建栈

Elastic Stack

Elastic Stack 以 Elasticsearch 存搜索与日志，Kibana 做可视化，Beats / Elastic Agent 采集，必要时用 Logstash 做复杂转换。典型用途是集中日志、指标和安全事件检索。

索引生命周期要设计好滚动和保留，否则磁盘会被热数据撑满。映射（mapping）一旦定错，后续聚合会很痛。权限用角色限制索引前缀。采集端先过滤敏感字段。集群至少关注主节点、磁盘水位和 JVM 内存。版本升级要看许可证变化。它很强，但不是万能数仓，明细分析量大时仍应分流到专用分析存储。

OpenTelemetry

OpenTelemetry 提供统一的 traces、metrics 和 logs 数据模型与 SDK，应用埋点后可由 Collector 导出到后端。目标是换观察性产品时不必重写埋点。

采样策略决定成本和完整度。上下文传播要穿过网关和消息队列，否则链路会断。资源属性（服务名、版本、环境）必须规范，否则看板无法聚合。

先覆盖入口和下游调用，再补业务事件。高基数标签会把指标存储打爆。用示例 trace 做回归，发布后对比错误率和延迟分布，而不是只看探针是否存活。

二、托管与架构

阿里云ARMS

阿里云 ARMS 是应用实时监控服务，覆盖 APM、前端监控、Prometheus 托管和告警。Java 应用通常通过探针采集接口耗时、SQL、JVM 指标和调用链。控制台能从接口下钻到单次 Trace，再看到慢 SQL 或外部依赖。它适合已经把应用放在阿里云上、不想自建整套可观测栈的团队。

接入后先定义黄金指标：错误率、饱和度和延迟分位。告警要按服务而不是按主机，并配上值班人。采样率太高会费流量，太低会漏偶发慢查询。自定义埋点只打业务关键路径。和日志、基础设施监控对齐 traceId，才能从一条用户投诉串到容器。定期清理无用仪表盘，避免监控本身变成无人维护的第二套系统。

APM系统

APM 监控应用的黄金指标：延迟、流量、错误、饱和度，再下钻到链路与代码热点。常见实现是探针插桩（Java Agent）上报 span，配合指标与日志。SkyWalking、Pinpoint、OpenTelemetry 是常见选择。

Android 上有 Firebase Performance、自研启动/卡顿/网络监控。采样率与隐私要设计好，避免把 PII 打进 span。告警应对 SLO 而不是原始均值。

落地先覆盖入口与数据库/HTTP 客户端。基数过高的 tag 会撑爆存储。本地调试可关探针。评估开销：CPU 与方法耗时偏差。与日志、度量构成可观测三支柱。

三、日志

日志系统

日志系统把分散在主机和容器里的事件收集、解析、存储并检索。采集侧用文件或 stdout，传输用缓冲队列，存储用索引或对象存储冷热分层。没有统一的 traceId，排障仍要登录一台台机器。

级别、采样和脱敏要在源头做。调试日志进生产会把磁盘和费用打爆，密码和证件号必须剔除。保留策略按合规和成本设，热数据几天，冷数据压缩归档。

告警不要直接绑每一条 ERROR，先聚合再阈值。仪表盘看错误率、延迟和饱和度。写入失败要有本地兜底，避免日志链路故障时业务进程被堵住。