rubyist518 (superiorlu)

如何持续监控 Unicorn 的性能指标

rubyist518 — Wed, 20 Apr 2016 16:28:18 +0800

背景介绍

最近用 Grape 重写了一份 API，马上要上线了，突然接到 boss 通知，需要做好应用服务器监控，以便上线遇到突发情况。于是乎从万能的 github 上找到了这个开源的代码：unicron_metrics。用起来还不错，下面给大家介绍一下认识。

是什么

unicorn_metrics是采集基于 Rack 应用服务性能数据的工具，尤其针对类似 Unicorn 的多进程服务器，并提供一个对外查看数据的接口。

如何监控

通过 raindrops 来采集Uincorn指标数据，同时通过构建Middleware统计应用中 HTTP 指标数据。

监控指标

unicorn_metrics监控指标分 2 部分：http 指标和 raindrops 指标，下面介绍各方面的指标：

指标名称	指标类型	说明
request.GET	timer	GET 请求的消耗时间 (ms)
request.POST	timer	POST 请求的消耗时间 (ms)
request.PUT	timer	PUT 请求的消耗时间 (ms)
request.DELETE	timer	DELETE 请求的消耗时间 (ms)
request.HEAD	timer	HEAD 请求的消耗时间 (ms)
responses.2xx	counter	响应状态为 2xx 的次数
responses.3xx	counter	响应状态为 3xx 的次数
responses.4xx	counter	响应状态为 4xx 的次数
responses.5xx	counter	响应状态为 5xx 的次数
raindrops.calling	gauge	应用服务器调度的数量
raindrops.writing	gauge	被写入数据的客户端的数量
raindrops.active	gauge	所有进程中已连接并尚未关闭的 sockets 的连接数
raindrops.queued	gauge	等待连接 sockets 的请求数

监控步骤

1.安装

$ gem 'unicorn_metrics', github: 'superiorlu/unicorn_metrics'
$ bundle

2.配置 unincor_metric.rb

#config/initializers/unicorn_metrics.rb

if defined?(UnicornMetrics)
  UnicornMetrics.configure do |c|
    c.app_name = 'app_name'
  end
end

3.配置 config.ru (Rails 无需配置)

# config.ru

 require 'unicorn_metrics/middleware'
 use UnicornMetrics::Middleware
 # other middleware...
 run N::Application

4.visit http://localhost:3000/metrics, 返回 unicorn 的各方面的指标。

实时监控和报警

由于unicorn_metrics只提供了查看unicorn性能指标的接口，根据业务的需求我们对其进行了修改，使其可以在装有我们 CloudInsight 探针的服务器上使用 Cloud Insight Ruby SDK 进行实时回传性能数据，形成 dashboard 图表同时在服务器出现问题时及时报警。具体数据图表见下图：

数据图表组成仪表盘示例：http://superiorlu.github.io/dashboards.html

源码见：https://github.com/superiorlu/unicorn_metrics

小结

本文介绍了使用unicorn_metris对Unicorn进行持续监控。使用Cloud Insight Ruby SDK，不但可以传输性能数据，还可以传输自定义的业务数据，将数据以图表的展示出来，并根据需求添加相应的报警服务。

RubyCritic-一款不错的检测代码质量工具

rubyist518 — Fri, 15 Jan 2016 17:49:17 +0800

最近在开发Cloud Insight API 时，发现一个可以检测 ruby 代码质量的工具-RubyCritic。

RubyCritic 集成 Reek, Flay 和 Flog这 3 个分析代码的工具，对你的 Ruby 代码进行静态分析并生成质量报告。

功能介绍

可以总览你的项目，并且可以对代码打分 (百分制)
根据各自的坏味道数量建立文件索引

对不同文件按照改动频率、复杂度、重复度和坏味道4 个维度进行综合评定代码质量等级

3. 可以查看具体的类文件中的代码质量问题

用法

看一下 rubycritic(2.7.0) 指令

rubycritic --help

Usage: rubycritic [options] [paths]}

-p, --path [PATH]               设置质量报告存放的路径(默认: tmp/rubycritic)  
-f, --format [FORMAT]           设置报告格式:
                                  html (默认)
                                  json
                                  console 
-s, --minimum-score [MIN_SCORE] 设置最小分数
-m, --mode-ci                   使用CI模式(更快，但仅分析最后一次提交)
    --deduplicate-symlinks      基于最后目标去除重复的符号链接
    --no-browser                不使用浏览器打开html格式的报告
    --suppress-ratings          压制质量评级 
-v, --version                   显示版本号
-h, --help                      显示帮助信息

运行

bundle exec rubycritic

的效果如下图：

从上图也能看出 rubycritic 分析代码流程。

其他用法

