Shazzam フェーズのトラブルシューティングIssue このナレッジ記事では、ディスカバリーの Shazzam フェーズでのトラブルシューティング方法と、Shazzam フェーズで見られる問題の解決方法について説明します。 ディスカバリーは Shazzam ポートスキャンに次のように反応します。 WMI、SSH、または SNMP 経由で通信するポートについて、ディスカバリーが OPEN の状態の IP アドレスを検出すると、ディスカバリーは Shazzam の戻り値に IP アドレスをリストします (result="open")。ディスカバリーがポートから応答を受信しない場合、Shazzam からの戻り値に IP アドレスはリストされません。ディスカバリーがスキャンから接続を拒否する応答を受信すると、ディスカバリーは Shazzam の戻り値に IP アドレスと結果 (result="refused") をリストします。 症状 一部のデバイスを検出できない特定のタイプのデバイス (SNMP/SSH/WMI) を検出できない一部の SNMP デバイスを検出できない一部の LPS デバイスを検出できない特定のネットワークセグメントまたはネットワーク全体の情報が転送されないエラー TCP_CONNECTION_FAILURE java.net.SocketException：利用できるバッファースペースがありません検出されるデバイスの数が一貫しないShazzam の完了に時間がかかる ビデオチュートリアル：失敗したディスカバリーのトラブルシューティング：スキャンフェーズ ResolutionShazzam が一部のデバイスを検出できない ネットワーク接続の問題である可能性があります。そのデバイスタイプに対し、「Shazzam プローブ、ポートプローブ、プロトコル」ドキュメントのリストに記載された、ディスカバリーが使用するポートがブロックされていないことを確認してください。 Shazzam が特定のタイプのデバイス (SNMP/SSH/WMI) を検出できない ネットワークの問題ではない場合は、まず port_probe_spec の Shazzam 出力ペイロードを確認し、ポートがスキャンされていることを確認します。スキャンされていない場合は、スケジュールの動作を確認します。詳細については、ディスカバリー動作についてのドキュメントを参照してください。 また、ポートプローブが優先プロパティでない可能性もあります。詳細については、選択的ポートプローブスキャンおよびポートプローブについてのドキュメントページを参照してください。 Shazzam が一部の SNMP デバイスを検出できない 上記ソリューションが機能しない場合は、SNMP を検出するために SNMP デバイスの認証情報が必要です。必要な SNMP 認証情報をデバイスに追加します。 SNMP デバイスの認証情報が既に追加されているのにデバイスが検出されない場合は、ディスカバリースケジュールがどの SNMP バージョンを検出するよう設定されているかを、[使用した SNMP バージョン] フィールドで確認してください (デフォルトは v1/v2)。SNMP v1、v2、v3 を試行するには、[使用した SNMP バージョン] を [すべて] に設定します。 注意：初期設定では、Shazzam はコミュニティ文字列「public」を試行します。一部の SNMP デバイスではこれがデフォルトとなっている場合があり、そのようなデバイスは discovery_credentials に SNMP 認証情報がなくても正常に検出されるかもしれません。ただし、ほとんどの SNMP デバイスでは、正常に検出するために SNMP 認証情報を discovery_credentials に追加する必要があります。 Shazzam が一部の LPS デバイスを検出しない デバイスタイプのポートが開いていて、そのデバイスでサービスが動作していることを確認します (WMI サービス、SSH サーバーなど)。 Shazzam には微調整が必要なプローブパラメーターがあります。例えば、Shazzam が SSH デバイスを検出しない場合、GenericTCP_waitForConnectMS と BannerTCP_waitForConnectMS の待機時間を延長する必要があるかもしれません。詳細については、「Shazzam プローブパラメーターとペイロードサイズの構成」ドキュメントページを参照してください。 shazzam_chunk_size を 100 からさらに小さい数値に減少させることもできます。 MID サーバーが特定のネットワークセグメントまたはネットワーク全体の情報を変換しない PING、TRACEROUTE、TELNET、および SNMP スキャンツールを使用してネットワーク接続を確認します。 ディスカバリーが使用している MID サーバーがネットワークの目的のセグメントに到達できることを確認してください。「MID サーバーの IP アドレス範囲の設定」ページを参照してください。 エラー TCP_CONNECTION_FAILURE java.net.SocketException：利用できるバッファースペースがありません (最大接続数に到達している場合あり) マルチスレッド Shazzam が原因である可能性があります。「シングルスレッド Shazzam とマルチスレッド Shazzam の比較」セクションを参照してください。 検出されるデバイスの数が一貫しない マルチスレッド Shazzam では、特定の時間にポートスキャン数が増加します。一部のネットワークセキュリティデバイスやアプライアンスがこれを悪意のあるものとみなして、ポートスキャンをブロック/スロットルする場合があります。これにより、検出される IP の数が少なくなる可能性があります。「シングルスレッド Shazzam とマルチスレッド Shazzam の比較」セクションを参照してください。 一部の MID サーバーで Shazzam の完了に時間がかかる これは、MID サーバーのキーストアが無効になった場合に発生する場合があります。キーストアが無効になると、MID サーバーがインスタンスから認証情報を収集できなくなります。これにより、Shazzam の SNMP スキャナーは検出された IP ごとに新しい認証情報のロードを試行します。これはコストの高い操作です。これにより他のスキャナースレッドもロックされ、Shazzam の所要時間が大幅に長くなります。この現象が発生した場合、エージェントログには次の情報が含まれます。 ConcurrentPortScannerEngine-3:<ecc_queue_sysId> SEVERE *** ERROR *** MID Server encryption keys do not match and are no longer valid. To restore proper functionality, invalidate and re-validate the MID Server.ConcurrentPortScannerEngine-3:<ecc_queue_sysId> SEVERE *** ERROR *** An error occurred while decrypting credentials from instancecom.snc.automation_common.integration.exceptions.AutomationIOException: No key pair found for DefaultSecurityKeyPairHandleat com.service_now.mid.keypairs.provider.standard.StandardKeyPairsProvider.decrypt(StandardKeyPairsProvider.java:182)at com.glide.util.MIDServerInfoPayloadDecrypter.decryptPayload(MIDServerInfoPayloadDecrypter.java:30)at com.service_now.mid.creds.provider.standard.StandardCredentialsProvider.loadCredentials(StandardCredentialsProvider.java:317)at com.service_now.mid.creds.provider.standard.StandardCredentialsProvider.load(StandardCredentialsProvider.java:287)at com.service_now.mid.creds.provider.standard.StandardCredentialsProvider.loadIfNecessary(StandardCredentialsProvider.java:299)at com.service_now.mid.creds.provider.standard.StandardCredentialsProvider.iterator(StandardCredentialsProvider.java:171)at com.service_now.mid.probe.shazzam.scanners.SNMP.getCredsIterator(SNMP.java:383)at com.service_now.mid.probe.shazzam.scanners.SNMP.sendSpamTaps(SNMP.java:283)at com.service_now.mid.probe.shazzam.scanners.SNMP.sendFirstTap(SNMP.java:252)at com.service_now.mid.probe.shazzam.scanners.SNMP.nextPhase(SNMP.java:199)at com.service_now.mid.probe.shazzam.PortScannerEngine.run(PortScannerEngine.java:70)at com.service_now.mid.probe.shazzam.ConcurrentPortScannerEngine.run(ConcurrentPortScannerEngine.java:35)at java.base/java.lang.Thread.run(Thread.java:834) ソリューションは次のとおりです。 MID サーバーのリキー シングルスレッド Shazzam とマルチスレッド Shazzam の比較 パラメーター mid.shazzam.threads と mid.shazzam.max_scanners_per_thread は Orlando で追加されました。パラメーター mid.shazzam.threads は Shazzam が同時に使用するスレッド数を指定し、mid.shazzam.max_scanners_per_thread は各 Shazzam スレッドが同時に処理するスキャナー数を指定します。いずれかのパラメーターを 0 に設定すると、Shazzam マルチスレッド最適化が無効になります。Orlando より前のリリースから Orlando 以降のリリースにアップグレードした後にディスカバリーのポートスキャンフェーズで問題が見つかった場合は、シングルスレッド Shazzam に戻してお試しください。Related Linksディスカバリーフェーズ Shazzamペイロードサイズのために Shazzam プローブによってノードのメモリ不足が発生するShazzam プローブは 、ディスカバリーの続くフェーズからのプローブと同じ優先度「標準」で実行されるため、それらのプローブ背後の ECC キュー出力内でスタックする可能性がある