sar 的图形化

用了这么多小巧的监控工具,发现还是 sar 最强大,系统级别的 metric 是应有尽有,不管是实时的秒级监控还是历史数据,对分析近期(比如前一天或者前几天)出现的问题非常有帮助,这比不管是 Zabbix,Nagios 之类的「系统」要强大的多,典型的开相即用的好工具。默认是 10min 一次数据,这个不能完全满足我们的需求,目前我们有部分机器将 interval 缩小到了 1min 一次,并且将默认的 7d 的保存时间延长到了 90d。除此之外,就剩下出图了。
要是闲的蛋疼,可以使用 gnuplot 来把自己关心的所有 metric 全部画出来,但是这个比较麻烦,之前我自己用 gnuplut 玩了几天,对于 mission critical 场景不适用,有时候是等不及你把脚本一个一个写好再运行的。
后来找到了一个叫 Ksar 的工具,非常的方便,导入 sarxx 文件即可自动出图,到目前为止没有找到比他更方便更简单的方式了。唯一的不足是没有把 sar -A 列出来的所有 metric 都画出来,不过对于一般的问题,Ksar 出的图足够用了。Ksar 的启动图是不是很像 CS 中的场景。

对于昨天以及之前的数据,可以直接到 sa/sarxx 去取,但是对于只有 saxx(比如当天的数据或者由于某些原因 sarxxx 文件丢失了) 的文件,首先需要通过 sar 获得 sarxx  文件,然后需要将 12 小时制转换成 24h 制的才可以丢到 ksar 里面出图:
# LC_TIME="POSIX" sar -f sa30 -A  | tee sar30

注意LC_TIME 这个环境变量。另外,阿里在此基础上搞了个 tsar,个人不是很看好,原因见这里

 

ref:
http://honglus.blogspot.com/2011/02/graphing-sar-output.html
http://brablc.com/2011/06/06/how-to-change-sar-output-time-format-to-24/

调整 ring buffer & interrupts affinity 的重要性

最近线上出现了不少由于 ring buffer 设置过小而导致的丢包问题问题,这个值在这之前我们一直使用的是出场的默认值,因此跟动辄 2048 的 max 相比,200 或者 500 确实小了点。
比如看看某台 web server 的监控

看了下 ring buffer 以及 interrputs 的分布
# ethtool  -S em2 | grep dis
     tx_discards: 0
     rx_discards: 77491

# ethtool  -g em2
Ring parameters for em2:
Pre-set maximums:
RX:   2047
RX Mini:  0
RX Jumbo: 0
TX:   511
Current hardware settings:
RX:   511
RX Mini:  0
RX Jumbo: 0
TX:   511

默认的太小了,适当的调大。 另外,由于这台机器网卡本身的问题,无法均匀的分散 interrupts,只能先把能分散的给分散了。记得把 irqbalance 给关了,这玩意儿没什么用:
# /etc/init.d/irqbalance status
irqbalance is stopped

关键还是配置管理做的不到位,不然不会出现这么低级的错误。

munin 以及 zabbix 的聚合(aggregate)

这类需求应该是评估监控系统是否合适的一个重要因素了。
munin 虽然具备,不过实现起来并不是很智能,需要人肉书写。以 mongo 的为例,我们需要聚合分布在不同机器上的 instance 上的 shard 的状态。
在 munin.conf 里面 include 一个名叫 mongo 的目录专门用来做聚合。先定义涉及到的 host:
[dc_shard;jaseywang-db9]
    address 192.168.1.43
    use_node_name yes

[dc_shard;jaseywang-db10]
        address 192.168.1.83
        use_node_name yes

[dc_shard;DailyCounter]
        update no

接下来就是定义需要聚合的 item 了,这个需要每个 host 都有对应的 plugin,比如这里叫 mongo_ops_xxx,xxx 是起 REST 端口:
dc_shard.graph_title DailyCounter
dc_shard.graph_category DailyCounter
dc_shard.graph_total total
dc_shard.total.graph no
dc_shard.graph_order insert update delete getmore
dc_shard.insert.label insert
dc_shard.insert.sum \
  jaseywang-db9:mongo_ops_28701.insert \
  jaseywang-db10:mongo_ops_28711.insert \
  jaseywang-db10:mongo_ops_28716.insert
