翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # トラブルシューティング ## vCenter への検出ツールの接続の検証 VMware モジュールの設定エラーが発生した場合は、以下の手順に従って接続を確認します。 **検出ツール VM にアクセスする** + 検出ツール VM にログインし、vCenter でリモートコンソールを開きます。 + ユーザー名: discovery + パスワード: password **vCenter 接続のテスト** 1. vCenter API アクセスをテストする: ``` curl -v --insecure -u : https://:443/mob ``` 1. 期待される成功出力: ``` [ec2-user@discoverytool ~]$ curl -v --insecure -u : https://vcsa/mob > tmp.txt % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 192.168.2.125:443... * Connected to vcsa (192.168.2.125) port 443 (#0) ... * Connection #0 to host vcsa left intact ``` **SSL 証明書をテストする** 1. 次のコマンドを実行します。 ``` openssl s_client -showcerts -servername -connect :443 ``` 1. 期待される成功出力: + vSphere 証明書の詳細を表示する必要があります + ポート 443 での SSL/TLS 接続の検証 ``` [ec2-user@discoverytool ~]$ openssl s_client -showcerts -servername vcsa -connect vcsa:443 CONNECTED(00000003) depth=0 CN = vcsa.onpremsim.env, C = US verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 CN = vcsa.onpremsim.env, C = US verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/CN=vcsa.onpremsim.env/C=US i:/CN=CA/DC=vsphere/DC=local/C=US/ST=California/O=vcsa.onpremsim.env/OU=VMware Engineering -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- --- Server certificate subject=/CN=vcsa.onpremsim.env/C=US issuer=/CN=CA/DC=vsphere/DC=local/C=US/ST=California/O=vcsa.onpremsim.env/OU=VMware Engineering --- ``` ## WinRM のトラブルシューティング WinRM との接続に問題がある場合は、以下の手順に従って接続をテストします。これらの手順は、検出ツールが WinRM を使用して Hyper-V ホストと通信するため、Hyper-V 接続の問題にも適用されます。 ポート 5985 (HTTP) と 5986 (HTTPS) を使用して基本的な WinRM 接続をテストします。ポート 5986 (HTTPS) で接続が機能することを確認する必要があります ``` # Check WinRM listener configuration winrm enumerate winrm/config/listener # Note: Replace with the target computer's hostname or IP address. Adjust the username and password as needed. # Test WinRM connection on port 5985 (HTTP) $cred = Get-Credential Test-WSMan -Computer -Authentication Negotiate -Credential $cred -Port 5985 # Test WinRM connection on port 5986 (HTTPS) Test-WSMan -Computer -Authentication Negotiate -Credential $cred -Port 5986 ``` 上記のテストが失敗した場合は、証明書の検証を無効にして PowerShell セッションを確立してみてください。 ``` $cred = Get-Credential $so = New-PsSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck Enter-PSSession -ComputerName -Credential $cred -Port 5985 -SessionOption $so ``` ## Kerberos のトラブルシューティング Windows サーバーからデータを収集するときに Kerberos 認証に障害が発生した場合は、次のセクションを使用して一般的な問題を診断し、解決します。 ### ネットワーク要件の検証 Kerberos 認証のトラブルシューティングを行う前に、検出ツールが必要なネットワークエンドポイントに到達できることを確認します。 **Kerberos のネットワーク要件を確認するには** 1. ドメインコントローラーへの DNS 解決を確認します。検出ツール VM から次のコマンドを実行します。 ``` nslookup dc01.example.com ``` または、`dig` を使用することもできます。 ``` dig dc01.example.com ``` DNS 解決に失敗した場合は、Active Directory ドメインを解決できる DNS サーバーを使用するように検出ツール VM が設定されていることを確認します。ネームサーバーエントリがドメイン DNS サーバーを指し`/etc/resolv.conf`ていることを確認します。 1. ポート 88 の Key Distribution Center (KDC) への接続を確認します。次のコマンドを実行します。 ``` nc -zv dc01.example.com 88 ``` 正常な出力: ``` Connection to dc01.example.com 88 port [tcp/kerberos] succeeded! ``` 接続が失敗した場合、ファイアウォールルールが検出ツール VM からポート 88 のドメインコントローラーへのトラフィックをブロックしていないことを確認します。 1. WinRM ポート上のターゲット Windows サーバーへの接続を確認します。以下の コマンドを実行します。 ``` nc -zv 5985 nc -zv 5986 ``` 接続が失敗した場合、ターゲットサーバーで WinRM が有効になっていること、およびファイアウォールルールでポート 5985 および 5986 でのインバウンドトラフィックが許可されていることを確認します。 ### 一般的な Kerberos の問題 以下は、一般的な Kerberos の問題とその解決策です。 **大文字と小文字の区別エラー** 症状: 認証中に「サーバーが Kerberos データベースに見つかりません」というエラーが表示されます。 このエラーは通常、Kerberos 領域名が大文字でない場合に発生します。Kerberos レルムは、`krb5.conf`ファイルの大文字で指定する必要があります。例えば、`example.com` ではなく `EXAMPLE.COM` を使用します。 **アカウントロックアウトの防止** 検出ツールはバックオフメカニズムを使用して、アカウントのロックアウトが認証試行に失敗するのを防ぎます。サービスアカウントがロックアウトされた場合は、 の検出ツールウェブ UI を使用してコレクションモジュールを停止して開始することで、コレクションプロセスをリセットできます`https://:5000`。 **CLI から kinit が失敗する** 次の表に、一般的な`kinit`エラーとその解決策を示します。 | エラー | 原因 | ソリューション | | --- | --- | --- | | 領域 の KDC が見つかりません | KDC ホスト名または IP アドレスに到達できないか、領域が で設定されていませんkrb5.conf。 | krb5.conf ファイルに正しい KDC ホスト名と領域が含まれていることを確認します。ポート 88 で DNS 解決と KDC へのネットワーク接続を確認します。 | | 事前認証に失敗しました | サービスアカウントのパスワードが正しくありません。 | パスワードを確認して、もう一度試してください。アカウントがロックアウトされている場合は、再試行する前に Active Directory でロックを解除します。 | | Kerberos データベースにクライアントが見つかりません | プリンシパル名が Active Directory のどのアカウントとも一致しません。 | プリンシパル名が、大文字と小文字を含むアカウント名と正確に一致することを確認します。レルムを大文字username@REALMにした 形式を使用します。 | | KDC のネットワークアドレスを解決できません | DNS は KDC ホスト名を解決できません。 | で DNS 設定を確認します/etc/resolv.conf。DNS サーバーが KDC ホスト名を解決できることを確認します。nslookup または を使用してテストしますdig。 | **kinit が成功してもコレクションが失敗する** が`kinit`成功してもデータ収集が失敗する場合は、以下を確認してください。 1. コレクションに使用されるプリンシパル名が、 中に使用されたケースと`kinit`正確に一致することを確認します。 1. サービスアカウントにターゲットサーバーに必要なアクセス許可があることを確認します。 1. ターゲットサーバーで WinRM が有効になっていることを確認します。 1. コレクションに使用されるホスト名が Active Directory に登録されているホスト名と一致することを確認します。 **Kerberos は一部のサーバーでは機能しますが、他のサーバーでは機能しません** 一部のサーバーでは Kerberos 認証が成功しても、他のサーバーでは失敗する場合は、次の領域を調査します。 サーバーが複数の Active Directory ドメインにまたがる場合は、ドメインごとに個別の Kerberos 認証情報を設定します。`/etc/krb5.conf` ファイルにすべてのレルムのエントリが含まれていることを確認します。各ドメインには、正しい`username@REALM`プリンシパルを持つ独自の認証情報が必要です。 動作中のサーバー上の WinRM 設定と障害が発生したサーバーを比較します。各サーバーで次のコマンドを実行します。 ``` winrm get winrm/config ``` リモートデスクトップとの接続をテストして、問題を分離します。検出ツールは 形式を使用し`username@DOMAIN`、リモートデスクトップは 形式を使用します`DOMAIN\username`。 サービスアカウントが、障害が発生したサーバーのローカル管理者グループのメンバーであることを確認します。ターゲットサーバーで次のコマンドを実行します。 ``` net localgroup Administrators ``` WMI には、オペレーティングシステム情報にアクセスするためのローカル管理者権限が必要です。SQL Server コレクションでは、サービスアカウントにターゲットサーバーに対するローカル管理者アクセス権も必要です。 ### Kerberos 設定チェックリスト データ収集を開始する前に、次のチェックリストを使用して Kerberos 設定を確認します。 + `krb5.conf` ファイルは検出ツール VM に存在します。 + の領域名は大文字です`krb5.conf`。 + サービスアカウント`kinit`で を実行すると、エラーなしで成功します。 + を実行すると、有効で有効期限が切れていないチケット`klist`が表示されます。 + プリンシパル名は Active Directory アカウント名と完全に一致します。 + DNS 解決は KDC ホスト名で機能します。 + ポート 88 の KDC へのネットワーク接続が確認されます。 + ポート 5985 および 5986 のターゲット Windows サーバーへのネットワーク接続が確認されます。 + (マルチドメイン) 各 Active Directory ドメインには、検出ツールで独自の認証情報が設定されており、すべてのドメインの `[realms]` エントリと `[domain_realm]`エントリ`krb5.conf`が含まれています。 ## Oracle Database のトラブルシューティング データ不足やエラーなど、Oracle Database の収集に関する問題を診断するには、以下を確認してください。 **接続が拒否またはタイムアウトしました** 症状: Oracle コレクションのステータスは、サーバーの接続エラーを示します。 この問題のトラブルシューティングを行うには、次を確認します。 + Oracle リスナーがターゲットホストで実行されていることを確認します。 `lsnrctl status` + 検出ツールからポート 1521 (またはカスタムポート) の Oracle ホストへのネットワーク接続を確認します。 `nc -zv 1521` + ファイアウォールルールが Oracle リスナーポートでのインバウンド接続を許可していることを確認します。 + Oracle ホスト`lsnrctl services`で を実行して、サービス名を確認します。サービス名が正しくない場合、Oracle リスナーは接続を拒否します。 **認証の失敗 (ORA-01017)** 症状: 無効なユーザー名またはパスワードエラーで収集が失敗します。 この問題のトラブルシューティングを行うには、次を確認します。 + Oracle サービスアカウントが存在し、ロックされていないことを確認します。 `SELECT account_status FROM dba_users WHERE username = 'DISCOVERY_USER';` + 手動で接続して、パスワードが正しいことを確認します。 `sqlplus discovery_user/@:1521/` + アカウントがロックされている場合は、ロックを解除します。 `ALTER USER discovery_user ACCOUNT UNLOCK;` **権限が不十分 (ORA-01031)** 症状: 接続は成功しますが、コレクションは不完全なデータを返します。 この問題のトラブルシューティングを行うには、次を確認します。 + SELECT\_CATALOG\_ROLE が付与されていることを確認します。 `SELECT * FROM dba_role_privs WHERE grantee = 'DISCOVERY_USER';` + 不足している場合は、必要なロールを付与します。 `GRANT SELECT_CATALOG_ROLE TO discovery_user;` **手動認証情報はエラーを表示しますが、自動接続は機能します** 認証情報を手動でサーバーに固定しても、接続が失敗しても検出ツールはフォールバックしません。認証情報で設定したポートとサービス名が、その特定のサーバーの Oracle リスナーと一致していることを確認します。サーバーに非標準のポートまたはサービス名がある場合は、それに応じて認証情報設定を更新します。 **OS レベルのフォールバックが Oracle を検出しない** データベース認証情報が設定されておらず、OS レベルのフォールバックが Oracle を検出しない場合: + SSH または WinRM OS 認証情報が設定され、サーバーに対して動作していることを確認します (OS メトリクスの収集ステータスを確認）。 + Linux ホストの場合は、 `/etc/oratab`が存在するか、Oracle プロセスモニター (`pmon`) プロセスが実行されていることを確認します。 + Windows ホストの場合は、Oracle レジストリエントリ`HKLM\SOFTWARE\Oracle`が に存在するか、`oracle.exe`プロセスが実行されていることを確認します。 ## SNMP のトラブルシューティング **検出ツール VM にアクセスする** + 検出ツール VM にログインし、vCenter でリモートコンソールを開きます。 + ユーザー名: discovery + パスワード: password **SNMP ツールのインストール (必要な場合)** + `sudo yum install net-snmp-utils -y` **Linux サーバーへの SNMP 接続をテストする** 1. `snmptable -v 2c -c .1.3.6.1.2.1.6.13.1` 1. 例: ``` #SNMPv2c: snmptable -v 2c -c public 192.168.1.100 .1.3.6.1.2.1.6.13.1 #SNMPv3 (with authentication): snmptable -v 3 -u -a MD5 -A 192.168.1.100 .1.3.6.1.2.1.6.13.1 #SNMPv3 (with privacy): snmptable -v 3 -u -a MD5 -A -x DES -X 192.168.1.100 .1.3.6.1.2.1.6.13.1 ``` ## ネットワーク収集エラー ### パスワードを読み取るにはターミナルが必要です **エラー**: ``` ss command failed on : sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper sudo: a password is required ``` ss コマンドは、ユーザーパスワードの入力を求めます。設定された ssh ユーザーは sudoers グループに属し、ss/netstat コマンドのパスワードレス sudo で設定する必要があります。パスワードレス sudo を設定するには: 1. 新しい sudoers ファイルを作成します。 ``` sudo vi -f /etc/sudoers.d/ ``` 1. 行を追加します。 ``` ALL=(ALL) NOPASSWD: /usr/sbin/ss, /usr/bin/netstat ``` 1. この変更後、 `sudo ss -tnap`と を実行する`sudo netstat -tnap`と、パスワードの入力を求められることなく実行されます。 ### sudo なしで実行されたネットワークコレクション **検出されたインベントリ**ページに次の警告が表示された場合: ``` Network collection ran without sudo. Process-level connection data may be missing. ``` この警告は、SSH ユーザーアカウントにターゲットサーバーでの sudo アクセスがないことを示します。sudo を使用しない場合、検出ツールは引き続きネットワーク接続データを収集できますが、どのプロセスが各接続を所有しているかを判断することはできません。完全なプロセスレベルの接続データを収集するには、SSH ユーザーがターゲットサーバーで sudo アクセスを持っていることを確認します。 ## OS メトリクス収集エラー ### Linux サーバーのサーバー UUID がない 検出ツールが Linux サーバーのサーバー UUID を収集できない場合 (空または欠落と表示）、それらのサーバー用に設定された SSH 認証情報に sudo 権限があることを確認します。ツールは `dmidecode`を使用してサーバー UUID を読み込みます。がインストールされ`dmidecode`ていない場合、ツールは の読み取りにフォールバックするため`/sys/class/dmi/id/product_uuid`、sudo アクセスも必要です。sudo がない場合、どちらのメソッドも UUID を取得できません。 **解決策:** 検出ツールに提供された SSH ユーザーアカウントに、ターゲット Linux サーバーに対する sudo アクセスがあることを確認します。 ## 検出されたインベントリのアクセスの問題 認証情報の欠落やアクセス拒否などのメッセージが**サーバーコレクションステータス**に表示される場合: 1. 検出されたサーバーのテーブルでサーバーを選択します。 1. アクセス**認証情報の管理** 以下を選択できます。 1. 認証情報の選択ドロップダウンから代替**認証情報を選択します**。 1. **新しい認証情報を使用して**新しい認証情報を指定するを選択します。 1. [**保存**] します。 変更を保存した後、検出ツールは接続を再試行します。 ## SSH キー認証のトラブルシューティング **検出ツールからの SSH キー接続のテスト** SSH キー認証が失敗した場合は、検出ツールからターゲットサーバーへの接続を確認します。 1. 検出ツールにログインします (vSphere コンソールまたは SSH 経由で Linux ホストにログインします）。 1. プライベートキーを使用して SSH 接続をテストします。 ``` ssh -i /path/to/private_key -o StrictHostKeyChecking=no @ ``` 1. 接続が成功した場合、問題はキーが検出ツールにアップロードされた方法にあります。キーを再アップロードし、ユーザー名が一致していることを確認します。 1. 接続が失敗した場合は、次の表のエラーメッセージを確認してください。 | エラーメッセージ | 原因 | 解像度 | | --- | --- | --- | | Permission denied (publickey) | パブリックキーがターゲットサーバーの authorized\_keys ファイルにないか、ユーザー名が間違っています。 | 正しいユーザーのために、ターゲットサーバーの \~/.ssh/authorized\_keysにパブリックキーを追加します。ファイルアクセス許可の確認: chmod 700 \~/.ssh && chmod 600 \~/.ssh/authorized\_keys。 | | Connection timed out after 20s | ポート 22 は検出ツールから到達できません。 | 検出ツールとターゲットサーバーの間でポート 22 が開いていることを確認します。ファイアウォールとセキュリティグループを確認します。 | | Connection refused | SSH サービスはターゲットサーバーで実行されていません。 | SSH サービスを起動します: sudo systemctl start sshd。 | | Invalid SSH key for credential '{{name}}' | キー形式がサポートされていないか、キーデータが破損しているか、パスフレーズがないか、正しくありません。 | キー形式が PEM、OpenSSH、または PKCS\#8 形式の RSA、ECDSA、または Ed25519 であることを確認します。キーが暗号化されている場合は、パスフレーズが正しいことを確認してください。 | ## Linux インストーラのトラブルシューティング **ポート 5000 は既に使用されています** **症状:** 検出ツールサービスはインストール後に起動しません。 **解決策:** ポート 5000 を使用してプロセスを特定して停止します。 ``` sudo ss -tlnp | grep :5000 ``` 競合するプロセスを停止し、検出ツールを再起動します。 ``` sudo ./AWS-Transform-discovery-tool.sh start ``` ## 一般的なエラーメッセージ この表は、一般的なエラーメッセージとその説明を示しています。 | メッセージ | ロケーション | 説明 | | --- | --- | --- | | パスワードはすでに作成されています | パスワードの作成ページ | 2 人のユーザーが同時にパスワードを作成する場合のレース条件。更新 | | エクスポートに失敗しました | インベントリページ | ログの再試行または送信 | | オンデマンドコレクションはすでに進行中です | インベントリページ | 2 人のユーザーが同時に手動収集を開始したときのレース条件。現在の手動収集が終了したら、もう一度試してください。 | | Command timed out after 60s | サーバーコレクションのステータス | ターゲットサーバーのコマンドが 60 秒以内に完了しませんでした。これは、負荷の高いサーバーで発生する可能性があります。コレクションを再試行するか、ターゲットサーバーの負荷を調査します。 | | 1 つ以上の認証情報に不明な UUIDsが含まれている | OS アクセスページ | 2 人のユーザーが同時に OS 認証情報を編集する場合のレース条件。もう一度試してください | | 無効なパスワード | サインインページ | ログイン用のパスワードが正しくありません。管理者に問い合わせるか、お問い合わせください | | セッションの有効期限が切れています。再度ログインしてください。 | サインインページ | セッションがタイムアウトしました。再度ログインする必要があります | | 内部エラーが発生しました | さまざまなページ | ログの再試行または送信 |