9.5.4　障害原因の調査方法

HMP-PCTOで発生する障害と、原因の調査方法について説明します。

〈この項の構成〉

(1)　事前準備
(2)　監視の設定
(3)　障害発生時の流れ
(4)　資料取得
(5)　主なトラブルと調査個所
(6)　障害個所の特定、原因の調査・対策

(1)　事前準備

HMP-PCTOの構築時に、トラブルシュート機能で必要な情報を取得するために、次の準備を行います。

Tomcatのアクセスログの取得方法
- ログ取得を有効にする方法
  
  OrchestratorおよびParticipantのSpring Bootのコンフィグソースにserver.tomcat.accesslog.enable=trueを設定するように定義してください。詳細については、「3.4　Kubernetesマニフェスト作成」を参照してください。
  
  「2.5.2　OrchestratorのKubernetesマニフェストの作成」、「2.5.5　SQL-ParticipantのKubernetesマニフェストの作成（SQL-Participant限定）」、「2.5.4　TCC-ParticipantのKubernetesマニフェストの作成（TCC-Participant限定）」時にFilebeatコンテナのfilebeat.ymlに次を設定してください。なお、output.logstashフィールドのNamespace名にはLogstashアプリケーションをデプロイするNamespaceを指定します。
```
filebeat.inputs:
- type: filestream
  id: "tomcat"
  paths:
    - '<Tomcatのアクセスログのパス>'
 
output.logstash:
  hosts: ["logstash.my-namespace.svc.cluster.local:5044"]
```
- ヘッダ情報を取得する方法
  
  server.tomcat.accesslog.enabled=trueを設定したSpring Bootのコンフィグソースに「server.tomcat.accesslog.pattern」の指定値として、「"%{X-transparent}i"」を含めるように定義してください。設定例は次のとおりです。
```
server.tomcat.accesslog.enabled=true
server.tomcat.accesslog.pattern=%h %{X-Forwarded-For}i %u %{dd/MMM/yyyy:HH:mm:ss.SSS Z}t "%r" %s %b %D %{ucar.rootap}r "%{Referer}i" "%{User-Agent}i" "%{X-transparent}i"
```
DBのログの取得方法（SQL-Participantを使用する場合）

DBのKubernetesマニフェスト作成時にFilebeatをサイドカーコンテナとして立ち上げるようにしてください。

Filebeatコンテナのfilebeat.ymlに次を設定してください。なお、output.logstashフィールドのNamespace名にはLogstashアプリケーションをデプロイするNamespaceを指定します。

注：DBのログが1回の出力で複数行を出力する場合、Filebeatの公式のマニュアルを参考にMultiline messagesの設定をfilebeat.ymlに対して行い、1つの行として処理される設定にしてください。
```
filebeat.inputs:
- type: filestream
  id: "postgre"
  paths:
    - '<DBログのパス>'
 
output.logstash:
  hosts: ["logstash.my-namespace.svc.cluster.local:5044"]
```
EADSのトラブルシュート情報の取得方法

トライアル版では取得できません。

EADSのトラブルシュート情報の取得方法については、EADSのマニュアルをご覧ください。

ページの先頭へ

(2)　監視の設定

EADSサーバのログ監視のための設定

EADSサーバのログ監視を行う場合、そのログをElasticsearchに格納するためにEADSサーバのログを標準出力に出力するよう設定する必要があります。そのためEADSのセットアップ時に使用するHelmチャートのvalues.yamlのproperties.serverにeads.logger.message.console.enable=trueを追加してください。
```
properties:
  server:
  - eads.logger.message.console.enable=true
```
その後、後述する「Elasticsearchに格納された標準出力を監視するための設定」を実施してください。

この手順でElasticsearchに格納されるEADSサーバのログは監視目的のため、サポート部署に調査を依頼する際にはEADSのトラブルシュートファイルを送付してください。
Elasticsearchに格納された標準出力を監視するための設定

Elasticsearchに格納された標準出力の情報を監視する場合、次の方法があります。
- KibanaのAlert機能を使用する
  
  ElasticStackのKibanaにあるAlert機能で、標準出力の監視を行います。
- Watcherを使用する
  
  ElasticStackの有償の監視機能であるWatcherで、標準出力の監視を行います。
- ElastAlert（またはElastAlert2）を使用する
  
  OSSのElastAlertで、標準出力の監視を行います。

例として、KibanaのAleart機能の設定方法を示します。

