このページで
トラブルシューティング
ログ
トラブルシューティングについては、一般的に以下のログを確認すると便利です。
/var/log/apache/netrounds_access.log:Control Center Web インターフェイスに対して行われたすべての HTTP リクエスト。/var/log/apache/netrounds_error.log: Control Center Web GUI に対する HTTP リクエストに関して Apache から報告されたエラー。Control Center バックエンドからのコンソール出力もこのファイルにあります。デフォルトでは、すべてのログ記録はコンソールによって行われます。/var/log/syslog:一般的なシステム ログ。/var/log/mail.log:電子メール サーバー のログ。dmesg:カーネル ログ
また、回線を変更して追加の /etc/netrounds/netrounds.conf ログインを有効にすることもできます。
LOGGING['handlers']['console']['level'] = 'ERROR'
宛先
LOGGING['handlers']['console']['level'] = 'DEBUG'
Paragon Active Assuranceコール実行者のロギングを表示するもう1つの方法は、ユーティリティを使用することです journalctl 。
journalctl -u netrounds-callexecuter
詳細については、 journalctl こちらをご覧ください: www.digitalocean.com/community/tutorials/how-to-use-journalctl-to-view-and-manipulate-systemd-logs。
ログのより詳細なリストについては、「運用ガイド」の章「 システムの監視」を参照してください。
テスト・エージェント・ローカル・コンソールでのルート・シェル・オプション
テストエージェントのルートシェルにログインすることで、Paragon Active Assuranceのガイダンスに基づく追加のトラブルシューティングを実行できます。これは、テストエージェントのローカル管理コンソールから行われます。
ローカルコンソールへのアクセス方法は、「テストエージェント」>「ローカルコンソールからテストエージェントを設定する」のアプリ内ヘルプで説明されています。
- ユーティリティに移動し、ルート シェルを選択します。
- パスワード
onlyfordebugaccessでログインします。
ルート シェル プロンプトが表示されます。
root パスワードは、 コマンドを使用して root シェル内で passwd 変更できます。または、ローカル・コンソールの root パスワード変更 オプションを使用して、これを行うことができます。
ルート シェルでテスト エージェントを変更した場合、テスト エージェントに誤動作が発生したり、保証が無効になったりする可能性があります。不明な場合は、続行する前に必ずジュニパーのスタッフにご相談ください。
その後に続くサブセクションでは、特定の問題に対処します。
問題: ライセンスの適用が失敗する
推奨されるアクション:
-
まず、ライセンス サービスの再起動を試してみてください。
sudo systemctl restart netrounds-license-daemon
-
それが役に立たない場合は、「運用ガイド」の章 「システムからのライセンスの削除」の説明に従って、すべてのライセンスをワイプして再適用できます。
問題: サービスにアクセスできません
推奨されるアクション:
-
サービスステータスを確認するには、次のコマンドを使用します。
sudo systemctl status "netrounds-*" openvpn@netrounds sudo systemctl status apache2 openvpn@netrounds
-
ホスト名が正しいIPに解決されていることを確認します。例えば
dig、 またはping -
でリスニングポートを確認する
netstat -lan
-
ネットワークトラフィックを確認する
tcpdump
問題: データの収集なし
- 考えられる原因: NTP 時刻同期の問題。これにより、サーバー生成の結果ビューにタイム オフセットが発生するため、これらのビューに結果が表示されるまでしばらく時間がかかる場合があります。
- 考えられる原因: 空きディスク容量なし。
問題: データ収集が遅い、またはデータ損失が発生する
- 考えられる原因: テストとモニターがキューイングを行い、データ収集が遅れます。
コマンドを実行します。
ncc status
キューの scheduled_call_latency長さを示す 、 の値を確認します。詳しい情報と推奨される救済策については、運用ガイド、システム のチューニングの章、「Control Center」を参照してください。
問題: ncc migrate コマンドが失敗する
- 考えられる原因: ズーキーパーがダウンしました。
コマンドが ncc migrate 失敗し、「Kafkaトピックを作成できません」というエラーメッセージが表示された場合、これはControl Centerが Zookeeperサーバープロセスを開始できないことが原因である可能性があります。Kafkaは Zookeeperに依存しており、正しく動作するためには動作している必要があります。
特定の Zookeeper ファイルが破損し、Java EOF 例外が発生する既知の問題があります。これのログを確認するには、次のコマンドを実行します。
sudo tail -n 100 /var/log/syslog
Zookeeperに関連するエントリーを探 ERROR します。
2021-02-20 18:55:13,302 - ERROR [main:ZooKeeperServerMain@64] - Unexpected exception, exiting abnormally java.io.EOFException
この問題を解決するには、フォルダー内にあるサイズ 0 のすべてのファイルを /var/lib/zookeeper/version-2 削除します。まず、これらのファイルを識別します。
/var/lib/zookeeper/version-2# du -sh * 0K log.1 8.0K log.1dd 8.0K log.210 ...
次に、破損したファイルまたはファイルを削除します。
sudo rm /var/lib/zookeeper/version-2/log.1
最後に、Zookeeperを再起動します:
sudo systemctl restart zookeeper
問題: サービス障害
- 考えられる原因: Kafkaがダウンしました。これは、Zookeeperの問題、またはシステムのメモリ不足が原因である可能性があります。
このような場合、Kafkaを利用しているサービスも失敗し、Kafkaがオンラインに戻るまで再起動しようとします。
たとえば、netrounds-ta3-compat サービスに障害が発生した場合、テスト エージェント アプリケーションは Control Center に登録できません。
Kafkaが次のコマンドで実行しているかどうかを確認できます。
sudo systemctl list-units --type=service | grep kafka
Kafkaがオフラインになった場合、
journalctl -u netrounds-test-agent-gateway.service
は、以下のようなエントリーを返します。
Oct 17 11:17:05 example.com test-agent-gateway-service[23009]: {"level":"info","service":"test-agent-gateway-
service","host":"example.com","src":"core","time":"2020-10-17T11:17:05.429473575Z","caller":"/app/cmd/server/
Oct 17 11:17:06 example.com systemd[1]: netrounds-test-agent-gateway.service: Main process exited, code=exited, status=1/FAILURE
Oct 17 11:17:06 example.com systemd[1]: netrounds-test-agent-gateway.service: Unit entered failed state.
Oct 17 11:17:06 example.com systemd[1]: netrounds-test-agent-gateway.service: Failed with result 'exit-code'.
Oct 17 11:17:07 example.com systemd[1]: netrounds-test-agent-gateway.service: Service hold-off time over, scheduling restart.
Oct 17 11:17:07 example.com systemd[1]: Stopped Netrounds TA3 Connection Service.
問題: Kafkaエラー "開いているファイルが多すぎます"
- 詳細な説明: Kafkaは、数秒が経過した後、再起動とクラッシュを繰り返します。ジャーナル・ログでは、Kafka はエラーのあるスタックトレースを表示します
Too many open files。 - 原因： Kafka が使用できるファイル記述子の数を制御する既定の設定は低すぎます。許容される数は最初は十分ですが、しばらくすると小さすぎる場合があります。
解決するには、
-
Control Center にログインして実行する
sudo systemctl edit kafka.service
-
エディタが開きます。次の行を挿入します。
[Service] LimitNOFILE=65536
ファイルを保存して終了します。
Kafkaが正常に開始して正常に動作するようになりました。
問題: テスト エージェントは正常に登録されましたが、オンラインになりません(ステータス アイコンが赤いまま)
- 考えられる原因: ネットワークでは、暗号化されたVPN接続の確立は許可されていません。テストエージェントとコントロールセンター間のファイアウォールの設定とログを確認してください。
詳細な説明:
登録は HTTPS 経由で行われ、登録後の接続設定は同じポートで OpenVPN を使用して行われます。これにより、ネットワークが登録を許可するが、接続試行は許可されない場合があります。
- 考えられる原因: テスト エージェントと Control Center のクロックが同期していません。両方の当事者がNTPを正しく設定していること、クロックがNTPサーバーと同期していること、そしてNTPサーバーのクロックも同期していることを確認してください。
詳細な説明:
テスト エージェント クロックが遅れている場合、テスト エージェントの登録後、Control Center によって署名されたテスト エージェントの TLS 証明書は、テスト エージェントのクロックが Control Center クロックに従って署名された時刻に達するまで、テスト エージェントの視点から無効になります。その時点まで、テスト エージェントは証明書を受け入れず、オフラインのままになります。
TLS 証明書は、Control Center のインストール時に生成されます。この時点でクロックが正しくない場合、証明書を再生する必要があります。また、すべてのテストエージェントの再登録も必要です。以下の手順に従います。
-
Control Center クロックが同期していることを確認します。
ntpq -np
-
古い証明書を削除します。
rm /var/lib/netrounds/openvpn/*
-
新しい証明書を生成します。
dpkg-reconfigure netrounds-probe-login
-
各テスト エージェントを別の名前で再度登録します。
問題: TimescaleDBデータの増分バックアップにより、ディスクが不足している
詳細な説明:
下でファイルが継続的に作成されているため、ディスク容量が不足している
/var/lib/netrounds/rrd/timescaledb/pgbackrest/repo/archive/paa-metrics/
これは、TimescaleDBの増分バックアップがデフォルトで有効になっているためです。
解決するには、
-
ファイル
/var/lib/netrounds/rrd/timescaledb/data/postgresql.confで、 を設定します。archive_mode = off
バックアップをオフにします
-
サービスを再起動します。
netrounds-timescaledbsudo ncc services restart netrounds-timescaledb
ジュニパーテクニカルサポートへのお問い合わせ
ジュニパーのテクニカルサポートにお問い合わせの場合は、support.juniper.net/support/requesting-support でチケットを提出 してください。チケットで、コマンド実行から生成されたファイルをアップロードしてください
ncc generate-troubleshooting-report
ファイルはユーザーのホームディレクトリ()にあります。/home/<username>