[译]OpenStack Object Storage Monitoring

andyyuduo

　　注：翻译的不完整，主要是有些地方翻译后反而妨碍理解，有些不知道怎么翻，anyway，需要时拿来用用也是可行的，顺便共享啦。欢迎提意见。
　　　　一个OpenStack Object Storage(OSOS)集群是一个复杂的野兽－大量的后台进程遍布各个节点，共同工作。因为有如此多的“moving parts“，了解集群内部每时每刻究竟在做些什么就显得相当重要。服务器层级的测量包括CPU利用率，负载，内存消耗，磁盘的用法及利用率等等，这些是必须的，但是还不够。我们需要知道每个服务器中不同的进程都在做什么。比如：node8中的备份对象有多少？备份要花多长时间？如果备份出错会怎么办？
在这个复杂的生态系统里，毫不惊讶，面对这些问题，有很多种方法或以获知答案。下面让我们来了解一下OSOS现有的监控方法。
　　Swift Recon
　　Swift Recon中间件可以提供通用的机器状态（负载均值，socket状态，/proc/meminfo等），同时还有以下swift特有的metrics:

• 每个ring文件的MD5和
  
• 最近的对象备份时间
  
• 每种隔离文件的个数
  
• 磁盘上“async_pending“(deferred container updates)的个数
  

　　Swift Recon是一个安装在对象服务器的pipeline上的中间件，它有一个必填选项：一个本地缓存目录。async_pendings要求每个对象服务器上有一个对应的cron job。可以通过发送HTTP请求到对象服务器去访问数据，或者使用swift-recon命令行工具。
OSOS集群里已经有不错的状态工具，但是通用的服务器测评同已有的服务器监控系统有交叉，要把swift专用测评放到监控系统里的话，数据需要被修整。Swift Recon本质上是一个中间测量收集器。常用的测量工具如collectd,gmond等很可能已经在存储节点运行，它们的数据会加入到状态系统里。因此，它们可以直接同Swift Recon交互。
　　Swift Recon的下一步计划是拓展支持到account和container服务器上。The auditors, replicators, and updaters也可以报告统计数据，但是仅限最近一次的运行情况。
　　
Swift-Informant
Florian Hines开发的Swift-Informant中间件可以获得OS客户请求的实时visibility。它位于proxy server的pipeline，在每一个请求到达Proxy server之后，它发送3类统计数据到StatsD server.

• 一个类似obj.GET.200 or cont.PUT.404的增量计数器。
  
• Timing data for a metric like acct.GET.200 or obj.GET.200. [The README says the metrics will look like duration.acct.GET.200, but I don’t see the “duration” in the code. I’m not sure what Etsy’s server does, but our StatsD server turns timing metrics into 5 derivative metrics with new segments appended, so it probably works as coded. The first metric above would turn into acct.GET.200.lower, acct.GET.200.upper, acct.GET.200.mean, acct.GET.200.upper_90, and acct.GET.200.count]
  
• A counter increase by the bytes transferred for a metric like tfer.obj.PUT.201.
  

