Tair是淘宝自主开发的一个分布式 key/value 存储系统。Tair 分为持久化和非持久化两种使用方式. 非持久化的 Tair 可以看成是一个分布式缓存. 持久化的 Tair 将数据存放于磁盘中. 为了解决磁盘损坏导致数据丢失, Tair 可以配置数据的备份数目, Tair 自动将一份数据的不同备份放到不同的主机上, 当有主机发生异常, 无法正常提供服务的时候, 其于的备份会继续提供服务.项目主页参见：淘宝Tair.
受NoSQLFan上的一遍文章Redis监控技巧 一文的启发，本文系统的总结下我们在生产环境使用Tair时进行的各类监控和统计，希望对开源社区有所回馈。
Tair最直接的监控和获取统计信息的方法是采用其提供的工具tairclient，按照如下方式使用，可以获取很多状态信息：
./sbin/tairclient -g group_1 -c tair_configserver_ip:port -l stat
- 配额信息
- dataserver存活信息
- 每个area(类似于namespace的信息)的dataSize，evictCount，getCount（per second），hitCount（per second），itemCount，putCount（per second），removeCount（per second），useSize信息
- 是否正在迁移（isMigrating false）
- group状态，代表是否有桶丢失（group_name status OK）
对于上述信息有如下说明：
1.dataSize和itemCount可能并不精确，参见“统计的itemcount问题”;
2.dataSize、evictCount等，也可以通过tair_client_api.hpp的get_data_stat接口获取，可以进行更灵活的统计和计算；
3.由于tair bucket的桶迁移并不常见，所以监控迁移状态作为一种预警非常有必要；
4.监控group状态，如果不为OK，证明有bucket的所有副本均丢失，此时tair的configserver不会rebuild分配表，需要人工介入处理；
服务状态监控
使用客户端模拟客户请求，如果连续5次均失败，证明访问出现问题，需要报警。此处需要注意的是，构造的key必须是随机的。（因为根据tair的hash算法，同样的key会一直落到同一个bucket）；
配置监控
group.conf是由tair configserver使用，并自动在master slave间同步的配置文件。该文件有许多重要的信息，比如副本数、dataserver地址、area capacity等信息，可能经常需要手工进行修改。因此，为了保证严格一致，我们使用inotify结合rsync对group.conf的一致性进行监控，如果在任何状况下，发现master和slave的group.conf不一致，则报警。
ldb level 0文件数目监控
tair的ldb存储引擎使用的是google开源的leveldb，其level0的文件数会影响到读取性能（超过一定值，会减慢请求，甚至是挂起请求）。在tair出现大量bucket迁移时，有可能会出现level 0文件数骤增，因此需要对level 0文件数做监控，超过阈值报警。
获取level 0文件数的方法非常简单，只需如下一行语句：
tac $log_file | grep -m 1 "compacted to:" | awk '{print $6}'
$log_file是ldb目录下的LOG文件。
内存级kv使用空间监控
tair的内存级存储引擎类似于memcache，由于我们的业务方有部分是将内存级当作准存储在使用，所以有必要对内存级area的area使用的内存空间做监控，如果达到阈值（如设定capacity的80%）则给业务方报警，避免不必要的数据evict。
thrift层面的监控
为了方便多种语言的访问，同时为了进行管控，我们提供了thrift形式的访问接口，在thrift层面做了大量的工作。针对thrift，我们统计了不同db的访问量、占用空间、QPS、访问时延等数据，用来在访问质量出现下降时报警，同时每天发出统计报表。这个层面的报警统计可以和tair的统计配合使用。
bucket分布表和迁移状态
Tair的桶分布表记录在configserver/data/目录下，使用cst_monitor工具，可以查看最新的桶分布表，同时在存在数据迁移时，可以查看最终生成的表，以及实时迁移表，使用这份数据，结合tairclient可以预估迁移进度。使用方式如下：
./cst_monitor ../configserverdir/data/group_1_server_table
注：以上监控项，涉及到趋势的，均使用ganglia做前端，可以使用gmetric或自行编写插件，方便的将数据导入ganglia。ganglia还顺便用于分析cpu\memory\disk等的使用情况。
除以上所述监控外，为了提高服务质量，便于迅速的定位问题，我们还在对ldb存储引擎内部进行剖析和监控，具体参见下图：