【Aleart機能の前提条件】

KibanaとElasticsearchで通信が暗号化されていること
Kibanaの設定でxpack.encryptedSavedObjects.encryptionKeyが設定されていること

【Aleart機能の設定方法】

Kibanaの左上の三本線をクリックし、出たメニューからObservability → Logs → Streamを選択し、Settingsをクリックする
Settingsの画面でLog indicesに、index名として「logstash*」をコンマ区切りで追加する（そのほかはデフォルトのままでよい）
Logs → Streamの画面からAlerts → Create Alert を選択する

【注意】Elasticsearchとの通信が暗号化されていない場合、画面に「Additional setup required」と出て、これ以降の設定ができません。
Create rule画面で、Nameに任意の名前を入力し、Log thresholdを選択する。その後、監視するフィールドと監視したい文字列、回数を入力する（下図の赤い枠の個所）

例として、KFSGの-Eメッセージが1つ以上出力された場合に、アラートを上げる例を次の図に示します。
ActionのSelect a connector typeで通知先への通知の定義を行う

例としてIndexを選択した場合、Run whenに「Fired」を、Index connectorではconnector（通知先）を指定します。Connectorの定義ではWrite to indexに通知先のindex名を指定します。Document to indexに、通知したい内容をJSON形式で記載します。

最後にSaveを押して保存します。

ページの先頭へ

(3)　障害発生時の流れ

ユーザは、標準出力（標準エラー出力を含む）に出力されたメッセージログのエラーメッセージ（警告メッセージを含む）、または分散トレースの出力情報によって、障害発生を検知します。

HMP-PCTOの障害発生時に、ユーザ（システム運用者）およびサポート部署が実施する障害調査の流れは次のとおりです。

資料取得
主なトラブルと調査個所
障害個所の特定
障害原因の調査
障害対策

次に、それぞれのフェーズでユーザ（システム運用者）およびサポート部署が実施する内容を示します。次に示す図はSQL-Participantを使用する場合です。TCC-Participantを使用する場合、Entity-ServiceをEntity-Moduleと読み替えてください。

図9‒24　HMP-PCTO 障害発生時の流れ（SQL-Participantを使用する場合）

図9‒25　 HMP-PCTO 障害発生時の流れ（TCC-Participantを使用する場合）

ページの先頭へ

(4)　資料取得

トラブルシュートを行うために必要な資料を収集する方法は、「9.5.2　情報の収集方法」を参照してください。

ページの先頭へ

(5)　主なトラブルと調査個所

トラブル（障害）が発生するフェーズは次のとおりです。

環境構築時および起動時

HMP-PCTOの各コンポーネントで使用するPod・コンテナを構築し、起動した際に障害となった場合
システム稼働中

HMP-PCTOの各コンポーネントが稼働中に障害となった場合

障害の種類と調査個所について、次の表に示します。

表9‒50　障害の種類と調査個所
項番	障害の種類	現象	主な原因	調査個所
1	通信エラー	エラーメッセージ出力	サービス要求や各コンポーネント間の通信に異常が起こる	標準出力をKibanaなどの可視化ツールで確認分散トレースをJaeger UIで確認
2	通信レスポンス遅延	応答遅延	サービス要求や各コンポーネント間の通信でレスポンスが遅延する	分散トレースをJaeger UIで確認メトリクスをPrometheus UIなどの可視化ツールで確認
3	連携製品のエラー	エラーメッセージ出力	HMP-PCTOから連携製品（DBなど）へのアクセス時のエラー	標準出力をKibanaなどの可視化ツールで確認分散トレースをJaeger UIで確認
4	連携製品のレスポンス遅延	応答遅延	HMP-PCTOから連携製品（DBなど）へのアクセスでレスポンスが遅延する	分散トレースメトリクスをPrometheus UIなどの可視化ツールで確認
5	製品内部のエラー	エラーメッセージ出力	HMP-PCTO各コンポーネントの内部で、製品処理に起因しない要因でエラー＜例＞ ConsensusLogアクセス時にエラーが返る	標準出力をKibanaなどの可視化ツールで確認分散トレースをJaeger UIで確認
6	製品内部のレスポンス遅延	応答遅延	HMP-PCTO各コンポーネントの内部で、製品処理に起因しない要因でレスポンスが遅延する＜例＞ ConsensusLog出力に時間が掛かりレスポンスが遅延する	分散トレースをJaeger UIで確認メトリクスをPrometheus UIなどの可視化ツールで確認
7	Pod障害	エラーメッセージ出力	Podが異常終了する	標準出力をKibanaなどの可視化ツールで確認 Kubernetesの詳細情報
8	メモリ不足	エラーメッセージ出力	HMP-PCTO各コンポーネントが使用できるメモリが不足する	標準出力をKibanaなどの可視化ツールで確認メトリクスをPrometheus UIなどの可視化ツールで確認
9	パラメタ設定ミス	エラーメッセージ出力	パラメタに誤りがありHMP-PCTOが動作しない	標準出力をKibanaなどの可視化ツールで確認
10	HTTPヘッダ設定ミス	・HTTPステータスコード3xx/4xx/5xx	HTTPヘッダに誤りがありサービスからエラーが返る	標準出力をKibanaなどの可視化ツールで確認分散トレースをJaeger UIで確認
11	製品不良	エラーメッセージ出力	HMP-PCTO製品に問題があり正常に動作しない＜例＞通信データ不正	標準出力をKibanaなどの可視化ツールで確認分散トレースをJaeger UIで確認

