尧图网站建设 
后端任务调度【免费下载链接】healthchecksOpen-source cron job and background task monitoring service, written in Python Django项目地址https://gitcode.com/gh_mirrors/he/healthchecks点击查看免费下载healthchecks 是一个基于 Django 的开源定时任务与后台任务监控服务采用心跳监控heartbeat monitoring模型被监控任务通过 HTTP 请求上报 start、success、fail 信号服务端在预期时间内未收到信号即判定异常并触发告警。本文围绕 templates/docs/monitoring_systemd_tasks.md 讲解如何将 systemd timer/service 接入 healthchecks包括 curl 方案、runitor 方案、$EXIT_STATUS退出码上报以及.timer文件中OnCalendar表达式的原生支持与界面预览。心跳监控能捕获哪些故障模式healthchecks 的监控原理是被监控任务在开始和结束两个时间点各发送一次 HTTP 请求即 start 与 success/fail 信号若在预期时间点没有收到请求服务端便发出通知。对 systemd 任务而言这种模式可以检测到以下四类典型故障整机宕机断电、硬件故障、网线被拔等导致机器完全不可达心跳自然中断systemd 未按预期启动任务如.service配置无效导致任务根本没跑起来任务以非零退出码结束主命令执行失败ExecStopPost上报失败信号任务运行时间异常在错误的时间点运行、或运行时间过长与预期调度不符。每个 systemd 定时任务由两个文件定义.service文件描述要执行的命令、以哪个系统用户运行、设置哪些环境变量以及依赖哪些服务已就绪.timer文件存放任务的调度计划如OnCalendar表达式。方案一用 curl 发送 start 与退出码信号接入的前提是服务器上装有 curl 或 wget无需再安装额外软件。以一个名为copy-media.service的原始服务为例它把/opt/media目录同步到远程主机[Unit] DescriptionCopy /opt/media to remote_host Requiresnetwork-online.target [Service] Typeoneshot ExecStartrsync -a /opt/media/ remote_userremote_host:/opt/media/改造后在主命令运行前发送 start 信号结束后把主命令的退出码上报给 healthchecks[Unit] DescriptionCopy /opt/media to remote_host, with SITE_NAME monitoring Requiresnetwork-online.target [Service] Typeoneshot ExecStartPre-curl -sS -m 10 --retry 5 PING_URL/start ExecStartrsync -a /opt/media/ remote_userremote_host:/opt/media/ ExecStopPostcurl -sS -m 10 --retry 5 PING_URL/${EXIT_STATUS}三个关键点ExecStartPre前的-前缀告诉 systemd 忽略该命令的失败超时或非零退出码否则 curl 一旦失败会阻断主命令执行——宁可心跳丢失也不能让业务命令跑不起来ExecStopPost与$EXIT_STATUS主进程结束后 systemd 提供$EXIT_STATUS环境变量取值范围 0–255curl 将其拼入 URL 上报。healthchecks 把退出码 0 视为成功success大于 0 视为失败failcurl 常用参数-sS静默输出但保留错误curl 失败时错误会打印进系统日志-m 秒HTTP 请求的最大允许耗时--retry 次数对瞬时故障超时、HTTP 5xx的重试次数。该方案只依赖 curl缺点是不捕获命令的输出stdout/stderr。退出码上报的服务端处理URL 末尾的退出码由 healthchecks 的 ping 接口解析。从 hc/api/urls.py 的 URL 定义可以看到ping/uuid:code之下除了start、fail、log子路径外还支持int:exitstatus直接把退出码作为 URL 段上报。在 hc/api/views.py 的ping()视图中退出码大于 255 会直接返回 400exitstatus 0时 action 被改写为fail从而将非零退出码统一映射为失败心跳。这也解释了为什么ExecStopPost里可以放心地使用curl PING_URL/${EXIT_STATUS}。方案二用 runitor 接管全部信号与输出采集如果不想在.service里手写多条 curl 命令可以使用 runitor 这样的封装工具它负责发送 start、success、fail 信号同时捕获并截断命令输出一个ExecStart即可完成全部监控逻辑[Unit] DescriptionCopy /opt/media to remote_host, with runitor Requiresnetwork-online.target [Service] Typeoneshot ExecStartrunitor -uuid your-uuid-here -- rsync -a /opt/media/ remote_userremote_host:/opt/media/前提是 runitor 二进制已存在于系统的 PATH 中。-uuid参数指定检查项的 UUID即 PING_URL 中的your-uuid-here--之后是被监控的实际命令runitor 会按命令退出码决定上报成功还是失败并顺带把输出作为 ping body 上传可在 healthchecks 的 ping 详情页查看。定时调度.timer文件与 OnCalendar 表达式.timer文件用OnCalendar选项设定调度计划它接收的是calendar event 表达式与 cron 表达式不同。示例——工作日每 4 小时运行一次copy-media.service[Unit] DescriptionRun copy-media.service every 4 hours on workdays [Timer] OnCalendarMon-Fri *-*-* 0/4:00 [Install] WantedBytimers.targethealthchecks 对 calendar event 表达式提供原生支持创建检查项时可直接选择 OnCalendar 类型把.timer里使用的同一套表达式粘贴到检查项的 OnCalendar Expression(s) 字段即可无需翻译成 cron 语法。可同时配置Servers Time Zone服务器时区与 systemd 相同表达式按该时区求值Grace Time宽限期允许心跳延迟到达的时间窗口超过才判定任务异常Kind 切换栏可在 Simple / Cron / OnCalendar 三种检查类型间切换。表达式校验与时间预览的源码实现OnCalendar 表达式不是简单字符串存储healthchecks 在前后端都对其做了真实解析表单校验OnCalendarValidator见 hc/front/validators.py要求表达式按空白拆分为 1–4 个分量然后实例化oncalendar.OnCalendar并调用next(it)尝试计算下一个触发时刻解析失败或计算不出未来时刻即报 Not a valid OnCalendar expression.即时预览oncalendar_preview()视图见 hc/front/views.py以当前时区为基准用OnCalendar迭代器解析 schedule生成未来 4–6 次执行时间UTC 时区取 6 次、其他时区取 4 次渲染到front/oncalendar_preview.html模板无效表达式会标记bad_schedule并给出错误提示。相关行为由 hc/front/tests/test_oncalendar_preview.py 覆盖例如*:*在 UTC 下应得到2020-01-01 00:01:00 UTC这样的下一次执行时刻下次执行时刻计算在模型层hc/api/models.py当检查项为oncalendar类型且状态为 up 时get_grace_start()会把上次 ping 时间转换到检查项所在时区用OnCalendar(schedule, last_local)计算下一个预期时刻再转回 UTC 后加上grace宽限期得到告警触发点going_down_after()。这一步意味着 schedule 的任何修改都会影响下一次告警的判定窗口也正因如此在 Web UI 中修改调度时会同步重算alert_after避免因调度变更导致误告警。心跳 URL 的获取与使用在实际接入前先在 healthchecks 中创建检查项Check从检查详情页复制 PING_URL形如https://your-healthchecks.example.com/ping/uuid。文档示例中的PING_URL与your-uuid-here均为占位符需要替换为真实值。系统内置的文档渲染上下文会把PING_URL替换为settings.PING_ENDPOINT your-uuid-here的形式见 hc/front/views.py其中 UUID 对应 URL 路由中的uuid:code见 hc/api/urls.py。如果项目开启了 slug 别名也可使用ping/ping_key/slug形式的可读 URLhc/api/urls.py。部署后的验证与故障排查建议先手动验证心跳修改.service后执行systemctl daemon-reload然后手动systemctl start copy-media.service观察 healthchecks 检查详情页是否出现 start 与 success 两条 ping 记录确认 timer 已启用systemctl enable --now copy-media.timer并用systemctl list-timers查看激活时间是否与 OnCalendar 表达式一致检查退出码上报故意让主命令失败一次确认检查项进入 down 状态并触发通知同时确认$EXIT_STATUS在ExecStopPost中能被正确展开systemd 单元中应使用$EXIT_STATUS而非$转义形式核对时区一致性.timer的OnCalendar表达式与 healthchecks 检查项中配置的时区必须一致否则会在不同时区求值导致未按时收到心跳的误判。小结把 systemd 定时任务接入 healthchecks 的最小改动只在.service文件里加两行 curlExecStartPre发 start、ExecStopPost报退出码或者用 runitor 一键接管.timer里的OnCalendar表达式可以直接复用到检查项的 OnCalendar 类型中配合界面预览与时区/宽限配置无需学习第二套调度语法。整套方案的可靠性建立在 healthchecks 对退出码、表达式解析与下次执行时刻计算的真实实现之上部署后建议按上文步骤做一轮端到端验证。赞分享后端任务调度【免费下载链接】healthchecksOpen-source cron job and background task monitoring service, written in Python Django项目地址https://gitcode.com/gh_mirrors/he/healthchecks点击查看免费下载相关推荐使用 PowerShell 与 Windows 任务计划程序监控 Healthchecks 定时任务使用 PowerShell 与 Windows 任务计划程序监控 Healthchecks 定时任务 PowerShell 脚本可以非常便捷地向 Healthc后端任务调度RxDB 深度解析local-first 响应式 NoSQL 数据库的架构、复制引擎与快速上手RxDB 深度解析local first 响应式 NoSQL 数据库的架构、复制引擎与快速上手 导读 RxDB 是一个面向 JavaScript 应用的 lo后端任务调度C 接入 Healthchecks 定时任务监控使用 HttpClient 发送 Pinging API 请求的完整指南C 接入 Healthchecks 定时任务监控使用 HttpClient 发送 Pinging API 请求的完整指南 Healthchecks 是一个用后端任务调度上一篇Listen gem高级配置技巧5个提升文件监听性能的黄金法则下一篇ATAC性能优化轻量级二进制的最佳实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 使用 healthchecks 监控 Systemd 定时任务：heartbeat 信号、curl/runitor 接入与 OnCalendar 调度详解
后端任务调度【免费下载链接】healthchecksOpen-source cron job and background task monitoring service, written in Python Django项目地址https://gitcode.com/gh_mirrors/he/healthchecks点击查看免费下载healthchecks 是一个基于 Django 的开源定时任务与后台任务监控服务采用心跳监控heartbeat monitoring模型被监控任务通过 HTTP 请求上报 start、success、fail 信号服务端在预期时间内未收到信号即判定异常并触发告警。本文围绕 templates/docs/monitoring_systemd_tasks.md 讲解如何将 systemd timer/service 接入 healthchecks包括 curl 方案、runitor 方案、$EXIT_STATUS退出码上报以及.timer文件中OnCalendar表达式的原生支持与界面预览。心跳监控能捕获哪些故障模式healthchecks 的监控原理是被监控任务在开始和结束两个时间点各发送一次 HTTP 请求即 start 与 success/fail 信号若在预期时间点没有收到请求服务端便发出通知。对 systemd 任务而言这种模式可以检测到以下四类典型故障整机宕机断电、硬件故障、网线被拔等导致机器完全不可达心跳自然中断systemd 未按预期启动任务如.service配置无效导致任务根本没跑起来任务以非零退出码结束主命令执行失败ExecStopPost上报失败信号任务运行时间异常在错误的时间点运行、或运行时间过长与预期调度不符。每个 systemd 定时任务由两个文件定义.service文件描述要执行的命令、以哪个系统用户运行、设置哪些环境变量以及依赖哪些服务已就绪.timer文件存放任务的调度计划如OnCalendar表达式。方案一用 curl 发送 start 与退出码信号接入的前提是服务器上装有 curl 或 wget无需再安装额外软件。以一个名为copy-media.service的原始服务为例它把/opt/media目录同步到远程主机[Unit] DescriptionCopy /opt/media to remote_host Requiresnetwork-online.target [Service] Typeoneshot ExecStartrsync -a /opt/media/ remote_userremote_host:/opt/media/改造后在主命令运行前发送 start 信号结束后把主命令的退出码上报给 healthchecks[Unit] DescriptionCopy /opt/media to remote_host, with SITE_NAME monitoring Requiresnetwork-online.target [Service] Typeoneshot ExecStartPre-curl -sS -m 10 --retry 5 PING_URL/start ExecStartrsync -a /opt/media/ remote_userremote_host:/opt/media/ ExecStopPostcurl -sS -m 10 --retry 5 PING_URL/${EXIT_STATUS}三个关键点ExecStartPre前的-前缀告诉 systemd 忽略该命令的失败超时或非零退出码否则 curl 一旦失败会阻断主命令执行——宁可心跳丢失也不能让业务命令跑不起来ExecStopPost与$EXIT_STATUS主进程结束后 systemd 提供$EXIT_STATUS环境变量取值范围 0–255curl 将其拼入 URL 上报。healthchecks 把退出码 0 视为成功success大于 0 视为失败failcurl 常用参数-sS静默输出但保留错误curl 失败时错误会打印进系统日志-m 秒HTTP 请求的最大允许耗时--retry 次数对瞬时故障超时、HTTP 5xx的重试次数。该方案只依赖 curl缺点是不捕获命令的输出stdout/stderr。退出码上报的服务端处理URL 末尾的退出码由 healthchecks 的 ping 接口解析。从 hc/api/urls.py 的 URL 定义可以看到ping/uuid:code之下除了start、fail、log子路径外还支持int:exitstatus直接把退出码作为 URL 段上报。在 hc/api/views.py 的ping()视图中退出码大于 255 会直接返回 400exitstatus 0时 action 被改写为fail从而将非零退出码统一映射为失败心跳。这也解释了为什么ExecStopPost里可以放心地使用curl PING_URL/${EXIT_STATUS}。方案二用 runitor 接管全部信号与输出采集如果不想在.service里手写多条 curl 命令可以使用 runitor 这样的封装工具它负责发送 start、success、fail 信号同时捕获并截断命令输出一个ExecStart即可完成全部监控逻辑[Unit] DescriptionCopy /opt/media to remote_host, with runitor Requiresnetwork-online.target [Service] Typeoneshot ExecStartrunitor -uuid your-uuid-here -- rsync -a /opt/media/ remote_userremote_host:/opt/media/前提是 runitor 二进制已存在于系统的 PATH 中。-uuid参数指定检查项的 UUID即 PING_URL 中的your-uuid-here--之后是被监控的实际命令runitor 会按命令退出码决定上报成功还是失败并顺带把输出作为 ping body 上传可在 healthchecks 的 ping 详情页查看。定时调度.timer文件与 OnCalendar 表达式.timer文件用OnCalendar选项设定调度计划它接收的是calendar event 表达式与 cron 表达式不同。示例——工作日每 4 小时运行一次copy-media.service[Unit] DescriptionRun copy-media.service every 4 hours on workdays [Timer] OnCalendarMon-Fri *-*-* 0/4:00 [Install] WantedBytimers.targethealthchecks 对 calendar event 表达式提供原生支持创建检查项时可直接选择 OnCalendar 类型把.timer里使用的同一套表达式粘贴到检查项的 OnCalendar Expression(s) 字段即可无需翻译成 cron 语法。可同时配置Servers Time Zone服务器时区与 systemd 相同表达式按该时区求值Grace Time宽限期允许心跳延迟到达的时间窗口超过才判定任务异常Kind 切换栏可在 Simple / Cron / OnCalendar 三种检查类型间切换。表达式校验与时间预览的源码实现OnCalendar 表达式不是简单字符串存储healthchecks 在前后端都对其做了真实解析表单校验OnCalendarValidator见 hc/front/validators.py要求表达式按空白拆分为 1–4 个分量然后实例化oncalendar.OnCalendar并调用next(it)尝试计算下一个触发时刻解析失败或计算不出未来时刻即报 Not a valid OnCalendar expression.即时预览oncalendar_preview()视图见 hc/front/views.py以当前时区为基准用OnCalendar迭代器解析 schedule生成未来 4–6 次执行时间UTC 时区取 6 次、其他时区取 4 次渲染到front/oncalendar_preview.html模板无效表达式会标记bad_schedule并给出错误提示。相关行为由 hc/front/tests/test_oncalendar_preview.py 覆盖例如*:*在 UTC 下应得到2020-01-01 00:01:00 UTC这样的下一次执行时刻下次执行时刻计算在模型层hc/api/models.py当检查项为oncalendar类型且状态为 up 时get_grace_start()会把上次 ping 时间转换到检查项所在时区用OnCalendar(schedule, last_local)计算下一个预期时刻再转回 UTC 后加上grace宽限期得到告警触发点going_down_after()。这一步意味着 schedule 的任何修改都会影响下一次告警的判定窗口也正因如此在 Web UI 中修改调度时会同步重算alert_after避免因调度变更导致误告警。心跳 URL 的获取与使用在实际接入前先在 healthchecks 中创建检查项Check从检查详情页复制 PING_URL形如https://your-healthchecks.example.com/ping/uuid。文档示例中的PING_URL与your-uuid-here均为占位符需要替换为真实值。系统内置的文档渲染上下文会把PING_URL替换为settings.PING_ENDPOINT your-uuid-here的形式见 hc/front/views.py其中 UUID 对应 URL 路由中的uuid:code见 hc/api/urls.py。如果项目开启了 slug 别名也可使用ping/ping_key/slug形式的可读 URLhc/api/urls.py。部署后的验证与故障排查建议先手动验证心跳修改.service后执行systemctl daemon-reload然后手动systemctl start copy-media.service观察 healthchecks 检查详情页是否出现 start 与 success 两条 ping 记录确认 timer 已启用systemctl enable --now copy-media.timer并用systemctl list-timers查看激活时间是否与 OnCalendar 表达式一致检查退出码上报故意让主命令失败一次确认检查项进入 down 状态并触发通知同时确认$EXIT_STATUS在ExecStopPost中能被正确展开systemd 单元中应使用$EXIT_STATUS而非$转义形式核对时区一致性.timer的OnCalendar表达式与 healthchecks 检查项中配置的时区必须一致否则会在不同时区求值导致未按时收到心跳的误判。小结把 systemd 定时任务接入 healthchecks 的最小改动只在.service文件里加两行 curlExecStartPre发 start、ExecStopPost报退出码或者用 runitor 一键接管.timer里的OnCalendar表达式可以直接复用到检查项的 OnCalendar 类型中配合界面预览与时区/宽限配置无需学习第二套调度语法。整套方案的可靠性建立在 healthchecks 对退出码、表达式解析与下次执行时刻计算的真实实现之上部署后建议按上文步骤做一轮端到端验证。赞分享后端任务调度【免费下载链接】healthchecksOpen-source cron job and background task monitoring service, written in Python Django项目地址https://gitcode.com/gh_mirrors/he/healthchecks点击查看免费下载相关推荐使用 PowerShell 与 Windows 任务计划程序监控 Healthchecks 定时任务使用 PowerShell 与 Windows 任务计划程序监控 Healthchecks 定时任务 PowerShell 脚本可以非常便捷地向 Healthc后端任务调度RxDB 深度解析local-first 响应式 NoSQL 数据库的架构、复制引擎与快速上手RxDB 深度解析local first 响应式 NoSQL 数据库的架构、复制引擎与快速上手 导读 RxDB 是一个面向 JavaScript 应用的 lo后端任务调度C 接入 Healthchecks 定时任务监控使用 HttpClient 发送 Pinging API 请求的完整指南C 接入 Healthchecks 定时任务监控使用 HttpClient 发送 Pinging API 请求的完整指南 Healthchecks 是一个用后端任务调度上一篇Listen gem高级配置技巧5个提升文件监听性能的黄金法则下一篇ATAC性能优化轻量级二进制的最佳实践创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考