はじめに

この記事ではオープンソースの分散データベースであるApache Cassandraのメトリクス・アラート設定について、私が携わっている環境の実例をベースに紹介します。

Apache Cassandraに限らず、データベースの運用には監視が不可欠です。
データベースのパフォーマンスや可用性を維持するためには、適切なアラート設定とメトリクスの収集が欠かせません。
特に分散システムであるCassandraでは、クラスタ全体の健全性を保つために多岐にわたる監視が求められます。

Cassandra運用で外してはいけないポイントを共有することで、読者の皆様が自身の環境で効果的な監視システムを構築し、システムの安定性とパフォーマンスを向上させるための参考になれば幸いです。

監視システムのアーキテクチャ

私が携わっている業務では、メトリクスはTelegrafを使用して収集し、内製の監視システムに格納しています。
また、Prometheusも並行して利用しており、可視化にはGrafanaを用いています。
アラートを出すのは主に内製の監視システムですが、PrometheusとAlertmanagerでも同様のことが可能ですので、個々の事情にあわせて適切な監視システムを採用すれば問題ありません。

アラートの種類

所属組織が定めるポリシーやSLAに応じて、クエリのレイテンシについても監視を検討してください。

Apache Cassandraで監視すべきアラートと、監視している背景や理由を記載します。
※記載するアラート以外にも重要なものはありますが、架電を受けるべき、緊急対応を検討すべき内容のみに絞っています。

カテゴリ	アラート項目	概要	説明
クラスタの正常性	downs	単体ノードダウン	nodetool statusからDNを取得し、1ノードがDNとなっている。復旧作業やremovenode/decommissionなどの対応が必要です。
	rack_downs	複数ラックにまたがるノードダウン	nodetool statusからDNが存在しているラック数を取得し、複数ラックでDNが存在している。 ConsistencyLevelを守れなくなる可能性が高まるため対応が必要です。
	ring_chksum	クラスタ内でring情報の一貫性が保たれているか	nodetool ringで得られるring情報に、ノード間でズレが発生している。データ不整合やデータ復活につながる可能性のある状態のため対応が必要です。
	schema_versions	クラスタ内でdescribeclusterのschema versions情報の一貫性が保たれているか	nodetool describeclusterのSchemaversionsをクラスタ内全ノードで取得し、ズレが発生している。ストリーミングの失敗などに繋がる可能性がある状態のため対応が必要です。
リソース監視	ディスク容量	ディスク容量溢れ	ディスク容量が不足する懸念がある。ワークロードにもよりますが、75%~95%程度のしきい値を設けて監視しています。
	利用可能メモリ	メモリ不足	メモリが不足する懸念がある。
	ディスクへの読み書き	物理サーバにおけるディスク故障	ディスク故障が発生している ※ディスクの冗長性の取り方次第では架電を受けたり、緊急対応は不要になる項目です。
パフォーマンス監視	ThreadPool native transport requestの平均値	リクエスト詰まりの予兆検知	リクエストが詰まりがちになり、パフォーマンスに影響が出ている可能性がある。平均値が200を超えた状態をアラートの対象としています。
	compaction pending tasks	未処理の圧縮タスク	コンパクション処理とアプリケーションのread処理で、I/Oの競合が発生している懸念がある。 ※詳細はdatastaxのドキュメントをご確認ください。
	oom-killer	OOMキラーによるプロセスの停止	OOMキラーによってCassandraプロセスが停止された ※oom_scoreの設定でOOM自体が発生しない場合は監視不要ですが、メモリ監視やパフォーマンス面での監視を強化する必要があります。
	load average 1m	load averageの高騰によるサーバ全体の異変の予兆検知 ※一部高SLA運用が必要なクラスタのみ	サーバ全体の負荷が上がっている可能性がある。 load average 1minが30を超えた状態をアラートの対象としています。

収集メトリクス

OSのメトリクス

OSからみた、システムの健全性を示すメトリクスを収集します。
CPU、メモリ、ディスク使用率、ディスクI/O使用率などです。

TelegrafやPrometheusのExporterなど、一般的な監視システムが標準で収集してくれるので、それをそのまま時系列DBに保存し、グラフで見れるようにしておけば問題ありません。

Cassandraのメトリクス

Cassandraのメトリクスは、JMXで収集するか、Datastax社が提供しているOSSであるMetric Collector for Apache Cassandra (MCAC) を利用するのが一般的なようです。
私が携わる環境では、jmx_exporterを利用して収集しています。
公式ドキュメント Monitoring章
 Metric Collector for Apache Cassandra (MCAC)

カスタムメトリクス

Cassandraの情報で監視や可視化に必要なメトリクスは、一般的な監視システムがデフォルトでは集められないものもあるため、追加で実装して集めているカスタムメトリクスについて紹介します。
主にnodetoolで取得可能な情報を整形して収集していますが、それ以外にもOSのコマンドから取得する情報や、珍しいものだとrepairの履歴なども含めて蓄積し、監視に利用しています。

カテゴリ	コマンド	説明
nodetool	nodetool status	- UNノード数 - DNノード数 - その他ステータスノード数 - ノード総数 - DNノードがあるラック数 - DNレート(DNノード数/ノード総数)
	nodetool ring	- ring情報のチェックサム
	nodetool gossipinfo	- gossip情報のチェックサム ※不要な情報、随時変わる値などの情報は省く - cassandra version
	nodetool describecluster	- schemaversions
	nodetool repair	- repair処理の履歴情報 ※keyspace、table、トークンレンジのfrom/to、repairの成功/失敗
プロセス	ps/tcp系コマンド	- cassandraプロセスの有無 - telegrafプロセスの稼働確認 - 各種Exporterの稼働確認
	chkconfig/systemctl系コマンド	- 自動起動設定
ファイル	glob系コマンド	- sstableのタイムスタンプ

まとめ

今回記載したもの以外にも、あれも見たほうが良いのではないか？このメトリクスも監視すべきか？など、監視のことを考えれば際限なくアラートの設定が可能です。
しかし過度なアラートはノイズでしかなく、ノイズが多い現場ではノイズに対して麻痺してしまい、アラートが飛んできても誰も見ない、どうせ見なくていいアラートであるとバイアスがかかってしまい、本当に見るべきアラートが見過ごされてしまいます。
これでは結局監視が出来ていないのと何も変わりません。
今回の記事が、Cassandra運用における適切なアラートの見直しや、Cassandra運用に取り組み始めた方の監視設定の足がかりになることを祈ります。