上个月帮一个做 AI 笔记类 App 的朋友排查线上问题用户反馈“AI 回答越来越慢”但后台错率低得离谱崩溃统计和日志干净得让人心虚。我排查了整整一天最后是在接入监控后的第一条链路里找到了答案——第三方模型服务在部分网络环境下触发了超时重试客户端却在傻傻盯着 Future 等结果。这件事之后我彻底改了一个判断给 Flutter 应用接上 AI 能力之后传统以“崩溃率”为核心的监控已经不够用了。你需要把一次会话、一次生成、一次流式响应、一次渲染卡顿串起来看而这恰恰是 OpenTelemetry 这套规范最擅长的事。在 Dart/Flutter 生态里我目前最推荐的方式就是用 Dartastic 这个社区客户端把 OpenTelemetry 接进应用。这篇文章会讲清楚为什么用、怎么落地、以及 AI 场景下有哪些监控指标值得特殊照顾。1. AI 时代 Flutter 应用的监控逻辑到底哪里变了1.1 崩溃率不再是主要矛盾慢和错才是传统移动端监控的思维惯性是“只要不崩就是好的”。但 AI 功能进 Flutter App 之后用户的糟糕体验几乎不依赖崩溃来触发模型服务返回 5xx 或限流客户端可能只是转圈后报“网络错误”流式响应中途断掉App 不崩但对话停在半句首 Token 延迟TTFT过高用户只觉得“AI 在思考”其实已经等了几秒上下文超长导致请求体过大用户无感知但每次请求都在默默烧钱。这些问题的共同点是不会触发系统崩溃但会直接决定用户是否卸载应用。只靠崩溃率和日志关键词你几乎没办法把“用户说 AI 很慢”这个模糊反馈映射到具体是哪一次调用、哪一个环节、哪一段网络出了问题。OpenTelemetry 的价值恰恰在这里——它把一次完整请求拆成多个带父子关系的 Span每个 Span 记录开始时间、耗时、状态和关键属性。一旦用户反馈“慢”你按 traceId 拉出整条链路就知道时间损耗是发生在模型请求上、网络传输上、还是本地解析大 JSON 上。1.2 LLM 让应用出现了“第三个运行时”过去 Flutter 应用的运行时模型是两层客户端和你的后端。客户端出问题你查 Flutter 侧后端慢你查服务端日志。现在接入 LLM 之后中间多了一个基本不受你控制的“模型运行时”。它不像自建后端那样能随时打点、埋日志、看监控大盘。它是一个黑盒你能观察到的只有你发出的 HTTP 请求的入参和出参网络层的耗时、重试状态码Token 消耗数据不同模型版本在不同输入下的行为差异。而这些数据天然分布在不同层Dart 侧、Dio 拦截器里、平台通道里、模型服务商的控制台里。如果不做标准化采集你手上就是一堆孤岛数据。把 LLM 调用也当作 Span 接入统一的 Trace 链路之后黑盒就被打开了——至少你能明确边界是“模型本身慢”还是“链路有瓶颈”。1.3 这套方案适合谁如果你满足以下任意一条我觉得 Dartastic OpenTelemetry 值得你花半天时间认真接一下你的 Flutter App 已经接了 ChatGPT、Claude、通义、文心之类的大模型能力但线上反馈问题只能靠用户截图和客服转述你已经有后端在用 OpenTelemetry想打通“客户端到服务端再到模型服务”的完整 trace你对 Sentry、Firebase Analytics 这类闭源、绑定厂商的监控方案不满意想要能自托管、数据结构可迁移的方案你是个人开发者追求低成本排查问题愿意用一套标准协议换未来多个项目的监控能力复用。如果是纯静态展示类 Flutter 应用不接 AI、没有复杂网络依赖那这套方案可能有点重。但只要你开始接触 LLM 相关能力我强烈建议别等出问题再补。2. 为什么选择 Dartastic它不是“又一个监控库”2.1 OpenTelemetry 在 Dart 侧的现状OpenTelemetry 官方在 Dart 语言上的推进一直不算快。opentelemetry-dart 仓库还存在但长期处于维护不活跃状态普通应用直接用官方包的体验并不好。Dartastic 是目前社区里相对成熟的选择。它不是另起炉灶定义一套新标准而是把 OpenTelemetry 的 API 语义用 Dart 的方式实现了一遍所以你在网上看到的大量关于 OpenTelemetry 概念Span、Trace、Metric、Exporter的文章都能直接迁移到 Flutter 项目里使用知识不浪费。这里有一个容易踩的认知误区很多人以为 Dartastic 只是“又一个崩溃监控 SDK”。其实它不是它的目标是把 OpenTelemetry 的 tracing、metrics、logging 三部分能力都覆盖而不是只盯着 crash。它更像是一个“可插拔的观测框架”底层数据格式符合 OTLP 协议理论上可以接任何支持 OTLP 的观测后端。2.2 与其他监控方案的对比我实际对比过几条路线列个表格供参考方案数据协议自托管能力与后端链路打通采集自由度我眼中的适用场景Sentry私有协议需自建 Sentry 实例有限主要靠手动关联中以错误和性能为主团队已经有 Sentry 全家桶Firebase Performance / Analytics私有协议不支持基本不打通低黑盒采样全家桶铁粉自研埋点上报自定义 JSON可要自己设计协议高但全得自己写有专门基建团队Dartastic OpenTelemetryOTLP 标准可后端组件全开源天然打通高API 覆盖 trace/metric/log想要一套长期可演进的监控体系真正让我选 Dartastic 的理由有三个第一标准协议的价值是长期的。OTLP 是云原生基金会旗下的标准后端可替换、可视化工具可替换唯独上报协议是通用的。你未来换监控平台客户端代码几乎不用动。第二Trace 与 Metric 可以来自同一套埋点。我可以在一个 Span 上记录耗时、状态、token 数再通过 SpanProcessor 把这些数据转成 metrics不需要写两套埋点逻辑。第三生态贴合 Dart 的异步模型。普通开发者写 Flutter 监控最痛苦的就是 Future 和 async 函数里的上下文传递Dartastic 在 API 设计上考虑了这种情况文档里的示例也都是围绕 Flutter 场景展开的比官方 SDK 的纯 Dart 示例更接地气。2.3 为什么不是等官方 SDK 完善后再接这是我在社区里被问得最多的问题。我的看法是可观测性基建和业务代码不一样它存在“数据积累周期”。你越早接上线上就越早有历史基线数据。等出线上事故再接入你连“以前正常的时候什么样”都不知道。Dartastic 现在虽然在快速迭代但基本概念已经稳定协议也是标准化的哪怕以后切换到官方 SDK迁移成本也远小于从零开始。3. 先对齐概念四个核心 API 搞懂后再动手3.1 Trace、Span 和 TracerProvider 到底是什么关系很多 Flutter 开发者第一次看到 OpenTelemetry 文档会懵因为里面术语太多。我常用一个快递的类比来解释Trace就像一次完整的寄件过程从你下单、快递员取件、运输、派送一直到签收Span是其中每个环节的单据每个单据记录了这一步的名称、开始时间、结束时间、状态和备注Tracer是负责开单据的人你让它 startSpan 它就给你开一张新单据TracerProvider是快递公司它统一管理所有开单人并且决定这些单据最终交给谁Exporter。所以你要做的第一件事就是先搞一个 TracerProvider然后在需要观测的代码位置调用 tracer.startSpan()。Span 结束时要调用 end()否则它不会出现在后台面板上。3.2 Span 上要放哪些属性刚开始时我犯过一个典型错误只在 Span 上放耗时和状态其他信息全丢。这就浪费了 Span 的另一个价值——上下文属性。推荐至少记录四类信息基础标识操作名称、服务名、操作类型如 http / db / llm关联数据请求 URL、方法、状态码、错误信息方便点进去直接定位业务数据用户会话标识、业务订单号方便对应用户反馈可量化数据token 数、字节数、重试次数、优先级等后续可以转成指标。我见过不少团队把 Span 理解成“计时器”只记耗时。这样你缺少了关联维度后期做分析时没法按模型版本、按用户群体、按网络类型切分可观测性的价值大打折扣。3.3 Metric 与 Log 不能缺席Trace 解决的是“某一次请求到底发生了什么”Metric 解决的是“整体趋势如何”Log 解决的是“报错时的现场细节”。三者配合才是完整可观测性。在移动端场景我的建议是Trace用于线上疑难杂症定位请求级别的精细数据Metric用于监控大盘和告警比如 P50/P95/P99 延迟、Token 消耗速率、错误率、活跃用户使用的模型分布Log用于关键业务事件如登录、付费和异常现场的额外上下文输出。不要指望每一个崩溃现场都靠日志去还原把日志和 traceId 做关联用日志里的 traceId 反查整条链路才是高效的做法。4. 从零接入Flutter 项目里的初始化步骤4.1 初始化 TracerProvider我先说一个基本结论不要在 build 方法里初始化监控环境也不要在异步函数里偷偷初始化。监控 SDK 需要在整个业务代码执行之前就绪否则早期 span 会丢。比较稳妥的位置是在 main() 函数的最前面而且在 runApp() 之前完成初始化void main() { WidgetsFlutterBinding.ensureInitialized(); // 创建 OTLP gRPC Exporter指向本地 Collector final exporter OtlpGrpcExporter( endpoint: http://10.0.2.2:4317, // Android 模拟器访问宿主机 ); // 创建 TracerProvider设置采样率避免全量上报 final tracerProvider TracerProvider( sampler: ParentBasedSampler( rootSampler: TraceIdRatioBasedSampler(0.1), // 10% 采样 ), ); // 注册 BatchSpanProcessor批量导出 tracerProvider.addSpanProcessor( BatchSpanProcessor(exporter), ); runApp(const MyApp()); }这里的代码是基于我当前使用的版本写的Dartastic 还在快速迭代不同版本的具体类名和导入路径可能略有差异一定要以你依赖的版本 README 为准。重点不是死记 API而是理解这一步做了三件事准备好出口Exporter、设定采样策略Sampler、注册批处理管道Processor。按官方文档初始化完成后通常还需要把 tracerProvider 存到一个全局可见的地方或者通过依赖注入传递。我在项目里习惯用一个简单的工具类来持有class Otel { static late TracerProvider provider; static Tracer get tracer provider.getTracer(my_flutter_app); }这样在业务代码的任何位置都能直接Otel.tracer.startSpan(...)不用走 BuildContext也不容易被界面生命周期干扰。4.2 接入导出管道Exporter接入导出管道有两种常见姿势。一种是 App 直接把数据发到远端的 OpenTelemetry Collector 或者云服务商的 OTLP 端点另一种是 App 先发到本机 Collector再由 Collector 统一转发。移动端场景我强烈推荐第二种原因后面专门讲。你现在只需要知道Exporter 的 endpoint 通常填 Collector 的地址。如果是在 Android 模拟器里调试宿主机地址是http://10.0.2.2:4317真机调试就需要填局域网 IPiOS 模拟器直接用localhost也可以。4.3 验证初始化是否成功接入后的第一个小时最容易出问题你以为接好了其实数据根本没出去。我给自己定了一套快速验证流程在 main() 里加一段手动 Span标记为 “startup”用浏览器打开 Collector 的 metrics 端口确认收到请求在一台 Android 真机和一个 iOS 真机上分别跑一次排除平台网络权限问题确认 Android 的 INTERNET 权限、iOS 的本地网络权限都配好。这里要特别提醒Android 9 默认禁止明文 HTTP 流量。如果你用的是 http 而不是 https 访问本机 Collector需要在 AndroidManifest 里加上android:usesCleartextTraffictrue或者配置 networkSecurityConfig 放行指定域名。否则你会在代码里看到数据似乎发出去了但 Collector 端一个包都没收到。5. 三种插桩方式怎么选自动、手动、拦截器5.1 自动插桩能省则省Dartastic 目前的自动插桩能力不像 Java 生态那么强。Java 里那套通过字节码注入实现的自动采集在 Dart 侧没法完全复刻。你能指望的自动插桩主要是框架层提供的一些便捷方法以及部分包自带的 instrumentation。我的经验是不要为了“自动”而自动。自动埋点容易成为黑盒你根本不知道它创建了哪些 Span、这些 Span 的属性是什么、是否有冗余数据。反而是手动埋点虽然工作量稍微大一点但每个 Span 的含义你心里完全有数排查问题时更放心。5.2 手动埋点核心链路必须手工覆盖所有你关心的业务关键路径都值得手动埋点。我习惯先列一张清单把核心链路画出来再对应加 Span冷启动完成后首帧渲染耗时AI 会话发送消息的完整流程登录/鉴权流程关键页面 Tab 切换支付等关键转化步骤。手动埋点的代码长这样FutureString askAi(String question) async { final span Otel.tracer.startSpan(ai.ask_question); span.setAttributes({ user_type: userType, question_length: question.length, }); try { final result await _api.send(question); span.setStatus(StatusCode.ok); return result; } catch (e) { span.setStatus(StatusCode.error, description: e.toString()); rethrow; } finally { span.end(); } }这里有一个非常容易被忽略的细节一定要用 finally 调用 span.end()。如果中间抛了异常但你不调用 end()这个 Span 会一直不关闭上报时会被当作超长 Span直接影响延迟统计。刚开始接监控的团队十有八九会在异步链路里漏掉 finally。5.3 HTTP 拦截器网络请求全自动记录网络请求是最值得自动采集的一类 Span因为 Flutter 项目里的 HTTP 调用往往集中通过 Dio 或 HttpClient。给 Dio 加一个拦截器就能覆盖 App 里绝大多数外部依赖调用class OtelDioInterceptor extends Interceptor { override void onRequest(RequestOptions options, RequestInterceptorHandler handler) { final span Otel.tracer.startSpan(http.request); span.setAttributes({ http.method: options.method, http.url: options.uri.toString(), http.request.body: options.data?.toString().substring(0, 200) ?? , }); options.extra[otel_span] span; handler.next(options); } override void onResponse(Response response, ResponseInterceptorHandler handler) { final span response.requestOptions.extra[otel_span] as Span?; span?.setAttribute(http.status_code, response.statusCode ?? 0); span?.setStatus(StatusCode.ok); span?.end(); handler.next(response); } override void onError(DioException err, ErrorInterceptorHandler handler) { final span err.requestOptions.extra[otel_span] as Span?; span?.setStatus(StatusCode.error, description: err.message); span?.end(); handler.next(err); } }拦截器这个方案我建议尽早接上。它不仅能观测到业务自己发的请求还能顺带覆盖到第三方 SDK 内部走的 HTTP 调用前提是它们复用了同一个 HttpClient。有些 AI 相关的 SDK 内部会单独维护一个 HttpClient这时候拦截器就拦不到。遇到这种情况可以退回到在 SDK 的返回 Future 外面手动包一个 Span或者在 SDK 初始化的地方尝试传入一个共享的 HttpClient。6. 数据出去之后Otel Collector 与开源后端的组合实践6.1 为什么不能 App 直发远端后端一开始最容易想到的做法是 App 端直接把数据 POST 到某个云服务商提供的 OTLP 端点。但实际跑下来你会发现一堆问题移动网络不确定性高App 直发容易超时、丢失还影响用户流量如果是自建后端安全上要暴露公网端口容易被扫描攻击客户端如果本地攒了大量 trace批量上传时可能瞬间打满带宽没法统一做数据格式处理、过滤、脱敏、重采样。所以移动端标准做法是App 先发给本机/内网的 OpenTelemetry Collector由 Collector 统一处理后转发给时序数据库或云平台。Collector 可以帮你做数据缓冲、重试、脱敏、采样还能把 traces 同时发给多个后端比如 Tempo 用于链路、Prometheus 用于指标、Loki 用于日志。这是一个非常经典的组合OpenTelemetry Collector 作为入口统一接收 OTLP 数据Tempo 存储和查询 tracePrometheus 或 VictoriaMetrics 存储 metricsLoki 收集日志Grafana 负责可视化。这套栈全开源、可自托管社区资料也多。6.2 Collector 配置的最小可用示例下面是我在本地 Docker Compose 里跑的一个最小配置足够支撑 Flutter 端调试receivers: otlp: protocols: grpc: endpoint: 0.0.0.0:4317 processors: batch: timeout: 5s send_batch_size: 1024 exporters: otlp/tempo: endpoint: tempo:4317 tls: insecure: true prometheus: endpoint: 0.0.0.0:8889 loki: endpoint: http://loki:3100/loki/api/v1/push service: pipelines: traces: receivers: [otlp] processors: [batch] exporters: [otlp/tempo] metrics: receivers: [otlp] processors: [batch] exporters: [prometheus] logs: receivers: [otlp] processors: [batch] exporters: [loki]把它跑起来之后Flutter App 端的 exporter endpoint 指向 Collector 的 4317 端口即可。调试阶段可以用docker compose logs看 Collector 是否收到数据通常第一次调通之前都需要看这里的日志来定位问题。6.3 移动端必须做采样策略全量上报在移动端几乎是不可行的。移动设备数量大、单次会话 span 数多全量上报既消耗流量也白白增加后端存储成本。我个人项目里的做法是按根 Span 采样 10%特殊场景比如支付失败、AI 会话报错强制 100% 记录。OpenTelemetry 的采样策略支持在登录、支付等关键业务链路上单独提高采样率不需要全局统一。这个在初始化 TracerProvider 的时候可以通过配置自定义 sampler 实现。如果你一开始不知道配多少先全局 10% 跑一周再看看数据量是否可接受再渐进调整。6.4 关注采样对 AI 场景的影响AI 场景有个特殊性一次用户对话可能涉及到若干个模型请求如果按 10% 采样可能丢掉大量有价值的对话。这时候我建议单独为 LLM 相关链路配置更高的采样率甚至 100% 采集同时把非关键页面级 span 降到更低的采样率。核心思路是把宝贵的采样预算花在业务价值观测点上。7. AI 功能专项观测把 LLM 调用变成一条可追踪的链路7.1 LLM 调用的关键观测指标结合我自己的排查经验LLM 集成场景至少要观测这几个指标缺一个都会让你在问题面前变成盲人调用延迟特别是第一次输出字节的时间TTFT和完整响应时间Token 消耗输入 token、输出 token以及是否触发上下文截断模型与参数用的什么模型名、temperature 等参数方便对比版本差异错误与重试限流429、超时408、内部错误500及其重试次数用户会话关联traceId 关联 sessionId这样能复现同一个用户的完整交互历史。这些指标最好在同一个 Span 里同时记录下来这样后续既可以用 trace 看单次请求细节也可以用 metrics 看整体统计。7.2 给 LLM 调用包装统一的 Span我习惯写一个统一的 LLM 调用包装函数所有 AI 模块都通过它下发请求这样埋点不会漏class LlmClient { final Tracer _tracer; FutureString complete({ required String prompt, required String model, MapString, dynamic? params, }) async { final span _tracer.startSpan(llm.completion); span.setAttributes({ llm.model: model, llm.prompt_length: prompt.length, llm.params: params?.toString() ?? , }); final stopwatch Stopwatch()..start(); try { final response await _provider.chat( messages: [{role: user, content: prompt}], model: model, ); span.setAttributes({ llm.completion_tokens: response.usage?.completionTokens ?? 0, llm.prompt_tokens: response.usage?.promptTokens ?? 0, llm.total_tokens: response.usage?.totalTokens ?? 0, llm.tokens_per_second: computeTokensPerSecond(response), }); span.setStatus(StatusCode.ok); return response.text; } catch (e) { span.setStatus(StatusCode.error, description: e.toString()); rethrow; } finally { span.end(); } } }这里记录tokens_per_second其实是很有用的一个手段。只看总耗时没法判断是模型生成慢还是网络传输慢但结合 token 数和耗时能算出每秒生成速度遇到“输出很慢”的用户反馈时你能直观地判断模型服务本身是否降速了。7.3 从数据里发现真实问题的一个案例我之前在一个 AI 聊天 Flutter App 里接完这套监控后发现了一个很有意思的现象某个用户群里P95 的 TTFT 达到了 4.8 秒但 P50 只有 900 毫秒。按照正常的排查思路先怀疑网络再怀疑模型服务但 trace 数据显示问题出在客户端在等待流式响应的首包时底层 gRPC 连接因为长连接空闲被服务端断开客户端自动重建连接重建的过程中丢了几秒。如果没有 trace 把“socket disconnect”、“reconnect”、“waiting for first token”这几个 Span 串起来这个问题靠日志几乎不可能定位。后来我们在客户端加了连接预热、缩短过期时间、调整了 KeepAlive 参数P95 直接降到了 1.2 秒。这就是监控链路带来的实打实的优化收益。7.4 Token 成本与用量监控Token 消耗不仅是性能问题更是钱的问题。AI 功能的成本跟用户对话深度直接挂钩用户话越多、上下文越长每次请求的输入 token 就越多。如果不监控月底账单出来才发现成本翻倍就晚了。我的做法是把 token 用量作为 metric 上报在 Grafana 里按用户、按模型版本、按日期做聚合。哪天 token 消耗突然飙升就能快速定位是哪个版本上线、哪类用户行为导致。这比看云厂商后台的账单报表要前置得多。8. 我踩过的坑和最后的建议8.1 与其他 Flutter 插件的初始化顺序很多监控类插件包括性能监控、崩溃上报都要求在 main() 之前做 Initialize。Dartastic 也一样。我遇到过一次混乱的初始化顺序问题某个性能插件在 main() 里先初始化了导致 Dartastic 的 TracerProvider 创建时拿不到完整的系统上下文某些 span 的属性是空的。解决方案很简单在 main() 的最顶部先初始化 Dartastic再初始化其他插件。如果用到WidgetsFlutterBinding.ensureInitialized()也放在最前面。8.2 并发与 Isolate 的上下文传播Flutter 的多 Isolate 环境对 OpenTelemetry 传播不友好。你不能保证一个 Span 在 Isolate A 里创建之后在 Isolate B 里还能通过同一个 Context 继续。我在实际项目里碰到过后台 isolate 里执行耗时的数据处理外层 span 已经结束里层的子 span 因为父 span 已经 close导致在 Tempo 里出现了悬空 span。处理办法是跨 isolate 传递 traceId、spanId 等必要参数在目标 isolate 里手动重建 Context或者尽量避免在 isolate 里开启需要父子关系的子 span直接作为独立 root span 处理。你要在架构设计时就想好哪些逻辑必须走 isolate否则后面改起来非常痛苦。8.3 导出阻塞与背压问题如果 Exporter 使用的是同步方案而网络不稳定会导致应用 UI 卡顿。我在 Android 低端机上实测过使用阻塞式导出时一个失败的 OTLP 请求能卡住 UI 数百毫秒。解决办法有两个一是使用 BatchSpanProcessor让导出跑在独立线程里以队列方式消费 span二是在导出失败时做退避重试不要立即重试风暴。Dartastic 默认的 BatchSpanProcessor 已经做了这些事但要注意别在初始化时手滑配成同步的 SimpleSpanProcessor。如果你关注内存也要给批处理队列设上限防止内存被 span 堆满。8.4 低端 Android 设备上的表现这里单独说一下低端机的性能影响。移动端监控 SDK 最容易被诟病的就是“监控比业务还卡”。我的实际体验是Span 对象的创建是轻量的不用太担心真正有开销的是属性值如果塞入超长字符串比如把整个响应体塞进去内存和网络都会吃紧尽量只记录关键属性的截断值一两百字符足够排查问题采样率要结合内存占用调整不要拍脑袋写 100%。一个更实际的问题如果你想给 span 记录文件路径、堆栈这类信息在低端机上获取堆栈本身是有代价的。建议放到采样链路上仅在错误或慢请求时记录。8.5 从“能跑”到“好用”最后分享一点个人经验。把 Dartastic 接入 Flutter 项目并不是终点真正的终点是形成一套“先看大盘、再下钻链路、最后定位代码”的排查习惯。技术债最重的往往不是集成本身而是分析链路不成熟导致数据接进来却没人看。我的习惯是新功能上线前先花半小时在 Grafana 上配置好对应的看板把核心指标成功率、延迟、token 消耗固定下来每两周复盘一次数据不是为了写报告而是建立一种对“正常情况长什么样”的直觉。等线上真的出问题时你才能第一时间意识到哪里偏离了基线。如果你现在已经在为 AI 功能接入 Flutter 之后的“不确定行为”头疼我希望这篇内容能帮你省掉几天弯路。监控不是玄学它是把黑盒一点点变白的过程。