VM/ベアメタルの Runtime Fabric のトラブルシューティング

このトピックでは、VM/ベアメタルの Anypoint Runtime Fabric をインストールおよび管理するときの一般的なエラーとその解決手順について説明します。

完全なネットワーク評価の取得

ネットワークの全体的な健全性評価を取得するには、次のコマンドを実行します。

/opt/anypoint/runtimefabric/rtfctl status

rtfctl を使用したネットワーク接続のトラブルシューティング

すべての Anypoint Runtime Fabric クラスターには Anypoint コントロールプレーンとの接続が必要であり、接続が干渉されると機能が制限され、結果としてアプリケーションのデプロイメントに失敗したり、Anypoint Runtime Manager で状況が低下したりするおそれがります。

rtfctl を使用して、Runtime Fabric に必要なアウトバウンド接続があることを確認するだけでなく、接続に関する問題をトラブルシューティングすることができます。

アウトバウンド接続の確認

各ノードで、「rtfctl のインストール」の手順に従って rtfctl をインストールします。クラスターのすべてのコントローラーノードとワーカーノードで次のコマンドを実行し、必要なアウトバウンド接続を確認します。

sudo ./rtfctl test outbound-network

サンプル出力:

[root@rtf-controller-1 runtimefabric]# sudo ./rtfctl test outbound-network
Using proxy configuration from Runtime Fabric (proxy "", no proxy "")

Using 'US' region
transport-layer.prod.cloudhub.io:443 ✔
https://anypoint.mulesoft.com ✔
https://worker-cloud-helm-prod.s3.amazonaws.com ✔
https://exchange2-asset-manager-kprod.s3.amazonaws.com ✔
https://ecr.us-east-1.amazonaws.com ✔
https://494141260463.dkr.ecr.us-east-1.amazonaws.com ✔
https://prod-us-east-1-starport-layer-bucket.s3.amazonaws.com ✔
https://runtime-fabric.s3.amazonaws.com ✔
tcp://dias-ingestor-nginx.prod.cloudhub.io:443 ✔

アウトバウンド接続に問題があり、Runtime Fabric が必要な Anypoint コントロールプレーンサービスのいずれかにアクセスできない場合、ネットワークチームと協力して「ポートの IP アドレスとホスト名の許可リストへの追加」で説明されているように必要なポート IP およびホスト名を許可リストに追加していることを確認してください。

未知の証明書機関エラーのトラブルシューティング

アウトバウンド接続を検証するためのネットワークテストを実行すると、x509: certificate signed by unknown authority エラーが返されることがあります。

このエラーは、Runtime Fabric がサポートしていない独自のルート CA を使用しているファイアウォールまたはプロキシによってトラフィックが捕捉されたことによって発生します。

証明書の発行者を確認するには、次のコマンドを実行します。

curl -v https://rtf-runtime-registry.kprod.msap.io

Amazon が発行者としてリストされていることを確認します。

Server certificate:

subject: CN=*.prod.cloudhub.io
start date: Nov 12 00:00:00 2021 GMT
expire date: Dec 10 23:59:59 2022 GMT
subjectAltName: host "rtf-runtime-registry.kprod.msap.io" matched cert's "*.kprod.msap.io"
issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
SSL certificate verify ok.

他の発行者がリストされている場合は、トラフィックが捕捉されていることを意味します。

アプリケーションポッド用の Anypoint Monitoring サイドカーコンテナの接続の問題のトラブルシューティング

アプリケーションデプロイメントポッドのサイドカーコンテナを監視しているときに接続の問題が発生した場合は、ネットワークポートの前提条件を確認して、必須ポートのブロックをすべて解除してください。Anypoint Monitoring を許可しない場合は、機能に問題がなくても Anypoint Visualizer ポート 5044 からエラーが報告される場合があります。詳細は、「"Failed to connect to failover" ERROR logs in RTF application pod sidecar container^ (RTF アプリケーションポッドのサイドカーコンテナに「Failed to connect to failover」エラーが記録される)」を参照してください。

chrony 同期チェックエラーのトラブルシューティング

Runtime Fabric の時間同期デーモンでは chrony が必要です。init.sh インストールスクリプトで chrony が見つからないと、Runtime Fabric のインストールは次のエラーで失敗します。

