可用性监测故障排查¶
Synthetic テスト自建节点管理 Name or service not known¶
問題の概要¶
【セルフホストノード管理】にて Name or service not known エラーが発生します。
エラーの原因¶
- 一部のクラウドベンダーのロードバランサーの問題により、サービスが自身の ingress のドメイン名にアクセスできない場合があります。
操作手順¶
1. Launcher を開き、アプリケーション設定を変更する¶
Launcher サービスにアクセスし、右上の アプリケーション設定を変更 をクリックします。
2. パラメータを追加する¶
「名前空間: forethought-core」- 「core」に internal_server パラメータを追加します。
3. 設定変更後、関連サービスを自動再起動する¶
設定変更後に関連サービスを自動再起動するオプションをオンにします。
Synthetic テストエクスプローラーのデータ欠落¶
問題の概要¶
このセクションでは、Synthetic モニタリングのエクスプローラーでデータが欠落する問題のトラブルシューティング方法について説明します。
フローチャート¶
トラブルシューティングの手順¶
ステップ1: 設定の確認¶
-
まず、設定ファイルが正しいことを確認します。
- forethought-core Namespace の
coreという名前の ConfigMap 設定が正しいことを確認します。
# 云拨测服务 DialingServer: # 拨测服务中心的地址配置 use_https: true port: 443 ## 实际环境に合わせて変更 host: 'dflux-dial.guance.com' ## 实际环境に合わせて変更 timeout: 10dflux-dial.guance.com は公式のSynthetic テストセンターです。プライベートなSynthetic テストセンターに切り替える場合は、ingress 設定を確認してください。
- utils Namespace の
dialtesting-configという名前の ConfigMap 設定が正しいことを確認します。
global: enable_inner_api: false stats_on: 256 listen: ":9538" sys_external_id: "ak_R5Fxxxxxxxxx8Go8-wksp_system"sys_external_id は、後述の aksk テーブルの uuid + external_id で構成されます。
- forethought-core Namespace の
-
MySQL df_dialtesting データベースの
akskテーブルのデータを確認します。id uuid accessKey secretKey owner parent_ak external_id status version createAt updateAt 1 ak_R5Fxxxxxxxxx8Go8 asjTxxxxxxxxxxxxxXMJ zeiX99gxxxxxxxxxxxxxxxx2h5 system -1 wksp_system OK 0 1,686,218,468 1,686,218,468 -
df_core データベースの main_config テーブルで
KeycodeがDialingServerSetのデータと一致することを確認します。id keyCode description value 6 DialingServerSet 拨测服务配置 "{\"ak\": \"asjTxxxxxxxxxxxxxXMJ\", \"sk\": \"zeiX99gxxxxxxxxxxxxxxxx2h5\", \"dataway\": \"http://deploy-openway.dataflux.cn?token={}\"}" -
launcher の
dialServiceAKモジュールのデータと比較して、一致することを確認します。操作手順: launcher 画面にログイン ---> 右上のボタン ---> その他
対応関係表:
aksk テーブルのキー名 launcher その他設定の dialServiceAK モジュールのキー名 uuid ak_id accessKey ak secretKey sk 一致しない場合は、データベースの値を基準に修正してください。
-
Synthetic テストセンターを切り替えたり、変更を行った場合は、launcher ページで再度ライセンスをアクティベートし、情報を再書き込みする必要があります。
ライセンス設定を変更する必要はなく、そのままアクティベートしてください。
データゲートウェイアドレスがサンプルと完全に一致する形式であることを確認してください。token={} は変更する必要はありません。
ステップ2: 通信の確認¶
Synthetic テストノードのマシンで ping コマンドを使用して、Synthetic テストセンターおよび DataWay と通信できることを確認します。
ステップ3: データが報告されているか確認する¶
Synthetic テストノードのマシンで以下のコマンドを実行し、データが報告されているか確認します。
- I/O 通信が正常かどうかを確認します。
sudo datakit monitor -M IO
## DYNAMIC_DW は Synthetic テストセンターのサービスを表します。 Points(ok/total) が一致していれば問題ありません。
┌IO Info───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Cat│ChanUsage│ Points(ok/total)│ Bytes(ok/total/gz) │
│DYNAMIC_DW│ 0/1│ 626 /626 │ 389.392 k/389.392 k(267.603 k) │
│ M│ 0/1│1.7955 M/1.796043 M│560.715703 M/560.880362 M(240.616886 M) │
│ O│ 0/1│ 588.045 k/588.2 k│ 516.475667 M/516.613201 M(37.964566 M)
- input が正常かどうかを確認します。
sudo datakit monitor -M In
## 以下の dialtesting の Feeds と TotalPts が 0 でなければ、データがアップロードされていることを示します。
┌Inputs Info(11 inputs)────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Input│Cat│ Feeds│ TotalPts│Filtered│ LastFeed│ AvgCost│Errors │
│ dialtesting│ L │ 626 │ 626 │ 0 │25 minutes ago│ 0s│ 0 │
│ cpu│ M │ 112.71 k│ 112.71 k│ 0 │ 6 seconds ago│ 237.807?s│ 0 │
ステップ4: ログの確認¶
以下のコマンドを使用して、Synthetic テストノードの DataKit ログを確認し、問題をさらに特定します。