平时使用guard工具的同学，可以使用guard-rubycritic, 代码改动时会自动分析你的代码。有兴趣的同学也可以将它集成到Jenkins CI。

扩展功能

在使用rubycritic过程中，每次都要手动打开浏览器进行查看质量报告，太麻烦了。于是给它添加一个功能

目前仅支持 Linux 和 Mac OSX 系统：

支持 Linux 浏览器： Firefox（默认）、Chrome和 Chromium

支持 Mac OSX 浏览器： Safari（默认）、Chrome和 Firefox

运行步骤

修改 Gemfile ruby gem 'rubycritic', github: 'superiorlu/rubycritic', branch: 'open_with_browser'
运行rubycritic -O chrome即可。

源代码：https://github.com/superiorlu/rubycritic/tree/open_with_browser

总结

本文简单介绍了rubycritic和用法，可能某些知识点会有所遗漏，不足之处请大家指正。

更新 (2016.01.29)

目前rubycritic已经更新到了2.7.0, 已经默认使用浏览器打开 html 格式的报告了。

你应该使用的 5 种 Ruby 方法

rubyist518 — Fri, 08 Jan 2016 14:38:39 +0800

最近rubyweekly回顾了 2015 年比较好的文章，看到一篇文章，感觉挺有意思。分享给大家原文。

5 种方法：

大家平时写 Ruby 的遇到比较有用的方法，不妨一起分享一下。

探讨如何统计 Ruby 应用服务器使用内存方法

rubyist518 — Wed, 14 Oct 2015 16:44:53 +0800

最近在解决探针获取 Ruby 应用服务器的内存使用的情况，将解决的思路总结一下，希望对此感兴趣的伙伴一起探讨。

先对比应用服务器：Puma和Passenger，下面对比这 2 个服务器内存统计，

Puma (2.13.4)

单进程模式：直接获取进程 id: Process.pid

memory = `ps -o rss= #{Process.pid}`.to_f / 1024 #单位:MB

cluster 模式：以启动 2 个 worker 进程为例: 从上面截图可以看到，Puma 启动后会出现 3 个进程：1 个 master 进程和 2 个 worker 进程。内存的使用情况 (见RSS列):

(109908 + 109868 + 7256 ).to_f / 1024 = 221.7109375 #单位:MB

而对于探针来说，一个探针实例是伴随进程一起启动的，也就说一个探针只能识别自己所在的进程 id，那如何获取应用服务器使用的内存？我们用其中 1 个 woker 进程所在的进程组 [PGID] 看一下:(为啥不是父进程？, 见下文 Passenger) 这 3 个进程都在相同的进程组里，而且进程组号为 master 的进程 id，那我们就可以用这个信息获取应用服务器的所使用的内存：

得到 1 个 worker 进程 id: Process.pid
获取所在进程组：Process.getpgrp
获取到进程组内所有的进程： ruby `ps -o pid,pgid -e | grep -w "#{pgrp_id}"`.split(/\s+/).uniq 4.累加进程组内进程内存和即为应用服务器使用内存： ruby pids.inject(0.0){|m, pid| m + memory(pid)} ## Passenger (5.0.20) 启动 Passenger 后的 Process 信息：对 Passenger 架构感兴趣的请移步到这儿. 查看一下 worker 所在进程组和父进程: 通过 PPID 可以看出 Passenger core —> Passenger AppPreloader —> Passenger RubyApp 三者为爷 - 父-子关系，当服务器请求量增大时AppPreloader会产生新的进程来响应请求，从而新的RubyApp进程的PPID即为AppPreloader的PID，这样看来就可以将同一个PPID的进程加起来得到应用服务器的内存？

由于 Passenger 会根据服务器的负载量动态调整进程数，当服务器请求量较小时，Passenger 会 kill 多余的进程，会出现下面的情况：

AppPreloader也被 Passenger 杀掉了。原RubyApp进程的PPID变成了 1。这时如果服务器的请求量增大，应用服务器进程会成为这样：

Passenger core 产生新的AppPreloader进程，并且AppPreloader产生新的RubyApp进程，这时如果只用PPID统计应用服务器内存就会不准确，所以要统计 Passenger 的使用的内存还得通过累加在同一个进程组 (PGID) 的所有进程使用的内存和得到。

由于Unicorn和Rainbows都与 Puma 的 cluster 模式 [master+worker 模式] 类似，内存统计的方式可以参考上文的 Puma。

总结：

由于Thin启动多个 server 后没有类似的特点，上面方法不适用于 Thin，有好方法的伙伴们可以告知

在解决探针统计应用服务器的内存问题上，摸索出了上面的一条路子，如果小伙伴们有其他更好的方式，可以一起探讨一下。

10 月 15 日更新

对于Thin，有一种思路是使用foreman来管理应用进程，这样就可以统一计算应用服务器内存方法。欢迎拍砖。