============================================================================================
1 / 10: Install required packages
================================================
chrony-3.4-1.el7.x86_64
Checking chrony sync status...Retrying in 30 seconds...
Retrying in 30 seconds...
Error: chrony sync check failed 3 times, giving up.

***********************************************************
** Oh no! Your installation has stopped due to an error. **
***********************************************************
1. Visit the troubleshooting guide for help:
xref:runtime-fabric::troubleshoot-guide.adoc#troubleshoot-install-package-issues[Troubleshoot Install Package Issues].

2. Resume installation by running /opt/anypoint/runtimefabric/init.sh

Additional information: Error code: 1; Step: install_required_packages; Line: -;

この問題を解決するには、次の手順を実行します。

chrony が有効化されていることを確認します。

systemctl enable chronyd
Network Time Protocol (NTP) が無効化されていて動作していないことを確認します。

systemctl stop ntpd; systemctl disable ntpd
ネットワークチームに連絡して、/etc/chrony.conf のタイムサーバーが到達可能であることを確認するように依頼します。

chrony が接続元と同期していることを確認します。

chronyc sourcestats -v

Number of sources = 4
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
ns3.turbodns.co.uk         16  12   58m     -0.006      0.014   +370us    14us
test.diarizer.com          16   9  327m     -0.184      0.144  -1618us   799us
ntp1.vmar.se                6   3   21m     +0.117      0.074   +228us    10us
time.cloudflare.com         6   5   86m     +0.014      0.214  +2040ns    94us

chronyc 追跡の Leap status 値が Normal であることを確認します。

chronyc tracking

Reference ID : A29FC87B (time.cloudflare.com)
Stratum : 4
Ref time (UTC) : Mon Jul 20 15:42:57 2020
System time : 0.000000003 seconds slow of NTP time
Last offset : +0.000344024 seconds
RMS offset : 0.000172783 seconds
Frequency : 2.265 ppm slow
Residual freq : +0.149 ppm
Skew : 0.124 ppm
Root delay : 0.003362593 seconds
Root dispersion : 0.000759320 seconds
Update interval : 1031.1 seconds
Leap status : Normal

init.sh を実行してインストールを再試行します。

クラスターの問題のトラブルシューティング

サポートケースを入力するときに、サポートチームから次のコマンドのいずれかまたは両方を実行してデバッグ情報を生成するよう要求される場合があります。

Kubernetes オブジェクトおよびログのみが含まれるアーカイブを生成する rtfctl report コマンド。
すべてのクラスターノードから診断を収集する rtfctl appliance report コマンド。

サポートチームから、「デバッグ情報のダウンロード」で説明されているようにオペレーションセンターから情報をダウンロードするよう要求される場合があります。

クラスターの縮小または拡張エラーのトラブルシューティング

Runtime Fabric からクラスターのノードを追加または削除 (クラスターを拡張または縮小) した直後に新しいノードを追加しようとすると、クラスター状況の「縮小中」エラーまたはクラスター状況の「拡張中」エラーが返される場合があります。この場合は、4 分以上待ってから新しいノードを追加してください。

アプリケーションデプロイメントの問題のトラブルシューティング

Anypoint Monitoring エージェントの問題

まれに、Anypoint Monitoring エージェントが原因でアプリケーションがデプロイされないこともあります。このような状況では、次のメッセージが表示される場合があります。

アプリケーションが Deploying 状態のままになる
Error starting monitoring agent (code -1)

この場合、アプリケーションを再デプロイし、次のカスタムプロパティを設定します。

anypoint.platform.config.analytics.agent.enabled=false

Anypoint Monitoring エージェントによって、デプロイされたアプリケーションの状態が変更されることもあります。次のいずれかの現象が発生した場合、

アプリケーションが Running から Applying に移行
Monitoring agent has exited with code -1

これはエージェントが再起動していることを示します。実行中のアプリケーションへの影響はありません。アプリケーションメトリクスはキューに追加され、エージェントの再起動後に再度収集されます。

VMware VMXNET Generation 3 の問題