dc_shard.update.label update
dc_shard.update.sum \
  jaseywang-db9:mongo_ops_28701.update \
  jaseywang-db10:mongo_ops_28711.update \
  jaseywang-db10:mongo_ops_28716.update

有点需要注意的是,需要严格遵循其语法,该是句号的使用句号,使用冒号的用冒号。

zabbix 的相对比较简单,既然是需要聚合的,划分到同一个 hostgroup,接着就是用其原生支持的 "Zabbix aggragate" 这个 Type 就好了。建立好了 item,trigger、graph 之类的就都有了,还是很简单的。顺便说下 Cacti,只要熟悉 rrdtool,问题也很好解决。
 

使用 cacti 监控网络设备

不管在何种发型版本上部署,基本都需要如下的包:
httpd
php
php-mysql
php-snmp
php-ldap(when using LDAP authentication)
php-xml
mysql
mysql-server
net-snmp(depending on the distro, net-snmp-utils may be required)
crond (cron, cronie or the like)
wget
patch

0.8.7h 算是比较稳定的版本,最新的 0.8.8a 在一些 plugins 会有兼容性的问题。
简单记录下安装过程。
Continue reading

代码变更对系统的影响

某台 Mongo,监控的 agent 突然取不到所有的数据,ssh 也直接显示:
ssh_exchange_identification: Connection closed by remote host
前提是我已经加了 public key。

通过远程卡登录,出现大量的如下信息:
INFO: task dpkg:5206 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disable this message.

尝试登录,进不了 shell,报错:
login: failure forking: Cannot allocate memory

猜测可能是机器的某些资源耗尽引起的。不得以强行 warn boot。之后的一小段时间内没有出现此问题,但是大概 2h 之后,又出现了上面的情况,查看系统资源的占用的情况,下面三张图分别是那段时间的 inode table, interrupts and context switch 以及 threads 显示

可以发现在 18 号的 20 点出现了一次波动,reboot 之后稍有缓解,但是从 24 点又开始出现了 threads 直线上升的情况。在网络没有变动,系统没有变动的情况下,惟一的可能就是代码有问题了。经排查,确实是代码引起的问题。
除了 dev 对变更后的代码最好监控之外,以后对这类的问题应该更加敏感些。

试用 boundary 引发的一些思考

先申明一点:以后所有的公开场合我会使用大陆这个名词来表示某些特殊的群体,毕竟中国除了西朝鲜之外还包括 HK, MC, TW(?)。
boundary 是啥,引用 NYTIMES 的一段话:

Boundary, a small start-up in San Francisco that monitors the performance of applications in the cloud, offers a product that shows just how complex a mess that is, in close to real time. That is a big improvement from the daily or less frequent check-ins people do at most data centers. More important, the monitoring can show where slowdowns might be occurring, or where operational savings might be found.

about 确实是蛮吸引人的,其联合创始人 Cliff Moon 兼 CTO 的来历也是牛逼哄哄,为 NoSQL、Scala、Erlang  做了不少事,strom 项目也有他的不少贡献。

大家都知道 instagram 被 FB 收购的时候不过 10 来人的样子;linode 从 02 发展到现在,10年,员工人数 11 年统计的时候不过 20 人不到。

同样的,boundary 2010 成立,到现在 12 年做了两年了,也不过是 50 人不到的样子。对比下大陆的,就不指名道姓的说了,做物流的 2 年估计直接上千了。

试用他们的服务器目的很简单,跟他们自身的描述基本一致,发现一些问题。于是注册了个帐号,安装 agent 的方式还蛮多的。最初选择的使用 bash scipt 这种最土鳖的方式安装,以为是墙的原因,特意加了 http proxy,但是试了几次依然不成功,就直接放弃了;后来通过 puppet 的方式安装,安装的第一个 web server 成功了,但是安装第二个 web server 的时候又可耻的失败了 :-(

至此对 boundary 的印象就不是很好,正式开始试用,UI 比较绚;实时出图,这个应该是以 agent 拼命的抓取资源为代价的,这导致我们的 web server 的 load 明显的高了一级;功能方面,基本符合我们的预期要求,但是通过出来的数据并没有能找到我们系统中存在的问题;agent 全程是走 SSL 的,因此数据基本是获取不到的,关于该 agent 会不会在我们的 server 上做不该做的事,这个我们不敢保证,但是有点一可以肯定的是,他出现流氓的概率会远比大陆的低的多。 Continue reading