CloudFoundry源代码学习笔记之Health Manager

长平狐 发布于 2013/11/25 18:34
阅读 677
收藏 0

Health Manage是开源CloudFoundry的重要组件之一,其最终目标:智能监控,确保App运行良好,不用运维。

本文将为你揭开HM神秘的面纱,作者希望你能够通过本文,减少阅读HM源代码的难度。重点部分已加星( * )


- bin/
  bulk_util.rb
    打印测试样例 bulk 中每个droplet的基本信息

  dea_tenancy.rb (与NATS有关)
    订阅dea.heartbeat从传过来的message中查看droplet的信息,如果没问题,就更新对应的dea信息。有问题的话,说明问题并停止该droplet 

  **health_manager**
    启动health_manager
   
  world_sym.rb
    为 hm_next 的性能测试模拟真实环境,略

- config/
  **health_manager.yml**
    intervals

- lib/

  **health_manager.rb**
    自注册成为组件,将其子组件包含进来;启动子组件

  1.varz.rb *
    调用:声明node, collection, counter

    重置实时统计信息; 重置期望的统计信息;

    *从droplet更新实时统计信息* (inc, add等)
    从instances更新数据统计信息,是上面的具体实现;
    *从droplet更新期望数据信息* (inc, add等)

    NAT publish 实时统计信息;NAT publish 期望的统计信息

    private: 创建并初始化runtime, db

  2.reporter.rb (报告者) *
    (功能很简单,两个概念FLAPPING -- indices, CRASHED -- instances)
    订阅 healthmanager.status 和 healthmanager.health
    然后 执行统计(instance级别);执行健康(droplet + instance级别)
    (执行完事后报droplet里每个instance运行信息报告回去)

  3.scheduler.rb (调度者)
    之前;之后;启动;停止;开始任务等等调度命令

  *app_state.rb (call by app_state_provider, harmonizer)*
set_expected_state(values)
process_heartbeat(beat)
app可有多种event_type(通常都是不好的!)
    针对app不同的event_type做出相应处理
跑飞的也算事件啵,也要处理

process_heartbeat
process_exit_dea
process_exit_stopped
process_exit_crash
process_droplet_updated

  4.app_state_provider.rb (call by health_manager)
    主要作用:
   *得到已知的数据支持者*: --> NatsBasedKnownStateProvider.new(config)
   *得到期望的数据支持者*: --> BulkBasedExpectedStateProvider.new(config)
 
   其它:
   取得droplet(id); get_state(id)

  bulk_based_expected_state_provider.rb (call by app_state_provider)
    设置droplet期望的数据
    varz 功不可没!

  common.rb (call by ALL)
    从config配置或default; 找到子组件并注册到hm_registry

  constants.rb --> 顾名思义

  / 让组件(Scheduler & Nudger)能够很好的和我们交互
  / 两种情况下发生:droplet.exited signal 或 flapping instances
  6.harmonizer.rb * -- *基于事件驱动编程在这里得到很好的体现*
    添加日志监听者

    *prepare(与AppState关联很大): missing_instances, extra_instances, exit_dea, exit_crashed, droplet_update (方法最后基本上都调用到了 nudger); scheduler 也被调用* 

    计算延时(xx.to_f);协调延时重启;让所有为挂起状态的重启;分析所有apps;更新期望的数据;执行期望的数据更新;

  nats_based_known_state_provider.rb (call by app_state_provider) *
    启动(NATS监听:dea.heartbeat, drolet.exited, droplet.updated)
    执行droplet退出: 有3种方式退出crash, dea, stopped

    执行心跳, 执行droplet更新: _都是logger并且varz.inc_

    (经常看到统计 heatbeat, app, droplet或者dea的信息,它们到底是什么?这个... .. 要弄懂这些概念真的很难,你只要知道到最后都反应到 instance 上面就行了,也就是说统计xxx信息,到最后基本上都是统计instance的状态)


  / 对外部世界发号施令(CCs to start/stop instances)的接口
  5.nudger.rb **
    (用优先队列来维护这些请求)
    启动/停止 instance
    发布请求信息:publish("cloudcontrollers.hm.requests.#{cc_patition}", message)

  / 为了让原来的HM平滑的过渡到HM-2
  / when in shadow-mode, all outgoing messages are sent to the Shadower, rather than being published to NATS.
  7.shadower.rb **
    订阅(healthmanager.start; cloudcontrollers.hm.requests; healthmanager.status; healthmanager.health) --> 然后执行相应操作:@requests记录timestamp, count等
    检查shadowing? --> max_shadowing_delay 与 timestamp比较,OK
或 unmatched-->warn并@requests.delete(unmatched.message)
    _注意_@requests为一个数组

  varz_common.rb (call by varz)
    这是对 VCAP::Component varz/functionality 的 wrapper/helper
    部分代码可能放到 common/component 更合适
    主要放置一些很基础的低层方法。
    声明node, collection, counter

    reset, push, add, inc, get, set等

Health Manager 整体结构不错,README也很好(建议认真阅读),还有就是阅读过程中别忘了本文开头说的"最终目标",先弄懂最重要的部分。有的代码和文件你不必一定要弄懂~~


原文链接:http://blog.csdn.net/restkuan/article/details/8111592
加载中
返回顶部
顶部