SentinelSentinel会监测相关条件，一旦满足触发条件便立即采取行动。而日程安排通常基于时间触发，而Sentinel则是基于 特定条件变为真时触发。
您可以在工厂的“日程安排”板块中找到它。
它的监测对象
您可以自定义监测条件——比如检查失败、代码库中出现特定模式、 关联系统发出的信号，或是标准合规项偏离要求。
监控器触发后便会启动修复任务：这是一项普通任务，配有详细规范，会经历与 其他任务相同的规划、构建、验证和审核流程。
为何这种设计是安全可靠的
Sentinel不会直接修改您的代码。它会发起修复代码的任务，最终生成的pull request需经您审批。
这一点的重要性远超想象。若自主系统直接编辑生产环境代码，在您最需要审核的节点——即无人请求且无人监管时——就会缺失审核环节。通过常规流程处理，既能提升效率，又能保留控制权。
模板
常用的监控器会以模板形式提供，无需您从零开始编写——比如定期健康检查、偏差检测以及标准修复循环。
您可以从模板入手，先让其处于建议模式运行一段时间，调整后再允许其自主发起任务。
如何对其进行管控
Sentinel发起的任务会与其他任务争夺同样的代理资源。频繁触发的监控器可能会悄悄占用您的算力。
以下三条规则可确保其发挥实用价值：
- 给它的优先级要低于人工请求的任务是。
P2或P3. - 设定具体的触发条件。“某项测试失败”会在繁忙的代码库中频繁触发；而“该特定检查在主分支上失败超过一小时”则仅在确实出现问题时才会触发。
- 审核产出结果如果某个监控器发起了二十个任务，而您仅合并了其中两个，那么它只是在产生无用噪音并浪费资源，并未创造实际价值。
关注合并率而非触发频率
衡量监控器效能的真实标准是它所发起的任务中最终被合并的比例。触发频率低但每次都准确无误的监控器才是有效的；而频繁触发却常被忽略的监控器只会徒增负担。