また、障害の種類と、ユーザの対策方法について次の表に示します。

表9‒51　障害の種類と対策
項番	障害の種類	現象	主な原因	調査個所	対策
1	HMP-PCTOのPodが終了しない	KFSG82103-I（未決着トランザクション待機処理が完了）が出ず、Podが終了しない	未決着トランザクションの情報が取得できない。	Kubernetesの詳細情報（Event情報）	preStopフックで実行する未決着トランザクション待機スクリプトのリトライ回数、リトライ間隔の設定を見直してください。

ページの先頭へ

(6)　障害個所の特定、原因の調査・対策

ユーザ（システム運用者）、およびサポート部署が行う、障害個所の特定、原因の調査・対策についてそれぞれ次に示します。

(a)　ユーザ（システム運用者）の調査、対策

ユーザ（システム運用者）は、次のそれぞれの情報について調査、および対策を行ってください。

調査順序

ユーザは、次の順序で障害を調査します。

Jaeger UIで、分散トレースの情報にエラー、または処理の遅延がないかどうかを確認します。エラーまたは処理の遅延があった場合、発生した個所や時刻を確認します。
Kibanaなどの可視化ツールで発生時間帯の標準出力を確認し、HMP-PCTOのメッセージなどエラーの情報があるかどうか確認します。
Prometheus UIなどの可視化ツールでメトリクスの情報を確認し、処理の遅延や、スレッドのキューへの滞留があるかどうかを確認します。
Podの障害、またはPodが終了しない事象があった場合は、Kubernetes上のpodの詳細情報を取得して、Podの状態やEvent情報を確認します。

調査個所、対策

ユーザは、それぞれ次の個所を調査し、対策を行います。

標準出力の情報

標準出力をKibanaなどの可視化ツールで確認してください。標準出力にHMP-PCTOが出力したエラーメッセージがあったときは、「8.　メッセージ」を参照してください。メッセージに対策が記載されている場合は、それに従って対策を行ってください。

HMP-PCTOが出力したエラーメッセージに出力されたブランチXID（またはルートXID）の情報から、分散トレースや、連携製品のTomcatやDBのログのトラブルシュート情報に、同じブランチXID（またはルートXID）の情報があるかどうか、あった場合はその情報から、サービス依頼元やDBに問題がないかを合わせて確認してください。

パラメタの誤りがある場合は、修正して再度HMP-PCTOを起動してください。
分散トレースの情報

分散トレースをJaeger UIで確認してください。処理結果がエラーとなっている個所、または、処理が遅延している個所を確認してください。また、その処理がHMP-PCTO製品内部の処理かどうかも確認してください。

分散トレースに出力されたブランチXID（またはルートXID）の情報から、連携製品のTomcatやDBのログのトラブルシュート情報に、同じブランチXID（またはルートXID）の情報があるかどうか、あった場合はその情報から、サービス依頼元やDBに問題がないかを合わせて確認してください。

HMP-PCTO製品内部の処理でエラー、または遅延が発生している場合は、「6.5.1 取得する情報」に記載の情報を収集し、サポート部署へ調査を依頼してください。

HMP-PCTOの処理ではない場合は、連携製品でのエラー、遅延であるため連携製品のサポートに調査を依頼してください。
メトリクスの情報