Runtime Fabric アプライアンスを VMware 環境でホストしていてアプリケーションをデプロイできない場合は、次の MuleSoft ナレッジベース記事を参照してください: RTF Networking Issues with VMware and "[Runtime Fabric] java.net.UnknownHostException:" Errors (VMware の RTF ネットワーキングの問題と「[Runtime Fabric] java.net.UnknownHostException:」エラー).

「CrashLoopBackOff - Couldn’t initialize inotify (CrashLoopBackOff - inotify を初期化できませんでした)」エラーのトラブルシューティング

inotify 値が環境で低すぎると、次のエラーメッセージが表示されることがあります。

[Kubernetes] Container "anypoint-monitoring" - CrashLoopBackOff - Couldn't initialize inotify

また、gravity status コマンドの出力で次のアラートが表示されることもあります。

        * rtf-worker-1 (172.31.3.5, worker_node)
            Status:		degraded
            [×]			Unable to initialize inotify (too many open files)
            Remote access:	online

2 つの Linux カーネル値で inotify の使用を制御します。

inotify.max_user_watches
inotify.max_user_instances

inotify.max_user_watches 設定は 1048576 に設定する必要があります。Runtime Fabric インストーラーでは自動的にこの設定が実行されるため、原因として最も可能性が高いのは別のプロセスまたはユーザーによってこの設定が低い値に変更されたことです。

この設定を修正するには、次のコマンドを実行します。

$ sysctl -w fs.inotify.max_user_watches=1048576

ノードが再起動されても影響がないようにこの変更を永続的なものにするには、例えば次のように、/etc/sysctl.d ディレクトリ内のファイルで設定を定義します。

$ cat /etc/sysctl.d/inotify.conf
fs.inotify.max_user_watches=1048576

ほとんどの OS ディストリビューションでは inotify.max_user_instances がデフォルトで 128 に設定されます。この値は多くのアプリケーションのデプロイやレプリカのワーカーノードには低すぎます。このエラーが表示された場合は、上記の手順に従って inotify.max_user_instances の値を増やしてください。

いずれの場合も、システム管理者と一緒にこの状況を確認し、これらの値が使用状況に適していて、将来減らされることがないことを確認してください。

アプリケーションのランタイムの問題のトラブルシューティング

次のいずれかの Runtime Fabric アラートメッセージが報告された場合、1 つ以上のコントローラーノードの回復が必要になる場合があります。

Management plane is unreachable

InfluxDB is down or no connection between Kapacitor and InfluxDB

Node is down

CRITICAL / Kubernetes node is not ready: <ip_address>

CRITICAL / etcd: cluster is unhealthy

ターミナルを開き、gravity status コマンドを実行して、クラスターおよび個々のコンポーネントの健全性状況を取得します。

ノードを回復するには、「Runtime Fabric からのノードの追加または削除」で提供されている手順に従います。

環境変数の問題のトラブルシューティング

この手順では、インストールプロセスで手順を実行するために必要な変数を検出します。この変数をインストールに提供する方法は、インストールを実行する場所により異なります。

AWS の場合、変数は terraform スクリプトで設定され、/opt/anypoint/runtimefabric/env に配置されているファイルに出力されます。
Azure の場合、変数は ARM テンプレートの実行時に設定され、仮想マシンインスタンスでタグとして取得されます。
手動インストールの場合、ユーザーが /opt/anypoint/runtimefabric/env にある値を使用してファイルを作成します。

このプロパティを取得したら、Anypoint Platform に接続して RTF_ACTIVATION_DATA 値に基づいて追加の値を取得するための手順が実行されます。

一般的なエラー

アクティベーションデータ値に問題がある場合や、インスタンスでのインターネットアクセスに問題がある場合、次のエラーが発生することがあります。

curl: (7) Failed connect to anypoint.mulesoft.com:443; Operation now in progress
Error: Failed to fetch registration properties. (000). Please check your token is valid


============ Error ============
Exit code: 1
Line:

このエラーが確認された場合、次の操作を実行してください。

インスタンスにアウトバウンドインターネット接続があることを確認します。簡単な検証方法は、次のコマンドを実行し、301 応答が返されることを確認することです。
```
curl https://anypoint.mulesoft.com
```
ネットワーク接続の初期化が完了しなかった場合は、インストール手順を再度実行します。
- Azure では、スクリプトは /opt/anypoint/runtimefabric/script.sh foreground にあります。
- AWS および手動インストールでは、スクリプトは /opt/anypoint/runtimefabric/init.sh foreground にあります。
Anypoint Runtime Manager で作成された Runtime Fabric と比較することで、アクティベーションデータ値が正しいことを検証します。

