OceanBaseデータベースのモニタリングは現在、主にOCPのモニタリング機能に依存しています。データベースクラスタ、テナント、ノードの各レベルで、パフォーマンス、容量、稼働状態などの指標を7×24時間モニタリングし、グラフィカルに可視化します。これにより、ユーザーはOceanBaseクラスタの使用状況を包括的に把握し、クラスタの異常を迅速に検出し、イベントが発生した際には即座に警告を発信することで、データベースの安定かつ効率的な正常運用を確保できます。
モニタリング
OceanBaseデータベースのモニタリングは、処理の流れに基づいて、以下の部分で構成されています：
Metricチェーン（一般的なモニタリング指標）：OBServerノードの状態監視、obproxyの状態監視、ホスト指標の監視。
OB SQLチェーン：OceanBaseデータベース関連のSQL、Plan指標を含みます。
OBリソース使用状況チェーン：OceanBaseクラスタ、テナントのリソース使用状況を収集します。
Metricチェーン
このチェーンは、以下の指標を収集します：
ホスト指標：ホストおよびホスト上にデプロイされた関連サービス（例：OBServerノード、obproxy）のCPU、ディスク、I/O、LOADなどの情報を含みます。
obproxy指標：obproxyの関連するリクエスト、セッション、トランザクションなどの情報。
OB秒（分）単位の指標：OBノードのリソース状態、QTPSなどのパフォーマンス監視情報に対応します。
Metricチェーンは、OCPで管理されるホスト上にデプロイされたOCP Agentのocp_exporterプログラムに依存して収集を行います。ocp_exporterは外部にRESTfulサービスを提供し、モニタリングデータの収集を行います。このインターフェースはPrometheus仕様のモニタリング指標を提供し、内部ではNodeExporter（ホスト監視）、OBProxyExporter（obproxy監視）、OBCollector（OceanBase監視）に依存して多様な指標を収集します。OCPは指定されたタイプのモニタリング指標を収集した後、それらを集計・変換してモニタリングデータベース（MonitorDB）に保存します。モニタリング計算エンジンは、モニタリング式（Prometheusベースの式）に基づいてモニタリングデータベースからモニタリングデータを照会し、計算を行った後、クライアントに返します。クライアントは返された計算済み情報に基づいてモニタリンググラフを表示します。
OB SQLチェーン
このチェーンは、各OceanBaseクラスタのSQLデータとSQL実行計画データを収集するために使用されます。主に以下のビューからデータを収集します：
v$sql_audit：SQLの実行監査情報を記録します。
v$plan_cache_plan_explain：実行計画の各演算子の情報を記録します。
v$plan_cache_plan_stat：実行計画の監査情報を記録します。
SQLデータとSQL実行計画のデータ量は比較的大きいため、パフォーマンスを向上させ、リソース消費を削減するために、このチェーンの収集プログラムであるobstat2は、C++で開発された高性能で軽量なプログラムです。収集頻度の設定に基づき、収集サイクル内にビューからSQLと実行計画の情報を収集し、ローカルで集計計算を行った後、OCPのモニタリングデータベース（MonitorDB）に保存します。OCPのバックグラウンドタスクは定期的にモニタリングデータベースにアクセスし、最小粒度のSQL auditおよびSQL planデータを大きな時間粒度の結果に集計し、保存します。Webページからクエリを実行する場合、選択した時間区間が短い場合は元のレポートテーブルを直接クエリし、時間粒度が大きい場合は集計テーブルをクエリします。
OBリソース使用状況の連携
この連携は、OceanBaseクラスタのリソース使用状況を収集する役割を担っており、主に以下のデータソースからデータを収集します：
CPU情報：
- GV$OB_SERVERS：CPUの総コア数、割り当て済みコア数。
メモリ情報
- GV$OB_SERVERS：メモリの総サイズ、使用済みサイズ。
ディスク情報
- GV$OB_SERVERS：ディスクの総サイズ、使用済み情報。
システムイベント情報
- oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY：OceanBaseクラスタのシステムイベント情報。
OBリソース使用状況の連携は、OCPの定期タスクによってトリガーされ、各クラスタのsysテナントがクラスタ、テナント、データベース、テーブルなどの観点からOBServerノード上のCPU、Memory、Diskなどの利用率を収集し、データを監視データベースに保存します。クライアントからクエリリクエストが送信されると、クエリエンジンはクラスタ、テナント、データベース、テーブルなどの観点から統計を行い、統計後のデータをフロントエンドに返して表示します。
アラート
OceanBaseデータベースは主にOCPアラートを通じて、本番環境のホストやデータベースのリスク、障害に対する予警を実現しています。データベースやそのホスト環境で障害が発生しそうになったり、実際に障害が発生した場合、組み込みのアラート項目が異常を検出し、アラートチャネルを通じてアラートをアラート購読者に送信します。ここでは、アラート機能について、アラート項目の設定、アラート検出、アラート集約、アラート購読の4つの側面から紹介します。
アラート項目
OCPには約60個の組み込みアラート項目があります。各アラート項目は、アラート名、レベル、概要テンプレート、詳細テンプレートなどの基本情報と、アラート検出に関連するルール情報を記述しています。
アラートのリスク度に応じて、5つのアラートレベルが定義されています：停止、重大、警告、注意、リマインダー。アラートが発生すると、関連するテンプレート変数が生成され、これらの変数は概要テンプレートや詳細テンプレートに設定することで、必要なコンテキスト情報を表示できます。アラート検出ルールは、監視式に基づく検出ルールであり、検出期間、検出サイクル、アラート回復サイクル、検出式の設定などが含まれます。
これらの組み込みアラート項目は、大まかにデータベースリソース、データベースイベント、ホストリソース、OCPイベントなどの観点からアラートを記述しています。例えば、データベースCPU、メモリ、MemStore、ディスク使用率などのデータベースリソースアラート、メジャーコンパクションタイムアウト、ハングトランザクションなどのデータベースイベントアラート、ホストのネットワークやディスクアラート、さらにOCPの監視APIステータス異常、metadbのOBクラスタ同期などのアラートが該当します。
アラート検出
アラート検出とは、組み込みのアラート項目を検出してアラートをトリガーするプロセスであり、監視式に基づく検出と定期タスクのロジック検出の2種類があります。アラート検出後、アラートイベントが生成され、アラートが発生したことになります。ただし、このアラートイベントをユーザーに通知する必要があるかどうかは、その後のアラート集約ロジックに依存します。大量のアラートメッセージが発生するのを避けるため、アラートを抑制する操作が必要になる場合があります。
監視式に基づくアラートでは、監視APIを通じて異なる観点から監視データを集約し、APIのクエリ結果と閾値を照合します。アラートトリガールールを満たすとアラートイベントが生成されます。
上図は、監視式に基づくアラート検出における状態遷移です。durationはアラートの検出期間を指し、durationの時間内に連続してアラートがトリガーされると、アラートイベントが生成されます。durationは異常状態のフォールトトレランスシナリオでよく使用されます。偶発的な1回の異常は即座にアラートをトリガーする必要はなく、継続的な異常がある場合にのみアラートをトリガーします。
定期タスクのロジック検出は、いくつかの複雑なシナリオに対応し、スクリプト言語を使用して検出する必要があります。この種の検出方法は、アラートAPIを直接呼び出してアラートイベントを生成するもので、OceanBaseログアラートやOMSアラートなどが該当します。外部システム（OCP以外のシステム）のイベントベースアラートに適しています。
アラート集約
集約アラートとは、アラートメッセージを事前設定されたルールに基づいて少数のアラートメッセージ（集約メッセージと呼ばれる）に統合し、アラートストームを防止することです。
以下はアラートの集約設定例です。これは深優先マッチングルールであり、例えばOceanBaseログアラート（ob_log_alarm）の集約次元はalarm_type（アラート項目）+ob_error_code（ログエラーコード）+obregion（OceanBaseクラスタ名）です。
aggregate:
# root層はデフォルトで集約され、アラートタイプとオブジェクトに基づいて集約されます。
match: {}
group_by:
- "alarm_type"
aggregate_wait_seconds: 10
aggregate_interval_seconds: 60
repeat_interval_seconds: 3600
aggregates:
# OBアラートについては、アラートタイプとOBクラスタに基づいて集約されます。
- match:
app: "OB"
group_by:
- "alarm_type"
- "obregion"
aggregate_wait_seconds: 10
aggregate_interval_seconds: 60
repeat_interval_seconds: 3600
aggregates:
# OBログアラートについては、アラートタイプ、ログエラーコード、OBクラスタに基づいて集約されます。
- match:
alarm_type: "ob_log_alarm"
group_by:
- "alarm_type"
- "ob_error_code"
- "obregion"
aggregate_wait_seconds: 10
aggregate_interval_seconds: 60
repeat_interval_seconds: 3600
aggregate_wait_secondsは初回アラート発生時の待機時間であり、この時間内に同じ集約次元で発生したアラートは1つのアラートメッセージに集約されます。
aggregate_interval_secondsは同じ集約次元の集約間隔であり、新しい集約アラートメッセージが生成されるまでの時間です。
repeat_interval_secondsは同一アラート（同一アラートID、アラートが解消されない限りIDは増加しない）の送信間隔であり、同一アラートが次のrepeat_interval_secondsサイクルで再び集約されます。
アラートサブスクリプション
アラートサブスクリプション機能は、アラートメッセージを異なるユーザーに送信するのを容易にするためのものです。
まず、アラート項目はさまざまなグループに分類されます。サブスクライブする際には、そのアラートグループを直接選択できます。現在、OCPでは以下の6つのアラートグループが定義されています：
ocp：OCP関連のアラート項目。
dba：OceanBaseデータベース関連のアラート項目。
info：操作系（Infoレベル）のアラート項目。
oms：OMSアプリケーションのアラート項目。
backup：バックアップ・リストアのアラート項目。
dev：運用保守関連のアラート項目。
クラスタやレベルごとにアラートをサブスクライブし、異なるアラートを異なるアラートチャネルに送信することができます。アラートチャネルはアラートの送信方法を定義しており、現在はbash/pythonスクリプトによる送信やHTTP APIによる送信をサポートしています。また、チャネルにレート制限ポリシーを設定することで、過剰なアラート送信を防ぐことも可能です。