トラブルシューティングのリソース
この記事では、Azure Arc 対応データ サービスのトラブルシューティングのリソースについて説明します。
アップロード
ログのアップロード関連のエラー
kubectl を使用して direct 接続モードで Azure Arc データ コントローラーをデプロイし、Log Analytics ワークスペース資格情報のシークレットを作成していない場合、データ コントローラー CR (カスタム リソース) に次のエラー メッセージが表示されることがあります。
status": {
"azure": {
"uploadStatus": {
"logs": {
"lastUploadTime": "YYYY-MM-HHTMM:SS:MS.SSSSSSZ",
"message": "spec.settings.azure.autoUploadLogs is true, but failed to get log-workspace-secret secret."
},
上記のエラーを解決するには、次のように Log Analytics ワークスペースの資格情報を使用して、WorkspaceID と SharedAccessKey を含む シークレットを作成します。
apiVersion: v1
data:
primaryKey: <base64 encoding of Azure Log Analytics workspace primary key>
workspaceId: <base64 encoding of Azure Log Analytics workspace Id>
kind: Secret
metadata:
name: log-workspace-secret
namespace: <your datacontroller namespace>
type: Opaque
直接接続モードでのメトリックのアップロード関連のエラー
直接接続モードでメトリックの自動アップロードを構成し、MSI に必要なアクセス許可が (メトリックのアップロードに関するページの説明どおりに) 適切に付与されていない場合、次のようにログにエラーが表示されることがあります。
'Metric upload response: {"error":{"code":"AuthorizationFailed","message":"Check Access Denied Authorization for AD object XXXXXXXXX-XXXX-XXXX-XXXXX-XXXXXXXXXXX over scope /subscriptions/XXXXXXXXX-XXXX-XXXX-XXXXX-XXXXXXXXXXX/resourcegroups/my-resource-group/providers/microsoft.azurearcdata/sqlmanagedinstances/arc-dc, User Tenant Id: XXXXXXXXX-XXXX-XXXX-XXXXX-XXXXXXXXXXX. Microsoft.Insights/Metrics/write was not allowed, Microsoft.Insights/Telemetry/write was notallowed. Warning: Principal will be blocklisted if the service principal is not granted proper access while it hits the GIG endpoint continuously."}}
上記のエラーを解決するには、Azure Arc データ コントローラー拡張機能の MSI を取得し、メトリックのアップロードに関するページの説明どおりに必要なロールを付与します。
直接接続モードでの使用状況のアップロード関連のエラー
直接接続モードで Azure Arc データ コントローラーをデプロイした場合、使用状況情報をアップロードするために必要なアクセス許可が、Azure Arc データ コントローラー拡張機能 MSI に対して自動的に付与されます。 自動アップロード プロセスでアクセス許可に関連する問題が発生した場合は、次のようにログにエラーが表示される可能性があります。
identified that your data controller stopped uploading usage data to Azure. The error was:
{"lastUploadTime":"2022-05-05T20:10:47.6746860Z","message":"Data controller upload response: {\"error\":{\"code\":\"AuthorizationFailed\",\"message\":\"The client 'XXXXXXXXX-XXXX-XXXX-XXXXX-XXXXXXXXXXX' with object id 'XXXXXXXXX-XXXX-XXXX-XXXXX-XXXXXXXXXXX' does not have authorization to perform action 'microsoft.azurearcdata/datacontrollers/write' over scope '/subscriptions/XXXXXXXXX-XXXX-XXXX-XXXXX-XXXXXXXXXXX/resourcegroups/my-resource-group/providers/microsoft.azurearcdata/datacontrollers/arc-dc' or the scope is invalid. If access was recently granted, please refresh your credentials.\"}}"}
アクセス許可の問題を解決するには、MSI を取得し、メトリックのアップロードに関するページの説明どおりに必要なロールを付与します。
アップグレード
正しくないイメージ タグ
az CLI を使用してアップグレードし、正しくないイメージ タグを渡すと、2 分以内にエラーが表示されます。
Job Still Active : Failed to await bootstrap job complete after retrying for 2 minute(s).
Failed to await bootstrap job complete after retrying for 2 minute(s).
ポッドを表示すると、ブートストラップ ジョブの状態が ErrImagePull のように表示されます。
STATUS
ErrImagePull
ポッドについて記述すると、以下のように表示されます。
Failed to pull image "<registry>/<repository>/arc-bootstrapper:<incorrect image tag>": [rpc error: code = NotFound desc = failed to pull and unpack image
解決するには、「バージョン ログ」を参照し、正しいイメージ タグを確認してください。 正しいイメージ タグを使用して upgrade コマンドを再実行します。
レジストリまたはリポジトリに接続できない
アップグレードを試みているときに、アップグレード ジョブでエラーは発生していないが、実行時間が 15 分を超える場合、ポッドを観察することでアップグレードの進行状況を確認できます。 [ファイル名を指定して実行]
kubectl get pods -n <namespace>
ポッドを表示すると、ブートストラップ ジョブの状態が ErrImagePull のように表示されます。
STATUS
ErrImagePull
ブートストラップ ジョブ ポッドについて記述して、イベントを表示します。
kubectl describe pod <pod name> -n <namespace>
ポッドを記述すると、以下のエラーが表示されます。
failed to resolve reference "<registry>/<repository>/arc-bootstrapper:<image tag>"
これは通常、イメージがプライベート レジストリからデプロイされ、Kubernetes を使用して yaml ファイルを介してアップグレードしているときに、yaml ファイルがプライベート レジストリではなく mcr.microsoft.com を参照すると発生します。 解決するには、アップグレード ジョブを取り消します。 デプロイ元のレジストリを見つけるには、以下を実行します。
kubectl describe pod <controller in format control-XXXXX> -n <namespace>
Containers.controller.Image を探します。ここに、レジストリとリポジトリが表示されます。 これらの値をキャプチャし、yaml ファイルに入力して、アップグレードを再実行します。
十分なリソースがない
アップグレードを試みているときに、アップグレード ジョブでエラーは発生していないが、実行時間が 15 分を超える場合、ポッドを観察することでアップグレードの進行状況を確認できます。 [ファイル名を指定して実行]
kubectl get pods -n <namespace>
いくつかのコンテナーの準備ができていることを示しているが、そうではないものがあるポッドを探します。たとえば、この metricsdb-0 ポッドには、2 つのコンテナーのうちの 1 つしかありません。
NAME READY STATUS RESTARTS AGE
bootstrapper-848f8f44b5-7qxbx 1/1 Running 0 16m
control-7qxw8 2/2 Running 0 16m
controldb-0 2/2 Running 0 16m
logsdb-0 3/3 Running 0 18d
logsui-hvsrm 3/3 Running 0 18d
metricsdb-0 1/2 Running 0 18d
そのポッドについて記述して、イベントを表示します。
kubectl describe pod <pod name> -n <namespace>
イベントがない場合は、コンテナー名を取得し、コンテナーのログを表示します。
kubectl get pods <pod name> -n <namespace> -o jsonpath='{.spec.containers[*].name}*'
kubectl logs <pod name> <container name> -n <namespace>
CPU またはメモリの不足に関するメッセージが表示される場合は、Kubernetes クラスターにノードを追加するか、既存のノードにリソースを追加する必要があります。
種類別のリソース
シナリオ: PostgreSQL サーバーのトラブルシューティング
Kibana と Grafana を使用してログとメトリックを表示する