在Cloud Foundry中有一個叫collector的組件，該組件的功能是通過消息總線發現在Cloud Foundry中註冊過的各個組件的信息，然後通過varz和healthz接口來查詢它們的信息併發送到指定的存儲位置。
本文從collector的功能出發，主要講述以上兩個功能的源碼實現。
發現註冊組件
在Cloud Foundry中，每個組件在啓動的時候後會以一個component的形式向Cloud Foundry註冊，同時也會作爲一個組件，向NATS發佈一些啓動信息。
首先以DEA爲例，講述該組件register與向NATS publish信息的實現。首先看以下/dea/lib/dea/agent.rb中register的代碼：
VCAP::Component.register(:type => 'DEA',
:host => @local_ip,
:index => @config['index'],
:config => @config,
:port => status_config['port'],
:user => status_config['user'],
:password => status_config['password'])這段代碼表示，DEA通過VCAP::Component對象中的register方法，實現註冊。以下進入vcap-common/lib/vcap/component.rb中的register方法：
def register(opts)
uuid = VCAP.secure_uuid
……
auth = [opts[:user] || VCAP.secure_uuid, opts[:password] || VCAP.secure_uuid]
@discover = {
:type => type,
……
:credentials => auth,
:start => Time.now
}
……
@healthz = "ok\n".freeze
start_http_server(host, port, auth, logger)
nats.subscribe('vcap.component.discover') do |msg, reply|
update_discover_uptime
nats.publish(reply, @discover.to_json)
end
nats.publish('vcap.component.announce', @discover.to_json)
@discover
end可見，在實現register方法的時候，首先通過傳遞進來的opts參數，構建一個@discover實例變量，訂閱了一個vcap.component.discover的消息，又發佈了一個vcap.component.announce的消息。關於collector的發現註冊組件的功能中，直接關聯的register方法中發佈的主題，因爲collector通過訂閱這個主題的消息，將json化的@discover變量取到，然後做相應的處理。
def send_data(data)
@adapters.each do |adapter|
begin
adapter.send_data(data)
rescue => e
Config.logger.warn("collector.historian-adapter.sending-data-error", adapter: adapter.class.name, error: e, backtrace: e.backtrace)
end
end
end之前已經涉及了collector組件訂閱消息的話題，現在進入collector/lib/collector.rb中，實現消息的訂閱還有其他的消息請求：
@nats = NATS.connect(:uri => Config.nats_uri) do
Config.logger.info("collector.nats.connected")
# Send initially to discover what's already running
@nats.subscribe(ANNOUNCE_SUBJECT) { |message| process_component_discovery(message) }
@inbox = NATS.create_inbox
@nats.subscribe(@inbox) { |message| process_component_discovery(message) }
@nats.publish(DISCOVER_SUBJECT, "", @inbox)
@nats.subscribe(COLLECTOR_PING) { |message| process_nats_ping(message.to_f) }
setup_timers
end def process_component_discovery(message)
message = Yajl::Parser.parse(message)
if message["index"]
Config.logger.debug1("collector.component.discovered", type: message["type"], index: message["index"], host: message["host"])
instances = (@components[message["type"]] ||= {})
instances[message["host"].split(":").first] = {
:host => message["host"],
:index => message["index"],
:credentials => message["credentials"],
:timestamp => Time.now.to_i
}
end
rescue => e
Config.logger.warn("collector.component.discovery-failure", error: e.message, backtrace: e.backtrace)
end一般情況下，當Cloud Foundry的組件啓動是發佈vcap.component.announce消息後，很快在@components中就會有相應的信息，這樣的話，也就是實現了“發現註冊組件”的功能。
獲取組件varz和healthz併發送
在以上功能中，collector只是實現了發現組件，只包括組件的ip：port信息，index，crdentials等信息，並不帶有其他關於組件運行時產生的數據信息。而通過varz和healthz訪問那些註冊的組件，正好可以做到這些收集varz和healthz信息。
實現的過程中，首先是使用添加週期性定時器：EM.add_periodic_timer(Config.varz_interval) { fetch_varz }，在一定的週期內，執行fetch_varz方法，以下進入fetch_varz方法：
def fetch_varz
fetch(:varz) do |http, job, index|
……
end
end def fetch(type)
@components.each do |job, instances|
instances.each do |index, instance|
next unless credentials_ok?(job, instance)
host = instance[:host]
uri = "http://#{host}/#{type}"
http = EventMachine::HttpRequest.new(uri).get(
:head => authorization_headers(instance))
……
http.callback do
begin
yield http, job, instance[:index]
rescue => e
……
end
end
end
end
end varz = Yajl::Parser.parse(http.response)
now = Time.now.to_i
handler = Handler.handler(@historian, job)
Config.logger.debug("collector.job.process", job: job, handler: handler)
ctx = HandlerContext.new(index, now, varz)
handler.do_process(ctx)@historian對象的功能是創建了網絡連接，具體代碼實現在/collector/lib/collector/historian.rb中：
class Historian
def self.build
historian = new
if Config.tsdb
historian.add_adapter(Historian::Tsdb.new(Config.tsdb_host, Config.tsdb_port))
Config.logger.info("collector.historian-adapter.added-opentsdb", host: Config.tsdb_host)
end
if Config.aws_cloud_watch
historian.add_adapter(Historian::CloudWatch.new(Config.aws_access_key_id, Config.aws_secret_access_key))
Config.logger.info("collector.historian-adapter.added-cloudwatch")
end
if Config.datadog
historian.add_adapter(Historian::DataDog.new(Config.datadog_api_key, HTTParty))
Config.logger.info("collector.historian-adapter.added-datadog")
end
historian
end
……
end
現在回到fetch_varz中，創建爲handler實例對象之後，還創建了一個ctx對象，最後通過handler的do_process方法處理了ctx對象，現在進入collector/lib/collector/handler.rb中，查看do_process方法：
def do_process(context)
varz = context.varz
send_metric("mem_free_bytes", varz["mem_free_bytes"], context) if varz["mem_free_bytes"]
……
varz.fetch("log_counts", {}).each do |level, count|
next unless %w(fatal error warn).include?(level)
send_metric("log_count", count, context, {"level" => level})
end
process(context)
end def process(context)
send_metric("can_stage", context.varz["can_stage"], context)
……
state_counts(context).each do |state, count|
send_metric("dea_registry_#{state.downcase}", count, context)
end
metrics = registry_usage(context)
send_metric("dea_registry_mem_reserved", metrics[:mem], context)
send_metric("dea_registry_disk_reserved", metrics[:disk], context)
end def send_metric(name, value, context, tags = {})
tags.merge!(additional_tags(context))
……
@historian.send_data({
key: name,
timestamp: context.now,
value: value,
tags: tags
})
end def send_data(data)
@adapters.each do |adapter|
begin
adapter.send_data(data)
rescue => e
Config.logger.warn("collector.historian-adapter.sending-data-error", adapter: adapter.class.name, error: e, backtrace: e.backtrace)
end
end
end以上講述從獲取varz到發送給TSDB等數據存儲模塊的流程，關於發送的是什麼信息，還沒有具體深入。這裏以router爲例，講述發送的信息的類型。源碼於collector/lib/collector/handlers/router.rb中：
def process(context)
varz = context.varz
send_metric("router.total_requests", varz["requests"], context)
send_metric("router.total_routes", varz["urls"], context)
send_metric("router.ms_since_last_registry_update", varz["ms_since_last_registry_update"], context)
send_metric("router.bad_requests", varz["bad_requests"], context)
send_metric("router.bad_gateways", varz["bad_gateways"], context)
return unless varz["tags"]
varz["tags"].each do |key, values|
values.each do |value, metrics|
if key == "component" && value.start_with?("dea-")
# dea_id looks like "dea-1", "dea-2", etc
dea_id = value.split("-")[1]
# These are app requests, not requests to the dea. So we change the component to "app".
tags = {:component => "app", :dea_index => dea_id }
else
tags = {key => value}
end
send_metric("router.requests", metrics["requests"], context, tags)
send_latency_metric("router.latency.1m", metrics["latency"], context, tags)
["2xx", "3xx", "4xx", "5xx", "xxx"].each do |status_code|
send_metric("router.responses", metrics["responses_#{status_code}"], context, tags.merge("status" => status_code))
end
end
end
end綜上代碼分析，可以得到框架圖如下：
以上便是Cloud Foundry中collector組件的功能分析。
關於作者：
孫宏亮，DAOCLOUD軟件工程師。兩年來在雲計算方面主要研究PaaS領域的相關知識與技術。堅信輕量級虛擬化容器的技術，會給PaaS領域帶來深度影響，甚至決定未來PaaS技術的走向。
轉載請註明出處。
這篇文檔更多出於我本人的理解，肯定在一些地方存在不足和錯誤。希望本文能夠對接觸Cloud Foundry中collector組件的人有些幫助，如果你對這方面感興趣，並有更好的想法和建議，也請聯繫我。
我的郵箱：[email protected]新浪微博：@蓮子弗如清