深入解析 Effect OpenTelemetry 日志时间戳修复统一时钟源解决日志早于父 Span 的时序错乱问题【免费下载链接】effectBuild production-ready applications in TypeScript项目地址: https://gitcode.com/GitHub_Trending/ef/effect本篇文章围绕 effect 仓库中的补丁文档 fix-otel-logger-clock-skew.md 展开深入剖析effect/opentelemetry包中日志与追踪时间戳不一致的根因、修复方案、源码实现与测试验证。读完本文你将理解为什么日志记录可能跑在其父 Span 之前、如何通过统一使用 Effect 的 Clock 服务消除时钟漂移以及如何在真实项目中验证与规避同类问题。一、问题背景日志时间戳为何会早于父 Span在 OpenTelemetry 的观测体系中Trace 与 Log 是两个独立的数据管道但它们通过traceId/spanId关联在一起。可观测性平台如 Jaeger、Grafana、OTLP 后端在渲染 Trace 视图时会将日志按时间戳插到对应的 Span 时间轴上。如果日志记录的时间戳早于其父 Span 的开始时间就会出现日志出现在 Span 之前的乱序现象破坏故障排查时的因果链判断。补丁文档 fix-otel-logger-clock-skew.md 记录的就是这一问题的修复Use the Effect wall clock for log timestamps to match span timestamps.The Logger usedDate.now()directly for logtimestampwhile the Tracer usedclock.currentTimeNanosUnsafe()for spanstartTime. These could diverge when the high-resolution wall-clock origin drifted, causing logs to appear before their parent span. Both now use the same Effect wall clock viananosToHrTime(clock.currentTimeNanosUnsafe()).该变更以effect/opentelemetry: patch的形式发布属于修复性补丁不会引入破坏性 API 变更。二、根因剖析两条独立时钟路径的漂移2.1 修复前的两条时间来源从源码结构看修复前effect/opentelemetry的日志与追踪分别走了两条不同的时间获取路径数据管道修复前的时间来源语义Logger日志记录options.date.getTime()即Date.now()语义毫秒级 wall-clock 读数TracerSpanclock.currentTimeNanosUnsafe()纳秒级 Unix 时间读数在 OtelLogger.ts 的make构造器中options.date来自 Effect Logger 框架注入的 Date 实例本质上就是系统墙钟时间而 Tracer 一侧OtelTracer.ts 中的OtelSpan从 Effect 的Clock服务读取currentTimeNanosUnsafe()。2.2 为什么两者会漂移关键差异在于Date.now()与 EffectClock内部的高精度 wall-clock 实现可能基于不同的时钟源或校准原点。系统墙钟并非恒定不变操作系统可能通过 NTP 等协议对系统时间进行校正导致时间跳变虚拟机 / 容器环境下宿主机与虚机的时钟源校准机制不同会产生持续漂移高分辨率时钟如基于performance/process.hrtime校准的实现在初始化时记录了一个原点若该原点与Date.now()的墙钟读数不一致后续换算出的时间就会系统性偏移。当两条路径的墙钟读数产生毫秒级甚至更小的偏差时恰好处于 Span 生命周期边缘的日志记录就可能被贴上早于startTime的时间戳在 Trace 视图中表现为日志穿越到 Span 之前。三、修复方案统一收敛到 Effect Clock补丁给出的修复思路非常直接——不再让 Logger 与 Tracer 各自取时而是让两者都从同一个Clock服务读取纳秒级 wall-clock 时间再统一转换为 OpenTelemetry 的HrTime格式nanosToHrTime(clock.currentTimeNanosUnsafe())3.1 为什么选currentTimeNanosUnsafe()查看 Clock.ts 的服务定义可知currentTimeNanosUnsafe()返回当前 Unix 时间纳秒属于wall-clock 语义与 Span 开始时间、日志时间戳在时间轴上天然可比它返回bigint纳秒精度远超Date.now()的毫秒精度它由Clock服务提供可通过Effect.provideService(Clock.Clock, ...)在测试中替换为可控时钟Unsafe后缀表示同步读取非 Effect 包装适合在日志回调这种同步场景中使用。值得注意的是Clock.ts 的 JSDoc 明确提示currentTimeNanosUnsafe()的值在系统墙钟被校正时可能前后移动不适用于测量经过的时间——这正说明它应该用于时间戳标记而测量耗时则应使用monotonicTimeNanos。本次修复正是把它用在时间戳这个正确场景上。3.2nanosToHrTime的格式转换OpenTelemetry 的时间戳标准格式为HrTime即[seconds, nanoseconds]二元组。转换工具位于 internal/attributes.tsconst bigint1e9 BigInt(1_000_000_000) /** internal */ export const nanosToHrTime (timestamp: bigint): Otel.HrTime { return [Number(timestamp / bigint1e9), Number(timestamp % bigint1e9)] }实现将纳秒时间戳整除得到秒、取余得到纳秒精度无损地映射到 OTel 数据模型。四、源码级实现修复后的日志发射链路4.1 Logger 侧时间戳与 logSpan 分离修复后的 OtelLogger.tsmake构造器完整逻辑如下节选关键部分export const make: Effect.Effect Logger.Loggerunknown, void, never, OtelLoggerProvider Effect.gen(function*() { const loggerProvider yield* OtelLoggerProvider const clock yield* Clock.Clock const otelLogger loggerProvider.getLogger(effect/opentelemetry) return Logger.make((options) { // 关联当前 Fiber 与父 Span const span Context.getOrUndefined(options.fiber.context, Tracer.ParentSpan) if (Predicate.isNotUndefined(span)) { attributes.spanId span.spanId attributes.traceId span.traceId } // 计算 logSpan 相对耗时毫秒 const now options.date.getTime() for (const [label, startTime] of options.fiber.getRef(References.CurrentLogSpans)) { attributes[logSpan.${label}] ${now - startTime}ms } // 统一使用 Effect Clock 生成时间戳 const hrTime nanosToHrTime(clock.currentTimeNanosUnsafe()) otelLogger.emit({ body: message.length 1 ? message[0] : message, severityText: options.logLevel, severityNumber: logLevelToSeverityNumber(options.logLevel), timestamp: hrTime, observedTimestamp: hrTime, attributes }) }) })实现细节值得注意timestamp与observedTimestamp同源二者都使用nanosToHrTime(clock.currentTimeNanosUnsafe())保证日志的产生时刻与被观测时刻一致options.date并未被删除它仍然用于logSpan.*属性的相对耗时计算now - startTime。这是毫秒级的差值运算用于展示当前日志与 logSpan 起点的间隔不参与绝对时间戳的生成因此不受墙钟漂移影响Logger 从Clock.Clock服务取时钟通过Effect.gen中的yield* Clock.Clock获得意味着时间源完全由 Effect 运行时决定可被测试层替换。4.2 Tracer 侧Span 时间戳同样来自 Clock与之对应OtelTracer.ts 中的 Span 时间戳来源如下OtelSpan构造时以nanosToHrTime(options.startTime)作为tracer.startSpan的startTimeOtelTracer.ts其中options.startTime由 Effect Tracer 基于 Clock 生成Span 结束时以nanosToHrTime(endTime)结束end方法未显式传入时间时convertOtelTimeInput回退到clock.currentTimeNanosUnsafe()const convertOtelTimeInput (input: Otel.TimeInput | undefined, clock: Clock.Clock): bigint { if (input undefined) { return clock.currentTimeNanosUnsafe() } // number - Date - HrTime 元组的转换分支 }修复后Logger 与 Tracer 在同一进程内、同一 Effect 运行时读取同一个Clock服务实例时间源完全一致从根本上消除了双时钟漂移问题。五、测试验证用可控时钟证明时间对齐仓库在 OtelLogger.test.ts 中新增了针对性测试uses wall-clock timestamps and keeps them aligned with spans其核心手法是构造一个故意错乱的时钟来证明修复有效const wallTimeNanos 1_735_689_600_123_456_789n const monotonicTimeNanos 123_456_789n const skewedClock: Clock.Clock { currentTimeMillisUnsafe: () 1, // 故意返回一个荒谬的毫秒值 currentTimeMillis: Effect.succeed(1), currentTimeNanosUnsafe: () wallTimeNanos, // 纳秒时钟返回真实墙钟时间 currentTimeNanos: Effect.succeed(wallTimeNanos), monotonicTimeNanosUnsafe: () monotonicTimeNanos, monotonicTimeNanos: Effect.succeed(monotonicTimeNanos), sleep: () Effect.void }测试通过Effect.provideService(Clock.Clock, skewedClock)注入这个时钟让Date.now()路径毫秒1与 Clock 路径纳秒真实时间产生巨大分歧随后断言assert.deepStrictEqual(log.hrTime, expectedTime) assert.deepStrictEqual(log.hrTimeObserved, expectedTime) assert.deepStrictEqual(log.hrTime, span.startTime) assert.strictEqual(log.attributes.spanId, span.spanContext().spanId) assert.strictEqual(log.attributes.traceId, span.spanContext().traceId)关键断言是log.hrTime与span.startTime深度相等——只有二者都走clock.currentTimeNanosUnsafe()才能通过如果 Logger 仍使用options.date.getTime()日志时间戳将变成 1970 年初的 1ms测试立刻失败。这一用例同时验证了修复前后的行为差异也演示了在测试环境中通过替换Clock.Clock服务来模拟时钟漂移的标准手法。此外测试还覆盖了关联正确性does not let annotations overwrite active span correlation用例证明即使通过Effect.annotateLogs({ traceId: spoof-trace, spanId: spoof-span })伪造日志注解spanId/traceId仍以真实活跃 Span 为准避免污染关联关系。六、这一修复对你的应用意味着什么6.1 升级即可受益本次变更仅涉及effect/opentelemetry的日志时间戳内部实现属于 patch 级修复。若你的应用同时使用 OtelLogger.ts 的layer/layerLoggerProvider接入 OpenTelemetry 日志管道并配合 OtelTracer.ts 或 NodeSdk.ts 进行追踪升级后即可自动获得对齐的时间戳无需修改业务代码。6.2 一个完整的接入示例结合 OtelLogger.test.ts 中的用法一个同时启用日志与追踪的最小接入方式如下import * as NodeSdk from effect/opentelemetry/NodeSdk import { InMemoryLogRecordExporter, SimpleLogRecordProcessor } from opentelemetry/sdk-logs import { SimpleSpanProcessor } from opentelemetry/sdk-trace-base import * as Effect from effect/Effect const TracingLayer NodeSdk.layer(Effect.sync(() ({ resource: { serviceName: my-service }, spanProcessor: [new SimpleSpanProcessor(new InMemorySpanExporter())], logRecordProcessor: [new SimpleLogRecordProcessor({ exporter: new InMemoryLogRecordExporter() })] }))) const program Effect.gen(function*() { yield* Effect.log(业务日志).pipe(Effect.withSpan(parent-span)) }).pipe(Effect.provide(TracingLayer))通过NodeSdk.layer同时配置spanProcessor与logRecordProcessorEffect 日志与 Span 将在同一运行时内共享Clock服务时间戳天然对齐。6.3 排查与验证建议如果你在观测平台上仍观察到日志早于 Span 的现象可以按以下顺序排查确认版本检查effect/opentelemetry是否包含本次修复参考 CHANGELOG.md 中4.0.0-beta.11版本的记录检查时钟环境NTP 频繁校正、虚拟机时钟漂移严重的环境更容易触发此问题修复后已通过统一时钟源规避复现实验可仿照 OtelLogger.test.ts 的做法在测试中注入毫秒与纳秒读数严重不一致的Clock.Clock服务验证日志时间戳不再跟随Date.now()。七、延伸Effect Clock 的取舍与最佳实践本次修复本质上是 Effect 生态可替换服务 单一事实来源理念的一次实践。从 Clock.ts 的服务文档可以看出currentTimeMillis/currentTimeNanos系列是wall-clockUnix 时间用于时间戳标记与展示可能因系统校时发生跳变monotonicTimeNanos系列是单调时钟原点任意、只适合测量耗时不适合序列化传播所有时间读取都通过Clock服务间接完成因此在测试中可以用TestClock或自定义实现完全控制时间行为。对于集成层代码如 OpenTelemetry 桥接正确做法正是绝对时间戳统一取自Clock的 wall-clock 读数相对耗时统一取自同一时钟源避免在桥接边界重新引入Date.now()、process.hrtime等游离于 Effect 服务体系之外的时间源。这也是本次修复在 OtelLogger.ts 与 OtelTracer.ts 中落地的最佳实践范本。【免费下载链接】effectBuild production-ready applications in TypeScript项目地址: https://gitcode.com/GitHub_Trending/ef/effect创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 深入解析 Effect OpenTelemetry 日志时间戳修复：统一时钟源解决日志早于父 Span 的时序错乱问题
深入解析 Effect OpenTelemetry 日志时间戳修复统一时钟源解决日志早于父 Span 的时序错乱问题【免费下载链接】effectBuild production-ready applications in TypeScript项目地址: https://gitcode.com/GitHub_Trending/ef/effect本篇文章围绕 effect 仓库中的补丁文档 fix-otel-logger-clock-skew.md 展开深入剖析effect/opentelemetry包中日志与追踪时间戳不一致的根因、修复方案、源码实现与测试验证。读完本文你将理解为什么日志记录可能跑在其父 Span 之前、如何通过统一使用 Effect 的 Clock 服务消除时钟漂移以及如何在真实项目中验证与规避同类问题。一、问题背景日志时间戳为何会早于父 Span在 OpenTelemetry 的观测体系中Trace 与 Log 是两个独立的数据管道但它们通过traceId/spanId关联在一起。可观测性平台如 Jaeger、Grafana、OTLP 后端在渲染 Trace 视图时会将日志按时间戳插到对应的 Span 时间轴上。如果日志记录的时间戳早于其父 Span 的开始时间就会出现日志出现在 Span 之前的乱序现象破坏故障排查时的因果链判断。补丁文档 fix-otel-logger-clock-skew.md 记录的就是这一问题的修复Use the Effect wall clock for log timestamps to match span timestamps.The Logger usedDate.now()directly for logtimestampwhile the Tracer usedclock.currentTimeNanosUnsafe()for spanstartTime. These could diverge when the high-resolution wall-clock origin drifted, causing logs to appear before their parent span. Both now use the same Effect wall clock viananosToHrTime(clock.currentTimeNanosUnsafe()).该变更以effect/opentelemetry: patch的形式发布属于修复性补丁不会引入破坏性 API 变更。二、根因剖析两条独立时钟路径的漂移2.1 修复前的两条时间来源从源码结构看修复前effect/opentelemetry的日志与追踪分别走了两条不同的时间获取路径数据管道修复前的时间来源语义Logger日志记录options.date.getTime()即Date.now()语义毫秒级 wall-clock 读数TracerSpanclock.currentTimeNanosUnsafe()纳秒级 Unix 时间读数在 OtelLogger.ts 的make构造器中options.date来自 Effect Logger 框架注入的 Date 实例本质上就是系统墙钟时间而 Tracer 一侧OtelTracer.ts 中的OtelSpan从 Effect 的Clock服务读取currentTimeNanosUnsafe()。2.2 为什么两者会漂移关键差异在于Date.now()与 EffectClock内部的高精度 wall-clock 实现可能基于不同的时钟源或校准原点。系统墙钟并非恒定不变操作系统可能通过 NTP 等协议对系统时间进行校正导致时间跳变虚拟机 / 容器环境下宿主机与虚机的时钟源校准机制不同会产生持续漂移高分辨率时钟如基于performance/process.hrtime校准的实现在初始化时记录了一个原点若该原点与Date.now()的墙钟读数不一致后续换算出的时间就会系统性偏移。当两条路径的墙钟读数产生毫秒级甚至更小的偏差时恰好处于 Span 生命周期边缘的日志记录就可能被贴上早于startTime的时间戳在 Trace 视图中表现为日志穿越到 Span 之前。三、修复方案统一收敛到 Effect Clock补丁给出的修复思路非常直接——不再让 Logger 与 Tracer 各自取时而是让两者都从同一个Clock服务读取纳秒级 wall-clock 时间再统一转换为 OpenTelemetry 的HrTime格式nanosToHrTime(clock.currentTimeNanosUnsafe())3.1 为什么选currentTimeNanosUnsafe()查看 Clock.ts 的服务定义可知currentTimeNanosUnsafe()返回当前 Unix 时间纳秒属于wall-clock 语义与 Span 开始时间、日志时间戳在时间轴上天然可比它返回bigint纳秒精度远超Date.now()的毫秒精度它由Clock服务提供可通过Effect.provideService(Clock.Clock, ...)在测试中替换为可控时钟Unsafe后缀表示同步读取非 Effect 包装适合在日志回调这种同步场景中使用。值得注意的是Clock.ts 的 JSDoc 明确提示currentTimeNanosUnsafe()的值在系统墙钟被校正时可能前后移动不适用于测量经过的时间——这正说明它应该用于时间戳标记而测量耗时则应使用monotonicTimeNanos。本次修复正是把它用在时间戳这个正确场景上。3.2nanosToHrTime的格式转换OpenTelemetry 的时间戳标准格式为HrTime即[seconds, nanoseconds]二元组。转换工具位于 internal/attributes.tsconst bigint1e9 BigInt(1_000_000_000) /** internal */ export const nanosToHrTime (timestamp: bigint): Otel.HrTime { return [Number(timestamp / bigint1e9), Number(timestamp % bigint1e9)] }实现将纳秒时间戳整除得到秒、取余得到纳秒精度无损地映射到 OTel 数据模型。四、源码级实现修复后的日志发射链路4.1 Logger 侧时间戳与 logSpan 分离修复后的 OtelLogger.tsmake构造器完整逻辑如下节选关键部分export const make: Effect.Effect Logger.Loggerunknown, void, never, OtelLoggerProvider Effect.gen(function*() { const loggerProvider yield* OtelLoggerProvider const clock yield* Clock.Clock const otelLogger loggerProvider.getLogger(effect/opentelemetry) return Logger.make((options) { // 关联当前 Fiber 与父 Span const span Context.getOrUndefined(options.fiber.context, Tracer.ParentSpan) if (Predicate.isNotUndefined(span)) { attributes.spanId span.spanId attributes.traceId span.traceId } // 计算 logSpan 相对耗时毫秒 const now options.date.getTime() for (const [label, startTime] of options.fiber.getRef(References.CurrentLogSpans)) { attributes[logSpan.${label}] ${now - startTime}ms } // 统一使用 Effect Clock 生成时间戳 const hrTime nanosToHrTime(clock.currentTimeNanosUnsafe()) otelLogger.emit({ body: message.length 1 ? message[0] : message, severityText: options.logLevel, severityNumber: logLevelToSeverityNumber(options.logLevel), timestamp: hrTime, observedTimestamp: hrTime, attributes }) }) })实现细节值得注意timestamp与observedTimestamp同源二者都使用nanosToHrTime(clock.currentTimeNanosUnsafe())保证日志的产生时刻与被观测时刻一致options.date并未被删除它仍然用于logSpan.*属性的相对耗时计算now - startTime。这是毫秒级的差值运算用于展示当前日志与 logSpan 起点的间隔不参与绝对时间戳的生成因此不受墙钟漂移影响Logger 从Clock.Clock服务取时钟通过Effect.gen中的yield* Clock.Clock获得意味着时间源完全由 Effect 运行时决定可被测试层替换。4.2 Tracer 侧Span 时间戳同样来自 Clock与之对应OtelTracer.ts 中的 Span 时间戳来源如下OtelSpan构造时以nanosToHrTime(options.startTime)作为tracer.startSpan的startTimeOtelTracer.ts其中options.startTime由 Effect Tracer 基于 Clock 生成Span 结束时以nanosToHrTime(endTime)结束end方法未显式传入时间时convertOtelTimeInput回退到clock.currentTimeNanosUnsafe()const convertOtelTimeInput (input: Otel.TimeInput | undefined, clock: Clock.Clock): bigint { if (input undefined) { return clock.currentTimeNanosUnsafe() } // number - Date - HrTime 元组的转换分支 }修复后Logger 与 Tracer 在同一进程内、同一 Effect 运行时读取同一个Clock服务实例时间源完全一致从根本上消除了双时钟漂移问题。五、测试验证用可控时钟证明时间对齐仓库在 OtelLogger.test.ts 中新增了针对性测试uses wall-clock timestamps and keeps them aligned with spans其核心手法是构造一个故意错乱的时钟来证明修复有效const wallTimeNanos 1_735_689_600_123_456_789n const monotonicTimeNanos 123_456_789n const skewedClock: Clock.Clock { currentTimeMillisUnsafe: () 1, // 故意返回一个荒谬的毫秒值 currentTimeMillis: Effect.succeed(1), currentTimeNanosUnsafe: () wallTimeNanos, // 纳秒时钟返回真实墙钟时间 currentTimeNanos: Effect.succeed(wallTimeNanos), monotonicTimeNanosUnsafe: () monotonicTimeNanos, monotonicTimeNanos: Effect.succeed(monotonicTimeNanos), sleep: () Effect.void }测试通过Effect.provideService(Clock.Clock, skewedClock)注入这个时钟让Date.now()路径毫秒1与 Clock 路径纳秒真实时间产生巨大分歧随后断言assert.deepStrictEqual(log.hrTime, expectedTime) assert.deepStrictEqual(log.hrTimeObserved, expectedTime) assert.deepStrictEqual(log.hrTime, span.startTime) assert.strictEqual(log.attributes.spanId, span.spanContext().spanId) assert.strictEqual(log.attributes.traceId, span.spanContext().traceId)关键断言是log.hrTime与span.startTime深度相等——只有二者都走clock.currentTimeNanosUnsafe()才能通过如果 Logger 仍使用options.date.getTime()日志时间戳将变成 1970 年初的 1ms测试立刻失败。这一用例同时验证了修复前后的行为差异也演示了在测试环境中通过替换Clock.Clock服务来模拟时钟漂移的标准手法。此外测试还覆盖了关联正确性does not let annotations overwrite active span correlation用例证明即使通过Effect.annotateLogs({ traceId: spoof-trace, spanId: spoof-span })伪造日志注解spanId/traceId仍以真实活跃 Span 为准避免污染关联关系。六、这一修复对你的应用意味着什么6.1 升级即可受益本次变更仅涉及effect/opentelemetry的日志时间戳内部实现属于 patch 级修复。若你的应用同时使用 OtelLogger.ts 的layer/layerLoggerProvider接入 OpenTelemetry 日志管道并配合 OtelTracer.ts 或 NodeSdk.ts 进行追踪升级后即可自动获得对齐的时间戳无需修改业务代码。6.2 一个完整的接入示例结合 OtelLogger.test.ts 中的用法一个同时启用日志与追踪的最小接入方式如下import * as NodeSdk from effect/opentelemetry/NodeSdk import { InMemoryLogRecordExporter, SimpleLogRecordProcessor } from opentelemetry/sdk-logs import { SimpleSpanProcessor } from opentelemetry/sdk-trace-base import * as Effect from effect/Effect const TracingLayer NodeSdk.layer(Effect.sync(() ({ resource: { serviceName: my-service }, spanProcessor: [new SimpleSpanProcessor(new InMemorySpanExporter())], logRecordProcessor: [new SimpleLogRecordProcessor({ exporter: new InMemoryLogRecordExporter() })] }))) const program Effect.gen(function*() { yield* Effect.log(业务日志).pipe(Effect.withSpan(parent-span)) }).pipe(Effect.provide(TracingLayer))通过NodeSdk.layer同时配置spanProcessor与logRecordProcessorEffect 日志与 Span 将在同一运行时内共享Clock服务时间戳天然对齐。6.3 排查与验证建议如果你在观测平台上仍观察到日志早于 Span 的现象可以按以下顺序排查确认版本检查effect/opentelemetry是否包含本次修复参考 CHANGELOG.md 中4.0.0-beta.11版本的记录检查时钟环境NTP 频繁校正、虚拟机时钟漂移严重的环境更容易触发此问题修复后已通过统一时钟源规避复现实验可仿照 OtelLogger.test.ts 的做法在测试中注入毫秒与纳秒读数严重不一致的Clock.Clock服务验证日志时间戳不再跟随Date.now()。七、延伸Effect Clock 的取舍与最佳实践本次修复本质上是 Effect 生态可替换服务 单一事实来源理念的一次实践。从 Clock.ts 的服务文档可以看出currentTimeMillis/currentTimeNanos系列是wall-clockUnix 时间用于时间戳标记与展示可能因系统校时发生跳变monotonicTimeNanos系列是单调时钟原点任意、只适合测量耗时不适合序列化传播所有时间读取都通过Clock服务间接完成因此在测试中可以用TestClock或自定义实现完全控制时间行为。对于集成层代码如 OpenTelemetry 桥接正确做法正是绝对时间戳统一取自Clock的 wall-clock 读数相对耗时统一取自同一时钟源避免在桥接边界重新引入Date.now()、process.hrtime等游离于 Effect 服务体系之外的时间源。这也是本次修复在 OtelLogger.ts 与 OtelTracer.ts 中落地的最佳实践范本。【免费下载链接】effectBuild production-ready applications in TypeScript项目地址: https://gitcode.com/GitHub_Trending/ef/effect创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考