2015年4月9日木曜日

cassandraの監視・統計のモニタリングポイント


cassandraを運用する際の正常性の判定方法と
障害の未然予防のためにどこをどうモニタリングすべきかをまとめる.


(その他 関連記事)
cassandra リングから外れたノードの再追加方法
cassandraの運用時に必要な定期バッチ処理の考察



【cassandraプロセスの生存確認】
(目的)
cassandraプロセスが稼働していることを確認する.

(確認方法)
$ ps -ef |  grep -v grep | grep cassandraのプロセス名

cassandraはjavaで動いているためjpsコマンドから確認してもよい.
$ jps | grep cassandraのプロセス名



【cassandraのスレッド数】
(目的)
設定値、また性能試験の最繁時負荷の値を上限として、それより余裕があることを確認する.

(確認方法)
$ ps auxww -L | grep -v grep | cassandraのプロセス名 | wc -l



【cassandraプロセスのステータス】
(目的)
StatusがUpであること確認する.

(確認方法)
$ nodetool -h `hostname` -p ${CASSANDRA_PORT} ring

Address     DC          Rack        Status State   Load            Owns    Token
192.0.2.1   DC1         RAC1        Up     Normal  37.85 GB        20.00%  0
192.0.2.2   DC1         RAC1        Up     Normal  34.54 GB        20.00%  34028236692093846346337460743176821145
192.0.2.3   DC1         RAC1        Up     Normal  36.02 GB        20.00%  68056473384187692692674921486353642291
192.0.2.4   DC1         RAC1        Up     Normal  38.31 GB        20.00%  102084710076281539039012382229530463436
192.0.2.5   DC1         RAC1        Up     Normal  36.30 GB        20.00%  136112946768375385385349842972707284582



【SSTableのサイズ】
(目的)
SSTableのサイズが設定値以下になっていることを確認する.
※LeveledCompactionを採用している場合は不要である.

(確認方法)
先のコマンドの出力結果からLoad値を読み取る.

リングノード全体の情報ではなく、個別にノード単位で確認する場合は、
オプションをinfoにすればよい.
この場合、全体のLoad数と共に、利用しているHeapメモリのサイズも確認できる.

$ nodetool -h `hostname` -p ${CASSANDRA_PORT} info

Token            : 0
Gossip active    : true
Thrift active    : true
Load             : 37.85 GB
Generation No    : 1427344416
Uptime (seconds) : 1177677
Heap Memory (MB) : 5694.93 / 16144.00
Data Center      : DC1
Rack             : RAC1
Exceptions       : 0



【cassandara内の各種タスクの遅延発生状況の確認】
(目的)
Pending数が性能試験の最繁時負荷の値を上限として、それ以下であることを確認する.
また、Droppedは発生していないことを確認する.
項目の意味は公式ドキュメントを参照のこと.

(確認方法)
$ nodetool -h `hostname` -p ${CASSANDRA_PORT} tpstats

Pool Name                    Active   Pending      Completed   Blocked  All time blocked
ReadStage                         1         1      834509952         0                 0
RequestResponseStage              0         0     1320083824         0                 0
MutationStage                     0         0      617086394         0                 0
ReadRepairStage                   0         0      167166109         0                 0
ReplicateOnWriteStage             0         0              0         0                 0
GossipStage                       0         0        5059485         0                 0
AntiEntropyStage                  0         0              0         0                 0
MigrationStage                    0         0              0         0                 0
MemtablePostFlusher               0         0           1914         0                 0
StreamStage                       0         0              0         0                 0
FlushWriter                       0         0           1914         0                 0
MiscStage                         0         0              0         0                 0
InternalResponseStage             0         0              0         0                 0
HintedHandoff                     0         0             14         0                 0

Message type           Dropped
RANGE_SLICE                  0
READ_REPAIR                  0
BINARY                       0
READ                         0
MUTATION                     0
REQUEST_RESPONSE             0



【コンパクションの遅延発生状況の確認】
(目的)
コンパクション処理時の遅延状況を確認する.

(確認方法)
nodetoolのtpstatsオプションでは目的に叶うものが表示されないため、
オプションでを変えて確認する必要がある.
$ nodetool -h `hostname` -p ${CASSANDRA_PORT} compactionstats

pending tasks: 0



【SSTable数(Leveled Compactionの各世代ごと)の確認】
(目的)
各世代のSSTableが設計通りに分散されていることを確認する.

(確認方法)
jsonファイル内のメンバの数から確かめられる.

jsonファイルはこのようになっている.
例えば下だと、世代1で10件のSSTableが存在していることが分かる.
   ~snip~
   "generation" : 1,
    "members" : [ 964339, 964340, 964341, 964342, 964343, 964344, 964345, 964346, 964347, 964348 ]
   ~snip~

$ find /cassandra/data/Keyspace1/ -name "CF_Folder.json" \
| xargs awk '\
BEGIN{genNum=0; total=0} \
{if($1~/members/)\
    {print "generation_"genNum": "NF-4; genNum++; total=total+NF-4} \
} \
END{print "total: "total;print "file: "FILENAME}'

generation_0: 0
generation_1: 10
generation_2: 107
generation_3: 546
generation_4: 0
generation_5: 0
generation_6: 0
total: 663
file: /cassandra/data/Keyspace1/CF_Folder.json



【カラムファミリ(CF:Column Family)ごとのSStable数】
(目的)
カラムファミリごとのSSTableを構成する3つのファイル数を確認する.

3つのファイルとは下の通りである.
Data files  : An SSTable  and is a file of key-value string pairs (sorted by keys).
Index file  : Key, offset pairs (points into data file)
Bloom filter: all keys in data file

Dataファイル数を見ておけばいいだろうか.

(確認方法)
Dataファイルは例えばこのように作成されている.
/cassandra/data/Keyspace1/CF_Folder-10-Data.db
/cassandra/data/Keyspace1/CF_Folder-11-Data.db
/cassandra/data/Keyspace1/CF_Folder-12-Data.db
/cassandra/data/Keyspace1/CF_Message-10-Data.db
/cassandra/data/Keyspace1/CF_Message-11-Data.db
/cassandra/data/Keyspace1/CF_Message-12-Data.db

ls -lの出力(1項目1行で出す)の9行目に、ファイル名が表示される.
その先頭位置から、ハイフン"-"の前までの位置でファイルを切り取り集計する.
$ ls -l /cassandra/data/Keyspace1/CF_*Data.db \
| awk '{print substr($9, 1, index($9, "-")-1)}'\
| sort \
| uniq -c \
| egrep 'CF_Folder|CF_Message'

573 /cassandra/data/Keyspace1/CF_Folder
357 /cassandra/data/Keyspace1/CF_Message



【Cassandraが利用するディスク容量】
(目的)
Compactionやデータ修復の際にテンポラリファイルを考慮して、
ディスク使用率に50%以上の余裕があることを確実にしておく.

(確認方法)
$ df 

/dev/sdb1 2884162784  58988308 2678667368 3% /cassandara/data/



【JavaのGCの動作のモニタリング】
JavaのGCについて別にまとめている.
Java GC の動作まとめ(その内の◆ 統計項目を参照のこと).



【その他】
一般的なサーバのリソースはこのあたりを見ておけばいい.
サーバリソース最速確認ポイント

cassandraを利用したアプリ部分は当然それ依存になるので省略する.