　　timing metrics有利于了解客户正体验的服务品质，也可以了解各种服务类型，命令以及响应码的不同排列的数量。Swift-Informant也要求no change  to core Swift code因为它是用中间件实现的。然而，也因为如此，它不能让人看到代理服务器后面的工作情景。如果一个存储节点的响应降低，你也可能看到你的请求变差－要么是高延迟，要么返回错误状态码。你不会知道具体是为什么，或者请求是要去哪里。或许你所考虚的container服务器是在一个好的节点的，而对象服务器是在另一个性能差的节点。
因此我们需要深入视觉到proxy server的后面，集群的操作里去。
　　Statsdlog
　　Florian的statsdlog工程增加了StatsD基于日志事件的计数器。正如Swift-Informant，它也是非侵入式的。但是statsdlog可以从Swift后台进程中追踪事件，而不仅仅是代理服务器。后台进程监听syslog信息的UDP流，当一条日志匹配于一个正则表达式时，StatsD计数器递增。Metric名字映射到JSON文件中的正则pattern。JSON文件允许灵活配置以能从日志流中抽取出想要的metrics。
通常，only the first matching regex triggers a StatsD counter increment, and the counter is always incremented by 1. There’s no way to increment a counter by more than one or send timing data to StatsD based on the log line content. 这个工具可以被扩展去为每一行数据处理多个metrics，包括timing数据。但是即便如此，在日志文本格式和日志分析正则式之间仍然有耦合，这样，为了支持单行多匹配与数据析取，事情变得更复杂。同时，日志处理也在触发事件与发送数据到StatsD之间引入一个延迟。我们当然更希望出错时有错误计数器，一有timing数据就马上发送，避免日志文本与解析正则式之间的耦合，事件与发送数据到StatsD之间没有时间延误。这带出了下一种收集Swift操作metrics的方法。
　　Swift StatsD Logging
　　StatsD使用程序代码来作深入分析。Metrics被有针对性的代码实时发送。发送一个metric的开销相当低：一个sendto UDP包。如果你认为这样的开销还算高的话，StatsD client library可以只发送样本的随机比率部分，flushing metrics upstream时StatsD将估算实际数据。
要避免基于中间件的监控与事后日志处理所带来的弊端，我们把StatsD metrics发送过种整合到Swift本身。我们当前所提交的更改报告了遍布15个swift后台进程的124个metrics以及tempauth中间件。metrics细节可参考https://review.openstack.org/#patch,sidebyside,6058,2,doc/source/admin_guide.rst  。
metrics的发送被整合到日志框架中。要使能的话，在相关的配置文件中配置log_statsd_host信息。同时可以配置port与采样比率。log_statsd_port，log_statsd_default_sample_rate 。...
　　Then the LogAdapter object returned by get_logger(), usually stored in self.logger, has the following new methods:
　　set_statsd_prefix(self, prefix) Sets the client library’s stat prefix value which gets prepended to every metric. The default prefix is the “name” of the logger (eg. “object-server”, “container-auditor”, etc.). This is currently used to turn “proxy-server” into one of “proxy-server.Account”, “proxy-server.Container”, or “proxy-server.Object” as soon as the Controller object is determined and instantiated for the request.
update_stats(self, metric, amount, sample_rate=1) Increments the supplied metric by the given amount. This is used when you need to add or subtract more that one from a counter, like incrementing “suffix.hashes” by the number of computed hashes in the object replicator.
increment(self, metric, sample_rate=1) Increments the given counter metric by one.
decrement(self, metric, sample_rate=1) Lowers the given counter metric by one.
timing(self, metric, timing_ms, sample_rate=1) Record that the given metric took the supplied number of milliseconds.
timing_since(self, metric, orig_time, sample_rate=1) Convenience method to record a timing metric whose value is “now” minus an existing timestamp.
　　注意这些日志函数可以在任何你拥有logger对象的地方调用。如果StatsD日志没有配置，这些方法为空。这样可避免大量的逻辑判断。下面是两个例子。
...
　　Final Thoughts
...
　　我们认为Swift集群动作最好的监控方法是综合了一个通用服务器监控系统，一个Swift特定统计指标收集（polling Swift-specific gauge metrics）机制，一个Swift内部counter与timing metrics深度StatsD日志手段的结合体。对于polling Swift-specific gauge metrics，最好使用一个通用的收集插件。这个插件即可以从swift-recon读数据，也可以自己直接收集信息。
在SwiftStack，我们使用collectd加上一些服务器监控用python插件代码。我们也在collectd中嵌入StatsD服务器，这样每个节点都有一个进程将stats数据“倒”给Graphite"(http://graphite.wikidot.com/)集群。有了这个装置，我们拥有前述所有问题的全覆盖解决方案：general purpose monitoring, Swift-specific gauge monitoring, and real-time counter and timing data directly from Swift.
　　...除了图形化，你也可以实现异常检测，触发警告，维护一个实时的实体健康状态视图，避免各种突发问题。