可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载在 OneUptime 中每当你创建并触发一个工作流Workflow平台都会完整记录这次执行的全部经过——何时运行、是否成功、每个节点块/组件做了什么。这份记录被称作一次运行Run。运行记录既是确认工作流正常工作的依据也是排查失败工作流、回溯历史活动的唯一入口。本文基于 OneUptime 官方文档体系中的 Runs Logs 章节源文档位于 packages/App/FeatureSet/Docs/Content/en/workflows/runs-and-logs.md结合仓库内的工作流引擎源码系统讲解运行记录在哪里找、每种状态意味着什么、如何阅读一次运行的详细日志以及常见故障的标准排查流程。在哪里找到运行记录OneUptime 提供了三个查看运行记录的入口它们展示的范围和过滤维度各不相同页面位置你能看到的内容Workflows → Runs Logs项目级项目中所有工作流的全部运行记录。支持按工作流名称、状态和时间进行过滤。Workflow → Runs Logs单工作流级仅当前这一个工作流的运行记录。与项目级页面不同这里没有工作流过滤器取而代之的是一个Run ID过滤器。单次运行详情通过某行运行记录上的View Logs按钮打开——注意运行记录的行本身是不可点击的必须点击按钮才能进入详情。从数据模型角度看每条运行记录都对应数据库中的一行WorkflowLog。在 WorkflowLog 模型 中可以看到它保存了运行的核心字段logs原始日志文本、workflowStatus运行状态、startedAt/completedAt起止时间、resumeAtSleep 节点后的恢复时间以及stepTrace结构化步骤追踪。其中Index([workflowStatus, createdAt])注解表明平台会按状态与创建时间索引这些记录以支持后台定期扫描超时或卡住Scheduled的运行——这与后文将要讲到的超时与 5 分钟未领取即失败的行为直接相关。运行状态全解读每一次运行都会经历若干状态理解每个状态的含义是排查问题的第一步。OneUptime 对运行状态的定义如下状态含义Scheduled触发器已触发运行已进入执行器runner的队列等待执行。通常只持续不到一秒。如果一次运行在5 分钟后仍处于 Scheduled 状态说明没有任何执行器认领它这次运行会被判定为失败。Running工作流正在执行中。包含长时间运行节点的块会让运行一直停留在这个状态。Waiting运行因遇到Sleep节点而暂时挂起之后会自动恢复。处于等待期间它不会占用任何 worker 资源。Executed运行顺利执行到结束、没有发生失败。这是成功状态——状态标签上写的就是Executed而不是 Success。Error运行因某个块抛出错误而中止。此外以下情况也会进入 Error 状态排队中的运行一直未被认领、Sleep 挂起的运行丢失了恢复调度、时间表达式无法解析、或者工作流在运行中途被停用。Timeout运行耗时超过了允许的上限。具体超时配置与安全相关设置请参考配置与安全。Execution Exceeded Current Plan项目在最近 30 天内已用尽工作流运行配额或订阅处于未付费状态。此时运行会被记录但不会真正执行。该状态仅存在于 OneUptime Cloud。重要细节如果某个块把执行流转交到了它的Error输出端口——例如一个 API 节点遇到 4xx 响应——这不会导致整次运行失败。错误分支会被正常执行运行最终仍以Executed结束。不过该步骤本身在可视化视图上仍会用红色标出方便你快速定位。状态枚举的源码印证打开 WorkflowStatus 枚举 可以看到引擎内部对状态的建模与文档表格完全对应enum WorkflowStatus { Scheduled Scheduled, Running Running, Waiting Waiting, Success Success, Error Error, Timeout Timeout, WorkflowCountExceeded Workflow Count Exceeded, }值得注意的是引擎枚举中的成功态写的是Success而界面展示给用户的标签是Executed两者指向同一个语义状态。此外Execution Exceeded Current Plan 对应的枚举值是WorkflowCountExceeded。在 QueueWorkflow 队列服务 中可以找到它的判定逻辑当workflowCount表明该项目最近 30 天内已经运行了超过计划限额的次数时就会写入WorkflowCountExceeded状态并在日志中明确写出当前计数与计划上限。状态机如何写入日志在 RunWorkflow 运行服务 中可以看到状态流转的实际写入点运行入队时写入WorkflowStatus.Scheduled第 401 行遇到 Sleep 节点挂起时写入WorkflowStatus.Waiting并记录恢复时间第 791 行正常结束时写入WorkflowStatus.Success第 694 行超时写入WorkflowStatus.Timeout第 720 行出错则写入WorkflowStatus.Error第 733 行。每一次状态变更都会重写一次WorkflowLog行——这也是为什么一次长时间运行会留下完整的状态演进轨迹。如何阅读一次运行点击某次运行的View Logs按钮即可打开详情。Workflow Run视图包含两个标签页分别对应两种粒度完全不同的信息。Steps 标签页结构化步骤追踪Steps视图为每一个实际执行过的块生成一行记录按执行顺序排列。每一行展示块的标题、它的组件 IDcomponent id、耗时以及它最终走出的输出端口显示为→ success、→ error或→ yes等。展开某一行可以看到两个详细区块Received—— 块实际收到的设置参数此时所有变量都已完成解析替换。Returned—— 块实际产生的输出。执行失败的步骤会以红色显示并且默认展开错误消息打印在Received区块上方让你一眼看到失败原因。Full Log 标签页原始执行日志Full Log展示执行器打印的逐行原始日志其中包含块自身输出的所有内容。当 Steps 视图不足以解释失败原因时切换到 Full Log 查看底层日志是标准做法。三个值得掌握的细节组件 ID 就是变量引用键。每个步骤标题下方印出的组件 ID正是你需要在{{local.components.id.returnValues.…}}引用中填写的字符串。因此 Steps 视图也是快速获得正确引用写法的最快途径——直接照抄页面上的 ID 即可。每次运行只保留最近 100 个步骤。如果一次运行很长、或经过多次 Sleep 挂起恢复较早的步骤会被丢弃并在原位置显示一条琥珀色提示而不是静默地展示不完整的运行。这一限制在 StepTrace.ts 中以常量形式定义MAX_TRACE_STEPS: number 100。其实现逻辑appendTraceStepStepTrace.ts在步骤数超过上限时丢弃最旧的步骤并置truncated标记——因为一个失败运行的读取习惯是从末尾往前读导致失败的那一步永远会保留。敏感值与超长值会被脱敏/截断。Steps 中展示的值是变量填充后块实际看到的内容但有两条例外一是密钥secrets以及块标记为敏感sensitive的字段会被移除二是非常长的值会被截断并以… (truncated)结尾。截断阈值定义在同文件中的MAX_TRACE_VALUE_LENGTH: number 4000StepTrace.tstruncateTraceValue函数StepTrace.ts对字符串直接截断而对结构化对象先序列化成 JSON 再按长度判断——因为把序列化对象拦腰截断会产生看似数据却无法解析的文本。敏感信息脱敏的源码实现关于脱敏RunWorkflow.ts 中的redactSensitiveComponentValuesForLogs函数会依据组件元数据Argument/ReturnValue上的isSensitive标记把对应字段替换为WORKFLOW_LOG_REDACTED_VALUE即[REDACTED]。真正的值仍会在运行时传给组件只是不落入日志。此外SecretRedaction.ts 中的redactSecretsFromString会递归地扫描整个结构化追踪数据把工作流变量中的密钥内容替换掉——包括 JSON 的键名也要脱敏密钥可能被替换进 HTTP 头名称等位置并且对重叠的密钥按长者优先排序替换防止短密钥先被替换而暴露长密钥的尾巴。另外从 Builder 手动启动一次运行时会直接打开这个视图并自动跟随运行following因此你可以实时观看执行过程而不必等它结束后再去找记录。常见故障排查我的工作流没有运行。按以下顺序排查确认工作流在其Overview页面处于Enabled状态。新建的工作流默认是停用状态而停用的工作流会拒绝一切运行——包括手动运行。对于 OneUptime 事件触发器确认事件确实发生了。打开对应记录并检查其历史。对于 Webhook 触发器确认外部系统向正确的 URL 发送请求。大多数工具在发送 webhook 时都会记录日志去那里查看即可。对于定时触发器确认 cron 表达式与你期望的时间一致。如果运行确实出现了但状态是Execution Exceeded Current Plan说明项目已用尽最近 30 天的工作流运行配额或订阅未付费。该次运行的日志会写明你的执行计数和计划上限。这一状态仅适用于 OneUptime Cloud。后面的块一直没有执行。一个块没有运行通常是接线wiring问题。打开Builder检查前一个块的输出是否连接到了这个块的输入前一个块是否走出了与你预期不同的输出端口——比如走出了Error而不是Success或No而不是YesSteps 标签页会明确显示它实际走了哪个端口。某个变量传过来是空的。打开运行详情查看失败步骤的Received区块如果你看到的是字面文本{{local.components.…}}说明引用没有被解析。通常是在组件 ID 或返回值 ID 上拼写错误——注意这里要用块的Identifier而不是界面上显示的名称。同时检查local.components本身的拼写例如{{local.componets.api-get-1.returnValues.response-body}}会以字面文本原样发送而运行仍然会报告Executed。如果你看到的是空字符串说明前一个块确实执行了但没有产出这个字段。Full Log标签页中会有一条警告行列出所有未解析的引用名称这通常是最快的定位方式。手动运行正常但从触发器触发就不行。打开Builder点击Run Workflow用与真实触发器发送内容相近的值填充触发器的字段。然后把这次运行的Received值与真实运行的 Received 值并排对比。差异通常只是某个字段名或字段类型不一致。关于重新运行Retry的设计取舍OneUptime没有提供重试这次运行的按钮也不会自动重跑旧执行。原因在于工作流的副作用——Slack 消息、API 调用、工单创建——可能无法安全地重复执行。如果要重做某次任务正确做法是修复工作流本身等待下一次真实触发器触发它或者打开Builder手动点击Run Workflow用相同参数值重新执行一次。这一设计在 RunStep API 的注释中也能看到印证产品中不存在安全或只读的组件概念注册表里大约一半的组件会发送消息、调用任意 URL、或对数据行做增删改而且这些操作事后都不会被撤销。因此单独运行某个步骤也不是在 API 进程里直接执行组件而是入队一次缩小到单步的普通运行从而完整继承工作流的所有既有保障必须启用、订阅有效、受项目计划运行限额约束、写入 WorkflowLog 审计记录、在独立 worker 而非 API 进程中执行、日志与返回值按既有规则脱敏。运行记录保留多长时间在OneUptime Cloud上运行记录保留30 天后即被删除——这也是为什么两个运行列表都声称自己覆盖最近 30 天。自托管Self-hosted安装会一直保留运行记录直到你手动删除。如果某个工作流执行过于频繁、让你的历史记录变得杂乱建议停用或删除它避免继续产生噪音。另外补充一点在步骤追踪step tracing功能引入之前记录下来的运行没有Steps内容只会显示Full Log。这一兼容性处理在 StepTrace.ts 的 parseTrace 函数 中有明确实现——旧行读取时绝不会抛错无法解析的追踪会读作空追踪视图自动回退到原始日志。延伸阅读配置与安全 —— 超时设置、递归限制、隐藏密钥。变量 —— 在你的块中使用变量时的完整语法。组件 —— 每个块具体能产出什么。赞分享可观测性后端运维前端云原生微服务AI Agent【免费下载链接】oneuptimeComplete open-source monitoring and observability platform.项目地址https://gitcode.com/GitHub_Trending/on/oneuptime点击查看免费下载相关推荐OneUptime 工作流运行与日志Runs Logs完全指南状态解析、步骤追踪与故障排查OneUptime 工作流运行与日志Runs Logs完全指南状态解析、步骤追踪与故障排查 本文围绕 OneUptime 开源可观测平台的 Workf可观测性后端运维前端云原生微服务AI AgentOneUptime 工作流运行与日志Runs Logs完全指南状态语义、执行追踪与故障排错OneUptime 工作流运行与日志Runs Logs完全指南状态语义、执行追踪与故障排错 工作流的每一次执行都会在 OneUptime 中留下一份完可观测性后端运维前端云原生微服务AI AgentOneUptime 工作流运行与日志Runs Logs深度指南状态机、步骤追踪与故障排查实战OneUptime 工作流运行与日志Runs Logs深度指南状态机、步骤追踪与故障排查实战 每次工作流被触发后OneUptime 都会将“何时运行可观测性后端运维前端云原生微服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考