メトリクスをPrometheus UIなどの可視化ツールで確認してください。CPU使用率・メモリ使用量などの情報から、処理が遅延している個所を確認してください。必要に応じてCPUコアやメモリの増強を行ってください。また、スレッドのキューへの滞留数を示している「executor_queued_tasks」「hmppcto_asynctask_queued_operations」が常時1以上になっている場合、同時実行可能なスレッド数を増やしてください。
Kubernetesの情報

Kubernetes上のpodの詳細情報を取得し、環境不正またはpodの操作ミスがないか確認してください。また、詳細情報の中のEvent情報から、ライフサイクルイベントハンドラで実行するHMP-PCTOのシェルスクリプトが出力したエラーメッセージがあったときは、「8.　メッセージ」を参照してください。メッセージに対策が記載されている場合は、それに従って対策を行ってください。

(b)　サポート部署の調査、対策

ユーザから調査依頼を受け、ユーザから資料を入手したサポート部署が調査する内容は次のとおりです。

標準出力の情報をエクスポートしたファイル

HMP-PCTOのエラーメッセージ、またはスタックトレースが出力されていないか確認します。

また、次に示す、そのほかの連携製品から出力された標準出力の情報からエラーメッセージが出力されていないか確認します。
- HMP-ADIF
- Spring
- Java VM
- Kubernetesの情報
サポート部署は、ユーザにpodの情報収集した出力結果ファイルを依頼し、その結果から状態を確認します。
分散トレース情報をエクスポートしたファイル

サービス呼び出し関連が知りたい場合や、遅延が発生していて遅延個所を特定したい場合は、分散トレースを確認します。分散トレースでは、トランザクション内の次の実行時間を確認できます。
- トランザクション（ルートXIDの割り当て〜合意）
- サービス（Orchestrator/Entity-ServiceまたはOrchestrator/Entity-Module）の実行時間
- DBアクセス時間
- EADS APIアクセス時間（トライアル版では取得できません）
- ConsensusLogアクセス時間
- REST API通信時間
- gRPC通信時間

連携製品側のトラブルシュートが必要になった場合、関連部署へ調査依頼を行います。

HMP-ADIF
EADS（トライアル版では不要です）
uCosminexus Application Runtime

OSSでのトラブルシュートが必要になった場合、関連部署（OSSサポートチーム）へ調査依頼を行います。

Spring
PostgreSQL

通信データの確認

製品不良による電文設定ミス、ユーザのHTTPヘッダミス（SQL-Participantを使用する場合の先行プリペア設定もれなど）のおそれがある場合は、次の情報を確認します。

Tomcatアクセスログ

ヘッダ情報から、REST API通信の内容を確認します。
分散トレース

gRPC通信の内容を確認します。

連携製品の調査

DB障害やEADS障害などの連携製品については、連携製品側のトラブルシュート情報を取得し、連携製品のサポート部署に調査を依頼します。

DBサーバのログファイル
EADsのトラブルシュートファイル（トライアル版では取得できません）

次の情報を、連携製品調査の補助資料として必要に応じて連携製品側へ情報を提供します。

分散トレース

次の項目を確認します。

・XA関数実行時の順序、内容、実行結果を確認します。

・EADS API実行時の順序、内容、実行結果を確認します。なお、トライアル版では確認不要です。
標準出力

エラーメッセージ、またはスタックトレースが出力されているかどうかを確認します。

統計情報確認

通信遅延、プロセススローダウンなどの遅延が発生した場合、ブランチXIDの情報だけでは原因の特定（例えば、通信量やディスクIOが競合したなど）が難しいため、次の情報から、遅延発生時間帯やその時間帯に動いていたブランチXIDを特定します。

メトリクス

gRPC通信量、GC回数、CPU情報を取得します。
分散トレース

通信やファイルアクセスで遅延が発生し始めた時間を特定します。

ページの先頭へ

9.5.4 障害原因の調査方法

(1) 事前準備

(2) 監視の設定

(3) 障害発生時の流れ

(4) 資料取得

(5) 主なトラブルと調査個所

(6) 障害個所の特定、原因の調査・対策

(a) ユーザ（システム運用者）の調査、対策

(b) サポート部署の調査、対策

9.5.4　障害原因の調査方法

(1)　事前準備

(2)　監視の設定

(3)　障害発生時の流れ

(4)　資料取得

(5)　主なトラブルと調査個所

(6)　障害個所の特定、原因の調査・対策

(a)　ユーザ（システム運用者）の調査、対策

(b)　サポート部署の調査、対策