监督计划工作的代理人:建立预期运行包裹

监测计划工作的代理人应该从一个问题开始: 这个具体的计划事件是否开始,完成,并在允许的窗口内产生承诺的结果? 绿色过程退出,最近的心跳和完整的痕迹不能单独回答这个问题. 实际默认是 预期运行包 . 每次事件,记录预期的时间表,允许的启动延迟,最大的运行时间和验证可交付的最后期限. 保持这些时间标签分开. 一个工作可能正确地等待,开始迟到,还在工作,迟到,复制或没有结果完成. 它们被分为"运行"和"失败"的状态, 这本指南将这封信构建成运行时间中立的合同. 包含的九个案例的装置是合成的,而不是生产证据,但可执行,并揭示监测系统必须做出的决定. 将记录与计划发生的事件挂 不要从第一个日志行推断预期时间. 获取规划器的预期发生时间,并将其保留为 scheduled at . 库伯尼特斯 1.32 后添加 batch.kubernetes.io/cronjob scheduled timestamp 创建的工作. 谷歌云调度器发送 X CloudScheduler ScheduleTime , 在重试中保持不变. 这些价值在晚起存活下来,使得重试归因于同一个事件. 使用稳定插槽键: 然后保留这些字段: outcome ref 应标识证据,而不是包含敏感的交付物. 它可能是一个哈希,一个对象版本,一个测试 ID,或者一个数据库行键. 一个仅仅存在的生成文件可能不够;验证应该与真正的承诺相匹配,例如今天简报存在,有五个引用的项目,并在预期目的地存储. 因为执行不一定是一次的. 库伯尼特斯记录了一个CronJob有时可以创建两个工作或没有工作,并建议无效的工作负载. 云调度器至少描述一次交付, 同样需要无力目标. 因此,监测必须将重复启动视为一流状态,而不是不可能的异常. 计算三个截止日期,而不是一个截止日期 定义包裹有三个独立的限制: 值应来自观察到的运行时间分布和业务要求,而不是普遍的预设. 计划在9点开始时可能是非常健康的. 同样的40秒的延迟可能违反了不到一分钟的发送承诺. 例如,Amazon EventBridge Scheduler记录了60秒的调用精度;将第01秒视为迟将误解该调度器的合同. 这三个限制回答了不同的问题: 国家 证据 运营商的响应 waiting for start 没有跑步,但 start deadline 没有通过 待一点. missed start 在 start deadline 之后没有运行 检查时间表和可访问性 running 在 finish deadline 之前一个运行是活跃的 放下它. overrun 活动运行通过 finish deadline 在打断之前检查进展 outcome pending 过程完成;验证窗口仍然开放 等待验证器 outcome missing 经过没有证据的验证截止日期 调查错误的成功 duplicate start 超过一个运行要求相同的插槽钥匙 含有副作用;检查重试原因 healthy 预言的结果得到了验证 关闭事件 suspended 清晰的维护或批准暂停覆盖该隙间 抑制失败;保留审计证据 这种排序可以防止两种常见的错误. 首先,缺席不是失败,直到适用的最后期限过去了. 第二,完成过程不是完成任务. 在 09:06 出发的运行可以保持 outcome pending 直到其上传,测试或目的地检查完成. 只有在那个独立的恩典窗口到期后才会成为 outcome missing . 突袭也不是杀害特工的许可. 检查有用的进展是否仍在进行,是否在外部系统中等待,以及是否可以逆转的中断. 包裹指出了哪些注意事项是合理的;它不决定收回. 复制分类器以9个尬的案例 运行文物通过确定性分类器评估了新的线程限定的装置. 用: 这款设备使用了2分钟的开始时间,10分钟的最高运行时间, 结果是: 核心分类器是故意小的: 这项实验证明了明确的边界的价值,但它并不能证明所选的门适合实际工作负载. 它还假设一个安排器将事件清洁地映射到一个插槽. 事件驱动的风扇,手动重播的历史工作,以及多个需要的交付项目的任务需要扩大身份模型. 操作重复,重叠,时间区和间歇 复试和重叠是相关的,但不是相同的. 运输故障后,一次重复尝试可能会重复相同的插槽. 在前一个仍然活跃的同时,下一个插槽可能会出现重叠. 保留 slot key 和 run id ,然后应用编程器的声明同步行为. 库伯尼特斯揭露了 Allow , Forbid 和 Replace 的同时货币政策. 在 Forbid 下,在前一个工作活动期间,错过事件被认为是错过的. 在 Replace 下,新的事件取代了旧的工作. 你的监控状态应该保留这个原因;否则,故意替换看起来就像一个崩. 对于副作用任务,在目的地和显示器上的插槽键上进行复制. 一次成功的第二次运行仍然可以发送第二个账单,重写更新的报告,或两次发布相同的消息. 监视器可以暴露风险,但无力属于工作负载和目的地合同. 时间区需要同样明确的规则. 存储发生时刻标记在 UTC 中,同时保留时间表IANA时区识别符和原始表达. 节省日光的转型是具体的时间表. 事件桥规划器记录了春季前期不存在的当地时间被跳过,秋季后期一次重复的当地时间被跳过. 不要综合编程程序员从未承诺的错过事件. 最后,暂停必须是模拟的,而不是通过禁用警报来隐藏的. 记录谁暂停了时间表,为什么,开始和结束时间,以及是否预计会赶上. Kubernetes指出,暂停的CronJob事件被视为错过,并且在没有设置的开始截止日期后,可能会立即运行. 一个忽略停机的监视器可以在维护结束时淹没操作员. 把封筒变成一个安静的操作规则 开始一个关键的计划代理,不是每一个痕迹: 1. 阅读时间区,重试政策和同步政策. 2. 在工作开始之前分配一个插槽钥匙,并在重试中保存它. 3. 根据实际要求和观察到的时间,选择 start grace , max runtime 和 outcome grace . 4. 定义一个确定性结果验证器. 5. 在启动通知之前,请通过9个州重新播放最近的历史. 6. 只有在用户相关的承诺不在封筒内时页面;保持 waiting for start , running 和 outcome pending 可见但安静. 在调整时间表,模型,工具或目的地之后,重新审核门. 一个更大的模型可能会增加运行时间,而不改变正确性. 一个较慢的外部API可能会延长结果验证. 值漂移是配置债务,而不是证据表明代理人变得不可靠. 该合同还设定了有用的数据界限. 你需要时间标签,稳定标识,状态, 你不需要自动提示,响应,原始工具的有效载荷,或完整的痕迹. 只有在诊断要求他们,而您的隐私政策允许时才会收集这些. Sidewisp旨在将错过时间表,摊位,工具故障和错过结果等信号转化为优先健康视图,具有明确的证据和批准界限. 目前,生产监测引擎和运行时间适配器通常没有出货. Sidewisp 目前处于私密预览阶段。 如果这份预期的运行合同与你运营的故障相匹配, Sidewisp 已经监视了你的现场代理人. 主要来源 库伯内特斯 CronJob文档 计划时间表,开始截止日期,同期政策,暂停,近似创建和无权. 谷歌云调度器概述 至少一次交付,重新尝试行为,无力,以及稳定的计划时间标题. 亚马逊事件桥程表类型 调用精度,时区,节约白天的行为.