問題のあるノードを見つける
Cassandra の問題をトラブルシューティングする最初のステップは、エラーメッセージ、メトリクス、および監視情報を使用して、問題がクライアントにあるのかサーバーにあるのかを特定し、サーバーにある場合は Cassandra クラスタ内の問題のあるノードを見つけることです。目標は、これがシステム全体の問題（例：クラスタ全体に影響を与えるクエリパターン）なのか、ノードのサブセットに限定された問題（例：共有トークン範囲を保持する隣接ノード、またはハードウェアに問題のある単一ノード）なのかを判断することです。
問題の所在を特定するのに役立つ情報源はたくさんあります。最も一般的なもののいくつかを以下に示します。
クライアントログとエラー
クラスタのクライアントは、多くの場合、追跡するための最良の手がかりを残します。クライアントのレイテンシまたはエラー率が特定のデータセンターで増加している（他のデータセンターのノードを除外できる可能性が高い）か、クライアントが特定の種類の問題を示す特定の種類のエラーコードを受信している可能性があります。トラブルシューターは、多くの場合、エラーメッセージを読むだけで多くの障害モードを除外できます。実際、多くの Cassandra エラーメッセージには、オペレーターが開始ノードを見つけるのに役立つ、最後に連絡したコーディネーターが含まれています。
Datastax ドライバー <client-drivers> と同様のエラー名を持つクライアントを想定した、いくつかの一般的なエラー（括弧内は可能性の高い原因）
-
SyntaxError(**クライアント**)。これと他のQueryValidationExceptionは、クライアントが不正な形式のリクエストを送信したことを示します。これらはサーバーの問題であることはまれで、通常は不正なクエリを示します。 -
UnavailableException(**サーバー**): これは、Cassandra コーディネーターノードが、使用可能なレプリカノードが不十分であると判断してクエリを拒否したことを意味します。多くのコーディネーターがこのエラーをスローしている場合、クラスタ内に（通常は）複数のノードがダウンしていることを意味し、nodetool status <nodetool-status>を使用してそれらを特定できます。単一のコーディネーターのみがこのエラーをスローしている場合、そのノードが他のノードからパーティション分割されている可能性があります。 -
OperationTimedOutException(**サーバー**): これは、クライアントがタイムアウトを設定し、クエリが指定されたタイムアウトよりも長くかかった場合に発生する最も一般的なタイムアウトメッセージです。これは*クライアント側*のタイムアウトであり、クライアントが指定したタイムアウトよりも長くかかったことを意味します。エラーメッセージには、最後に試行されたコーディネーターノードが含まれており、これは通常、良い出発点となります。このエラーは通常、積極的なクライアントタイムアウト値、または潜在的なサーバーコーディネーター/レプリカを示します。 -
ReadTimeoutExceptionまたはWriteTimeoutException(**サーバー**): これらは、クライアントがより低いタイムアウトを指定せず、cassandra.yaml設定ファイルで指定された値に基づいて*コーディネーター*タイムアウトが発生した場合に発生します。デフォルト値は通常数秒であるため、通常は重大なサーバー側の問題を示します。
メトリクス
Cassandra メトリクス が Graphite や Grafana などの集中管理場所にレポートしている場合は、通常、それらを使用して問題を絞り込むことができます。この段階での主な目標は、問題を特定のデータセンター、ラック、またはノードのグループにまで絞り込むことです。確認するのに役立つメトリクスを以下に示します
エラー
Cassandra はノード間メッセージングエラーを「ドロップ」と呼んでおり、エラーを絞り込むのに役立つ多数の ドロップメッセージメトリクス を提供しています。特定のノードがメッセージをアクティブにドロップしている場合、それらは問題に関連している可能性があります。
レイテンシ
タイムアウトまたはレイテンシ関連の問題については、operating/metrics.adoc#table-metrics[テーブルメトリクス] から始めることができます。たとえば、CoordinatorReadLatency や CoordinatorWriteLatency などのコーディネーターレベルのメトリクスを、ReadLatency や WriteLatency などの関連するレプリカメトリクスと比較します。問題は通常、50パーセンタイル または 平均 に現れる前に 99パーセンタイル に現れます。メトリクスを生成するために内部で使用される指数関数的に減衰するリザーバーのため、最大 コーディネーターレイテンシは通常あまり役に立ちませんが、コーディネーターの 99パーセンタイル の増加と相関する 最大 レプリカレイテンシは、問題を絞り込むのに役立ちます。
通常、3つの主要な可能性があります
-
コーディネーターレイテンシはすべてのノードで高いが、少数のノードのローカルリードレイテンシのみが高い。これは、低速なレプリカノードを示しており、コーディネーターは単なる副作用です。これは通常、クライアントがトークンを認識していない場合に発生します。
-
コーディネーターレイテンシとレプリカレイテンシが少数のノードで同時に増加する。クライアントがトークンを認識している場合、これはほとんどの場合発生し、トークン範囲のサブセット（リングの一部のみ）の低速なレプリカを示します。
-
コーディネーターとローカルのレイテンシが多くのノードで高い。これは通常、クラスタ容量の限界点（1秒あたりの書き込みまたは読み取りが多すぎる）、または新しいクエリパターンを示します。
クライアントの負荷分散動作と整合性レベルによっては、コーディネーターとレプリカメトリクスが相関しない場合があることに注意することが重要です。特に、TokenAware ポリシーを使用する場合、同じノードのコーディネーターとレプリカのレイテンシはしばしば一緒に増加しますが、通常の DCAwareRoundRobin を使用する場合、コーディネーターのレイテンシは関連のないレプリカノードのレイテンシとともに増加する可能性があります。例えば
-
TokenAware+LOCAL_ONE: 同じノードのコーディネーターとレプリカのレイテンシは常に一緒に上昇するはずです -
TokenAware+LOCAL_QUORUM: 同じデータセンター内のコーディネーターと複数のレプリカのレイテンシは常に一緒に上昇するはずです。 -
TokenAware+QUORUM: 他のデータセンターのレプリカレイテンシは、コーディネーターレイテンシに影響を与える可能性があります。 -
DCAwareRoundRobin+LOCAL_ONE: コーディネーターレイテンシと関連のないレプリカノードのレイテンシは一緒に上昇します。 -
DCAwareRoundRobin+LOCAL_QUORUM: 異なるコーディネーターとレプリカのレイテンシは、ほとんど相関なく一緒に上昇します。
クエリレート
時に、テーブルメトリックのクエリレートメトリックは、ロード問題の絞り込みに役立ちます。コーディネーターのクエリ/秒（QPS）の「わずかな」増加が、レプリカレベルのQPSの大幅な増加と相関している可能性があるためです。これは、クライアントが50個のステートメントを含む単一のBATCHクエリを送信する可能性のあるBATCH書き込みで最も頻繁に発生します。9つのコピー（RF = 3、3つのデータセンター）がある場合、すべてのコーディネーターBATCH書き込みは450のレプリカ書き込みになります！これが、`BATCH`を同じパーティションに保持することが非常に重要である理由です。そうでない場合、「単一」のクエリでCPU容量を大幅に使い果たしてしまう可能性があります。
