10.6.3 障害原因の調査方法
HMP-PCTOで発生する障害と、原因の調査方法について説明します。
(1) 障害発生時の流れ
ユーザは、標準出力(標準エラー出力を含む)に出力されたメッセージログのエラーメッセージ(警告メッセージを含む)、または分散トレースの出力情報によって、障害発生を検知します。
HMP-PCTOの障害発生時に、ユーザ(システム運用者)およびサポート部署が実施する障害調査の流れは次のとおりです。
-
資料取得
-
主なトラブルと調査個所
-
障害個所の特定
-
障害原因の調査
-
障害対策
次に、それぞれのフェーズでユーザ(システム運用者)およびサポート部署が実施する内容を示します。
(2) 資料取得
トラブルシュートを行うために必要な資料を収集する方法は、「10.6.2 情報の収集方法」を参照してください。
(3) 主なトラブルと調査個所
トラブル(障害)が発生するフェーズは次のとおりです。
-
環境構築時および起動時
HMP-PCTOの各コンポーネントで使用するPod・コンテナを構築し、起動した際に障害となった場合
-
システム稼働中
HMP-PCTOの各コンポーネントが稼働中に障害となった場合
障害の種類と調査個所について、次の表に示します。
項番 |
障害の種類 |
現象 |
主な原因 |
調査個所 |
---|---|---|---|---|
1 |
通信エラー |
エラーメッセージ出力 |
サービス要求や各コンポーネント間の通信に異常が起こる |
|
2 |
通信レスポンス遅延 |
応答遅延 |
サービス要求や各コンポーネント間の通信でレスポンスが遅延する |
|
3 |
連携製品のエラー |
エラーメッセージ出力 |
HMP-PCTOから連携製品(DBなど)へのアクセス時のエラー |
|
4 |
連携製品のレスポンス遅延 |
応答遅延 |
HMP-PCTOから連携製品(DBなど)へのアクセスでレスポンスが遅延する |
|
5 |
製品内部のエラー |
エラーメッセージ出力 |
HMP-PCTO各コンポーネントの内部で、製品処理に起因しない要因でエラー <例> ConsensusLogアクセス時にエラーが返る |
|
6 |
製品内部のレスポンス遅延 |
応答遅延 |
HMP-PCTO各コンポーネントの内部で、製品処理に起因しない要因でレスポンスが遅延する <例> ConsensusLog出力に時間が掛かりレスポンスが遅延する |
|
7 |
Pod障害 |
エラーメッセージ出力 |
Podが異常終了する |
|
8 |
メモリ不足 |
エラーメッセージ出力 |
HMP-PCTO各コンポーネントが使用できるメモリが不足する |
|
9 |
パラメタ設定ミス |
エラーメッセージ出力 |
パラメタに誤りがありHMP-PCTOが動作しない |
|
10 |
HTTPヘッダ設定ミス |
・HTTPステータスコード3xx/4xx/5xx |
HTTPヘッダに誤りがありサービスからエラーが返る |
|
11 |
製品不良 |
エラーメッセージ出力 |
HMP-PCTO製品に問題があり正常に動作しない <例> 通信データ不正 |
|
また、障害の種類と、ユーザの対策方法について次の表に示します。
項番 |
障害の種類 |
現象 |
主な原因 |
調査個所 |
対策 |
---|---|---|---|---|---|
1 |
HMP-PCTOのPodが終了しない |
KFSG82103-I(未決着トランザクション待機処理が完了)が出ず、Podが終了しない |
未決着トランザクションの情報が取得できない。 |
Kubernetesの詳細情報(Event情報) |
preStopフックで実行する未決着トランザクション待機スクリプトのリトライ回数、リトライ間隔の設定を見直してください。 |
(4) 障害個所の特定、原因の調査・対策
ユーザ(システム運用者)、およびサポート部署が行う、障害個所の特定、原因の調査・対策についてそれぞれ次に示します。
(a) ユーザ(システム運用者)の調査、対策
ユーザ(システム運用者)は、次のそれぞれの情報について調査、および対策を行ってください。
- 調査順序
-
ユーザは、次の順序で障害を調査します。
-
JaegerのWeb UIで、分散トレースの情報にエラー、または処理の遅延がないかどうかを確認します。エラーまたは処理の遅延があった場合、発生した個所や時刻を確認します。
-
Kibanaなどの可視化ツールで発生時間帯の標準出力を確認し、HMP-PCTOのメッセージなどエラーの情報があるかどうか確認します。
-
PrometheusのWeb UIなどの可視化ツールでメトリクスの情報を確認し、処理の遅延や、スレッドのキューへの滞留があるかどうかを確認します。
-
Podの障害、またはPodが終了しない事象があった場合は、Kubernetes上のpodの詳細情報を取得して、Podの状態やEvent情報を確認します。
-
- 調査個所、対策
-
ユーザは、それぞれ次の個所を調査し、対策を行います。
-
標準出力の情報
標準出力をKibanaなどの可視化ツールで確認してください。標準出力にHMP-PCTOが出力したエラーメッセージがあったときは、「9. メッセージ」を参照してください。メッセージに対策が記載されている場合は、それに従って対策を行ってください。
HMP-PCTOが出力したエラーメッセージに出力されたブランチXID(またはルートXID)の情報から、分散トレースや、連携製品のTomcatやDBのログのトラブルシュート情報に、同じブランチXID(またはルートXID)の情報があるかどうか、あった場合はその情報から、サービス依頼元やDBに問題がないかを合わせて確認してください。
パラメタの誤りがある場合は、修正して再度HMP-PCTOを起動してください。
-
分散トレースの情報
分散トレースをJaegerのWeb UIで確認してください。処理結果がエラーとなっている個所、または、処理が遅延している個所を確認してください。また、その処理がHMP-PCTO製品内部の処理かどうかも確認してください。
分散トレースに出力されたブランチXID(またはルートXID)の情報から、連携製品のTomcatやDBのログのトラブルシュート情報に、同じブランチXID(またはルートXID)の情報があるかどうか、あった場合はその情報から、サービス依頼元やDBに問題がないかを合わせて確認してください。
HMP-PCTO製品内部の処理でエラー、または遅延が発生している場合は、「6.5.1 取得する情報」に記載の情報を収集し、サポート部署へ調査を依頼してください。
HMP-PCTOの処理ではない場合は、連携製品でのエラー、遅延であるため連携製品のサポートに調査を依頼してください。
-
メトリクスの情報
メトリクスをPrometheusのWeb UIなどの可視化ツールで確認してください。CPU使用率・メモリ使用量などの情報から、処理が遅延している個所を確認してください。必要に応じてCPUコアやメモリの増強を行ってください。また、スレッドのキューへの滞留数を示している「executor_queued_tasks」「hmppcto_asynctask_queued_operations」が常時1以上になっている場合、同時実行可能なスレッド数を増やしてください。
-
Kubernetesの情報
Kubernetes上のpodの詳細情報を取得し、環境不正またはpodの操作ミスがないか確認してください。また、詳細情報の中のEvent情報から、ライフサイクルイベントハンドラで実行するHMP-PCTOのシェルスクリプトが出力したエラーメッセージがあったときは、「9. メッセージ」を参照してください。メッセージに対策が記載されている場合は、それに従って対策を行ってください。
-
(b) サポート部署の調査、対策
ユーザから調査依頼を受け、ユーザから資料を入手したサポート部署が調査する内容は次のとおりです。
-
標準出力の情報をエクスポートしたファイル
HMP-PCTOのエラーメッセージ、またはスタックトレースが出力されていないか確認します。
また、次に示す、そのほかの連携製品から出力された標準出力の情報からエラーメッセージが出力されていないか確認します。
-
HMP-ADIF
-
Spring
-
Java VM
-
TP1/Client/J
-
SQL Server
-
HiRDB
-
Kubernetesの情報
サポート部署は、ユーザにpodの情報収集した出力結果ファイルを依頼し、その結果から状態を確認します。
-
-
分散トレース情報をエクスポートしたファイル
サービス呼び出し関連が知りたい場合や、遅延が発生していて遅延個所を特定したい場合は、分散トレースを確認します。分散トレースでは、トランザクション内の次の実行時間を確認できます。
-
トランザクション(ルートXIDの割り当て〜合意)
-
サービス(Orchestrator/Entity-ServiceまたはOrchestrator/Entity-Module)の実行時間
-
DBアクセス時間
-
EADS APIアクセス時間(トライアル版では取得できません)
-
ConsensusLogアクセス時間
-
REST API通信時間
-
gRPC通信時間
-
連携製品側のトラブルシュートが必要になった場合、関連部署へ調査依頼を行います。
-
HMP-ADIF
-
EADS(トライアル版では不要です)
-
uCosminexus Application Runtime with Java for Spring Boot
-
TP1/Client/J
-
uCosminexus Service Platform
-
OpenTP1
-
HiRDB
OSSでのトラブルシュートが必要になった場合、関連部署(OSSサポートチーム)へ調査依頼を行います。
-
Spring
-
PostgreSQL
-
SQL Server
- 通信データの確認
-
製品不良による電文設定ミス、ユーザのHTTPヘッダミス(SQL-Participantを使用する場合の先行プリペア設定もれなど)のおそれがある場合は、次の情報を確認します。
-
Tomcatアクセスログ
ヘッダ情報から、REST API通信の内容を確認します。
-
分散トレース
gRPC通信の内容を確認します。
-
- 連携製品の調査
-
DB障害やEADS障害などの連携製品については、連携製品側のトラブルシュート情報を取得し、連携製品のサポート部署に調査を依頼します。
-
HiRDBのトレース・ログ情報
-
EADSのトラブルシュートファイル(トライアル版では取得できません)
-
uCosminexus Service Platformのトレース・ログ情報
-
OpenTP1のトレース・ログ情報
-
TP1/Client/Jのトレース情報
次の情報を、連携製品調査の補助資料として必要に応じて連携製品側へ情報を提供します。
-
分散トレース
次の項目を確認します。
・XA関数実行時の順序、内容、実行結果を確認します。
・EADS API実行時の順序、内容、実行結果を確認します。なお、トライアル版では確認不要です。
-
標準出力
エラーメッセージ、またはスタックトレースが出力されているかどうかを確認します。
-
- 統計情報確認
-
通信遅延、プロセススローダウンなどの遅延が発生した場合、ブランチXIDの情報だけでは原因の特定(例えば、通信量やディスクIOが競合したなど)が難しいため、次の情報から、遅延発生時間帯やその時間帯に動いていたブランチXIDを特定します。
-
メトリクス
gRPC通信量、GC回数、CPU情報を取得します。
-
分散トレース
通信やファイルアクセスで遅延が発生し始めた時間を特定します。
-