問題が引き続き発生する場合は、サポートチケットを申請して詳細なサポートを要求してください。

失敗したインストールの再開

init スクリプトを実行することで、インストールが失敗した時点からそのインストールを再開できます。

AWS および手動インストール:
```
/opt/anypoint/runtimefabric/init.sh
```
Azure インストール:
```
/opt/anypoint/runtimefabric/script.sh
```

インストールパッケージの問題のトラブルシューティング

この手順では、必要なパッケージをインスタンスにインストールします。yum パッケージリポジトリを使用して、必要なパッケージのダウンロードとインストールを行います。

一般的なエラー

この手順でエラーがある場合、以下を確認します。

インスタンスにアウトバウンドインターネット接続があることを確認します。簡単な検証方法は、次のコマンドを実行し、301 応答が返されることを確認することです。
```
curl https://anypoint.mulesoft.com
```
手動インストールを実行している場合、init.sh スクリプトがルート権限で実行されていることを確認します。
```
sudo ./init.sh foreground
```
必要なパッケージの 1 つを手動でインストールし、インストールスクリプト以外でインストールが成功するかどうかを確認します。
```
sudo yum install -y chrony
```
- 成功しない場合、運用チームに問い合わせて、サポートを要求してください。インスタンスへの昇格したアクセス権の要求が必要になる場合があります。

パッケージの手動インストールが成功した場合や、引き続きサポートが必要な場合は、サポートチケットを申請してください。

ディスクのフォーマットおよびマウント

この手順では、RTF_DOCKER_DEVICE または RTF_ETCD_DEVICE 変数が提供されているブロックデバイスまたはディスクに対して次のタスクを実行します。

インスタンスで使用可能なブロックデバイスに値がマップされていることを確認するチェックを実行します。
ディスクがすでにマウントされている場合は、マウント解除します。
ディスクをフォーマットします。
マウントエントリを /etc/fstab ファイルに追加します。
$DOCKER_MOUNT または $ETCD_MOUNT の値に基づいてディレクトリを作成します。
上記で作成した予期されるディレクトリにディスクをマウントします。

RTF コンポーネントのインストール

この手順では、Anypoint Platform に接続し、Runtime Fabric コンポーネントをクラスターにダウンロードしてインストールします。

デプロイメントが時間制限内に完了できない場合、この手順でエラーが返されることがあります。

...
[OK]
Installing Runtime Fabric Agent. This may take several minutes...
configmap "grafana-dashboards" deleted
configmap "kapacitor-alerts" deleted
Release "runtime-fabric" does not exist. Installing it now.
The following deployments failed to become ready within the time limit:
monitor ---
Name:           monitor-79c7564b77-wb9c6
Namespace:      rtf
Node:           10.165.12.87/10.165.12.87
Start Time:     Thu, 13 Dec 2018 20:23:59 +0000
Labels:         app=monitor
                pod-template-hash=3573120633
Annotations:    checksum/config=4c4aac48d9cc8b24828b38ba0eb587840bc17b2449a54d593f74e2d58e5c12ae
                kubernetes.io/psp=privileged
                seccomp.security.alpha.kubernetes.io/pod=docker/default
Status:         Running
IP:             10.244.82.17
Controlled By:  ReplicaSet/monitor-79c7564b77
Containers:
...
<< More information displayed that describes the deployment manifest and stack trace >>

このエラーが確認された場合、次の操作を実行してください。

アウトバウンド TCP ポート 5672 がインターネットに対して開かれていることを確認します。内部ネットワークで実行されているコントローラー VM からインターネット上のこのホスト名への接続が許可されている必要があります。
インターネットへの接続を確立するには、TCP プロキシが必要になる場合があります。必要に応じて、ネットワークチームと連携して検証と確認を行ってください。「Anypoint Runtime Fabric インストールの前提条件」を参照してください。

期限切れのクライアント証明書のトラブルシューティング

