- hm9000跟hm_next（healthmanager）功能类似。在cloudfoundry集群中担任至关重要的角色
- 尝试启动缺失情况下的实例，停止异常实例
- 获知和报告应用执行的实际实例个数
- 从DEA中迁移应用到其它DEA - hm9000组件工作须要获取的两种状态
- desired state: 期望的状态，哪些apps应该是running状态，哪些instances应该是running状态。这些信息是通过http协议从CC中发送过来
- actual state: 实际状态，哪些instances实际上是running状态。这些信息通过via Nats和DEAs中接收，每一个DEA节点会周期性的发送heartbeat心跳来确认running应用 - hm9000存储desired state和actual state在etcd中，有了这两种状态。hm9000能够决定是否启动或者停止一个实例.这个信息通过Nats发送到CC。最后CC通过Nats发送消息到DEA决定是否启动或者停止一个实例
- hm9000是至关重要的组件，在hm9000正常工作前要确保hm9000所维护的环境都是正常状态，因此我们介绍下“freshness”的概念
- 当hm9000能够与NATS通信而且能够周期性的从DEA节点中接收心跳而且能够正确的把actual state存储在etcd中。那么这个actual state是我们期望的“fresh”状态。假设它们中不论什么一个环节出现异常（NATS/no DEA heartbeats/etcd writes fail），这个actual state都将标记为“fressness”或者“not fresh”,这时候hm9000将停止不论什么会话（交互）动作
- 当hm9000从CC中下载desired state成功（without timeout）而且能够正确存储在etcd中时，那么这个disired state是我们期望的"fresh"状态，同actual state一样不论什么一个环节出现异常都将导致hm9000工作异常。即上面所述的“fressness” - hm9000中内置了5个组件，每一个组件都负责不同的作用于功能。而且每一个组件都有自己的日志记录
- listener: 负责监听DEA heartbeats（心跳）通过NATS，来确定actual state，假设actual state状态是not fresh，那么能够查看listener的log来确定为什么hm9000不能维护 actual status
- desired_state_fetcher: 周期性的从cc获得desired state，相同当disired_state状态时not fresh时，能够查看fetcher的log来确定问题所在
- analyzer: 分析actual state和disired state来make decisions（做决定）
- sender: 运行analyzer所做出的决定而且向CC发送通知
- api_server: 对cc的app state（应用状态包含实例个数）request做出response - 排错
- 确保CC配置能正确訪问hm9000：CC的配置中有一项hm9000_noop项，假设设置为true那么cc将仅仅listen health_manager_next,而且仅仅对health_manager_next请求实例执行个数,假设设置成false那么将被hm9000代替
- 确保etcd不是错误的状态，当etcd是错误状态的时候，那么state不能被写入etcd，会引起hm9000 freness,那么bosh ssh进入每一个etcd节点执行monit stop all然后删除/var/vcap/store文件夹再执行monit start all
- /var/vcap/packages/hm9000/hm9000 dump --config=/var/vcap/jobs/hm9000/config/hm9000.json在hm9000虚拟机中执行这个命令。能够更直观的看日志 - 我遇到的hm9000问题是应用正常启动，可是cf apps显示state和instances不对
- 按上述步骤排查之后发现时fetcher问题也就是和cc通信问题，问题所在市ssl证书没能得到验证，cc主动拒绝链接
解决方法在bosh 部署文档中改动skip_cert_verify: true此选项设置为true的时候是告诉cc忽略不对的ssl证书
- 至此问题解决。OK~！