关于容器异常终止的重新调度

[sunyi00]

现在咱们的策略是否是尝试 3 次，之后放弃？

如果是这样的话，能否给一个 callback 配置，在放弃时可以 post 一下信息？

关于容器状态报警，这个事情的本质应该是这样的：

deployd 的责任是判断当前状态是否和预期的状态（spec）一致（例如 instance 数），如果不一致，则尽可能调整当前状态，使之于 spec 一致。

所以，对于报警，策略应该是：对于和 spec 不一致的状态，均认为是异常，进行报警。通过 retry 和 check_interval 来给 deployd 足够的时间尝试修复。在指定时间内 deployd 未能成功修复的，则应响亮的报警出来。

--by hongqn

[panli889]

@sunyi00 现在的默认策略是在 30 min 内重启了 3 次后 deployd 会认为是异常，不再进行处理。

理解教授的意思，报警确实是应该存在的，@supermeng 正在加这个功能，不过我们目前思路稍微不太一样。。我们目前的思路是尝试使用单独的组件（假如叫 cmonitor）通过监听 etcd 中容器的信息给容器相关负责人发送容器重启信息，看起来通过 callback 思路的话，deployd 可以通过调用 callback 函数通知 cmonitor 去给相应的人员发送报警信息？

另外看起来 console 也可以使用类似的方式调用 cmonitor 去通知相应的人员 app 被进行了修改

[sunyi00]

那之前 @xtao 做的一个 App 貌似就在实现 cmonitor 的功能...具体 可咨询 涛涛 :)

[xtao]

那我来处理一下，开源 REL 和 Hedwig (new) 这 2 个项目。另外这个涉及到了我之前跟 @panli889 提到的提供一个集群内部事件暴露给集群用户的问题。。。

[xtao]

cmonitor 做的工作，就是现在 Hedwig 中的 icinga proc 的工作。另外这个 callback 我觉的做成事件暴露出来更好一些。这样扩展性更强，定制性也更好一些。