クラスターで Anypoint Platform との相互認証を使用する場合は、rtf 名前空間の certificate-renewal という名前の cron ジョブにより、クライアント証明書が定期的に更新されます。このジョブは証明書の期限切れ前に実行され、証明書が期限切れになる前に更新します。予期せぬ状況により、証明書が更新されずに期限切れになることがあります。そのような場合、certificate-renewal ジョブで次のエラーが記録されます。

time="2020-03-11T12:42:05Z" level=warning msg="{\"timestamp\":\"2020-03-11T12:42:05.035+00:00\",\"status\":409,\"error\":\"Conflict\",\"message\":\"Certificate was already exipired, please renew cert!\",\"path\":\"/api/v1/organizations/4d70ccf6f0ce/agents/74f0df29/renew\"}"

証明書を更新するには、rtfctl appliance renew-expired-client-cert コマンドを使用します。詳細は以下を参照してください。

Runtime Fabric のバックアップと復元後の不整合のトラブルシューティング

クラスターをバックアップから復元した後に、Runtime Manager で次のような不整合が見られることがあります。

削除したアプリケーションが実行中と表示される
最近デプロイされたアプリケーションが 0 個のレプリカとリストされる
デプロイメントのレプリカ数が Runtime Manager で指定したレプリカ数と一致しない

これらのそれぞれの状況では、デプロイメントの状況が適用中と表示されることと、対応する API コールで status 項目と desiredState 項目が一致しないことが明らかになることを確認してください。根本原因の説明については、「The Back Up and Restore Process Does Not Affect the Control Plane (バックアップと復元プロセスがコントロールプレーンに影響しない)」を参照してください。

これらの競合を解決するには、クラスターに必要な変更を手動で適用し、予期される状況を照合する必要があります。これらの変更は自動的に再同期することも、新しい変更で上書きすることもできません。クラスターの現在の状況が予期される値に一致してからでないと、コントロールプレーンから追加の変更を適用することはできません。バックアップを作成した後に適用した変更を確認する必要がある場合は、監査ログを使用してください。

オペレーションセンターの監視およびログの問題のトラブルシューティング

1 つ以上のノードの再起動後にオペレーションセンターの監視およびログの再起動に失敗した場合、すべての VM でポート転送ルールが適用されており、VM で実行されている Kubernetes ポッドにトラフィックを伝送できることを確認します。詳細は、「firewalld を使用する場合の転送の有効化」を参照してください。

Ops Center メトリクスダッシュボードにアプリケーションが表示されない場合のトラブルシューティング

シナリオ: Ops Center メトリクスダッシュボードで次の現象が起きています。

メトリクスデータに想定外のスパイクが頻繁に示される
ドロップダウンメニューにアプリケーションが表示されない
InfluxDB ログに max-series-per-database limit exceeded エラーが含まれる。

influxdb_pod_name を取得するには、kubectl -n monitoring get pod -lcomponent=influxdb を実行します。

このシナリオは、エントリ数が事前設定されている 100 万件の制限に達すると発生することがあります。

この問題を解決するには、シリーズ制限を 1000 万以上に増やします。

設定マップを編集します。
```
kubectl edit cm influxdb -n monitoring
```
max-series-per-database 値を 1000 万に変更します。
```
max-series-per-database = 10000000
```
変更を保存します。
InfluxDB ポッドを再起動して変更を適用します。
```
kubectl -n monitoring delete pod <influxdb_pod_name>
```

データベースシリーズを削除してログに記録されるデータを変更するには、「RTF - Error Reporting Heap Metrics: InfluxDBException: partial write: max-series-per-database limit exceeded^ (RTF - ヒープメトリクスレポートエラー: InfluxDBException: 部分的な書き込み: max-series-per-database 制限を超えました)」の手順に従ってください。

エージェントバージョンの不一致のトラブルシューティング

シナリオ: Runtime Fabric のアップグレード後に、Runtime Manager で次のエラー状況が発生します。Degraded: Runtime Fabric agent version mismatch detected from control plane. (Degraded: コントロールプレーンで Runtime Fabric エージェントバージョンの不一致が検出されました。)このエラーは、Anypoint Platform に保存されているクラスターの Runtime Fabric エージェントバージョンと、エージェント状況プローブから報告されたバージョンが一致しない場合に発生します。

この問題の一般的な原因は次のとおりです。

