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存儲引擎內部進行剖析和監控，具體參見下圖：
