次の方法で共有


トラブルシューティングのリソース

この記事では、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 ワークスペースの資格情報を使用して、WorkspaceIDSharedAccessKey を含む シークレットを作成します。

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 を使用してログとメトリックを表示する

シナリオ: Azure portal でインスタンスのインベントリを表示する