Runtime Fabric エージェントのアップグレードが失敗した、またはロールバックされた
アップグレード前のバックアップが復元された
相互認証が無効化されている

エージェントアップグレードが失敗した

この状況では、Runtime Fabric エージェントのアップグレードが失敗してロールバックされているものの、目的の (アップグレード後の) バージョンが Anypoint Platform にリストされています。この問題を解決するには、「Degraded Status as Runtime Fabric Agent Version Mismatch Detected^ (Runtime Fabric エージェントバージョンの不一致が検出された場合の状況の低下)」を参照してください。

アップグレード前のバックアップが復元された

コントロールプレーンから適用された最新バージョンよりも前の Runtime Fabric バージョンで作成されたバックアップを復元した場合は、アップグレードをやり直す必要があります。詳細は、「バックアップ実行後の変更内容が復元されない」を参照してください。

相互認証が無効化されている

Runtime Fabric バージョン 1.11 以降では相互認証が必要です。相互認証が有効化されていない状態で 1.11 より前のバージョンから 1.11 以降にアップグレードすると、このエラーメッセージが返される場合があります。この問題を解決するには、相互認証を有効化してからアップグレードを再び実行します。

エージェントポッドのトラブルシューティング

1 つ以上の Runtime Fabric エージェントポッドコンテナでログを確認せず、エントリと一致するエラーメッセージを検索していない場合は、トラブルシューティングシナリオを実行していない次のメトリクスサーバーを確認します。

rtfd コンテナが試行のたびにクラッシュする場合は、次のエラーメッセージが返されることがあります。

2023/02/23 16:35:20 instantiating client: fetching server resource preferences: unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request

このエラーは、Kubernetes メトリクスサーバーがインストールされているのに実行されていないために発生します。 Runtime Fabric アプライアンスバージョン 1.1.1636064094-8b70d2d 以降には、[monitoring] 名前空間でのデプロイとしてメトリクスサーバーが含まれています。さらにトラブルシューティングするには、このデプロイおよび関連付けられているポッドのイベントとログを調査する必要があります。メトリクスサーバーが起動して動作状態になれば、rtfd は想定通りに機能します。

メトリクスサーバーの復旧に関して支援が必要であれば、完全なアプライアンスレポートを沿えて MuleSoft サポートまでご連絡ください。

メールアラートのカスタマイズが消えた場合のトラブルシューティング

シナリオ: アプライアンスのアップグレード後に、メールアラートのカスタマイズ内容が失われます。

これは VM/ベアメタル上での Runtime Fabric の制限であり、Runtime Fabric アプライアンスのアップグレード前のドキュメントに記載されています。推奨される対策は、アップグレード前にカスタマイズ内容をすべてバックアップしておき、アップグレードの完了後に再び適用することです。

外部ログ転送のトラブルシューティング

ログアグリゲーターでは TLS v1.2 の使用が必須

Runtime Fabric の外部ログ転送ライブラリでは TLS v1.3 がサポートされていません。

ログアグリゲーターで TLS v1.2 を使用していないと、ログが転送されず、外部ログ転送ポッドに次のような警告が表示されます。

[ warn] [engine] failed to flush chunk '8-1652967809.949249428.flb', retry in 10 seconds: task_id=5, input=tail.0 > output=es.0 (out_id=0)
[ warn] [engine] chunk '8-1652967799.665591977.flb' cannot be retried: task_id=1, input=tail.0 > output=es.0

ログアグリゲーターで、次のようなエラーメッセージが表示される場合があります。

[WARN ][o.e.h.AbstractHttpServerTransport] [] caught exception while handling client http traffic, closing connection Netty4HttpChannel{localAddress=0.0.0.0/0.0.0.0:9200, remoteAddress=/*.*.*.*:1787}

io.netty.handler.codec.DecoderException: javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1.2 is not enabled or supported in server context

...

Caused by: javax.net.ssl.SSLHandshakeException: Client requested protocol TLSv1.2 is not enabled or supported in server context

このような場合は、TLSv v1.2 を有効にするか、中間ノードで TLS v1.2 セッションを終了して最終的な宛先までの新しい TLS v1.3 セッションを作成するようにネットワーキングインフラストラクチャを設定してください。