さらなる考慮事項
このセクションでは、レイテンシー測定、サンプリング、データ量、およびデータに関する情報をまとめています。
レイテンシー測定方法
この図は、QoSエージェントからレイテンシーを計算する方法を示しています。
デフォルトのサンプリングレート
以下はデフォルトのサンプリングレートです。変更方法については、カスタム設定セクションを参照してください。
注： 実行中のdockerの設定ファイルを変更した場合は、dockerの再起動（停止、起動）が必要です。
| プロトコル | サンプリングレート |
|---|---|
| TWAMP | 2秒ごと |
| ICMP | 2秒ごと |
| HTTP | 2秒ごと |
| HTTPs | 2秒ごと |
| TCP | 2秒ごと |
| UDP | 2秒ごと |
| TraceRoute | 15分ごと |
| PacketLoss | 5秒ごと |
| Iperf3 | 2時間ごと |
| Lifbe | 10分ごと |
データ量
以下の表は、高負荷構成でのデータ消費量を示しています：
| プロトコル | サンプリング | 時間あたりの消費量 | 日あたりの消費量 | 月あたりの消費量 |
|---|---|---|---|---|
| TWAMP | 30回/分 | 0.1 Mb | 2.4 Mb | 74.4 Mb |
| ICMP | 30回/分 | 0.2 Mb | 4.8 Mb | 148.8 Mb |
| HTTP | 30回/分 | 0.5 Mb | 12 Mb | 372 Mb |
| HTTPs | 30回/分 | 0.6 Mb | 14.4 Mb | 446.4 Mb |
| TCP | 30回/分 | 0.4 Mb | 9.6 Mb | 297.6 Mb |
| UDP | 30回/分 | 0.4 Mb | 9.6 Mb | 297.6 Mb |
その他のプロトコル
| プロトコル | サンプリング | 時間あたりの消費量 | 日あたりの消費量 | 月あたりの消費量 |
|---|---|---|---|---|
| TraceRoute | 4回/時間 | 2.2 Kb | 53 Kb | 1.7 Mb |
| Iperf3 | 12回/日 | 83 Mb | 2 Gb | 62 Gb |
| Lifbe | 6回/時間 | 25.8 Mb | 619.2 Mb | 18.6 Gb |
| PacketLoss | 12回/分 | 4.3 Mb | 104.2 Mb | 3.1 Gb |
データの保存場所
InfluxとGrafanaのデータベースは、アナライザーホスト上でアクセスできます。
| アプリケーション | 保存場所 |
|---|---|
| Grafana | lti_analyzer/grafana/grafana/grafana.db |
| Influx | lti_analyzer/influx/data/* |
バックアップ
バックアップは、単純にファイルを目的の場所にコピーするか、データベースを読み取るプロセスを設定することで実行できます。
ダッシュボードの拡張
追加のダッシュボードを作成できます。詳細については、Latence Technologiesのベンダーにお問い合わせください。
NTPのインストールと設定
次のコマンドでNTPをインストールできます。
sudo apt install ntp # Debian/Ubuntuの場合
sudo yum install ntp # CentOS/RHELの場合
sudo dnf install ntp # Fedoraの場合
インストール後、/etc/ntp.confを編集してNTPサーバーを指定します：
server pool.ntp.org
server time-a-g.nist.gov
driftfile /var/lib/ntp/ntp.drift
特定のサーバーを優先するには、preferキーワードを追加できます：
server 192.168.1.1 prefer
server pool.ntp.org
次にNTPサービスを有効化して起動します：
sudo systemctl enable ntpd
sudo systemctl start ntpd
同期が動作していることを確認するには：
ntpq -p
アナライザーにIPアドレスの代わりにセキュアなDNSを使用する
アナライザーにnginxサーバーを追加してDNSアドレスを使用できるようにする場合は、次の手順に従ってください：
サーバーの作成
必要なもの：
* アナライザーのパブリックIPを指すDNS Aレコード。これはNginxで設定され、アプリケーションサーバーをプロキシします。この例ではdemo.domain.comとします。
* プロキシするアプリケーションサーバーのアドレス。この場合はhttp://127.0.0.1:12021となります。
ステップ1 — Nginxのインストール
sudo apt update
sudo apt install nginx
systemctl status nginx
ステップ2 — サーバーブロックの設定
デフォルトの設定を直接編集するのではなく、新しいサーバーブロックの追加用にカスタム設定ファイルを作成することが推奨されます。nanoまたは好みのテキストエディタを使用して、新しいNginx設定ファイルを作成して開きます：
sudo nano /etc/nginx/sites-available/demo.domain.com
以下のブロックをコピーして設定ファイルに貼り付けます。アナライザーに割り当てたDNS Aレコードで「demo.domain.com」を変更することを忘れないでください。
server {
listen 80;
listen [::]:80;
server_name demo.domain.com;
location / {
proxy_pass http://127.0.0.1:12021;
include proxy_params;
}
}
次に、sites-enabledディレクトリへのリンクを作成して、この設定ファイルを有効にします。Nginxは起動時にこのディレクトリを読み取ります：
sudo ln -s /etc/nginx/sites-available/demo.domain.com /etc/nginx/sites-enabled/
設定ファイルの構文エラーをテストできます：
sudo nginx -t
問題が報告されなければ、Nginxを再起動して変更を適用します：
sudo systemctl restart nginx
TLS/SSL証明書の追加
ステップ1— Certbotのインストール
sudo apt install certbot python3-certbot-nginx
ステップ2 — Nginx設定の確認
上記のチュートリアルに従った場合、/etc/nginx/sites-available/example.comにドメイン用のサーバーブロックがあり、server_nameディレクティブが適切に設定されているはずです。その場合はステップ3に進んでください。
確認するには、nanoまたは好みのテキストエディタを使用してドメインの設定ファイルを開きます：
sudo nano /etc/nginx/sites-available/demo.domain.com
既存のserver_name行を見つけます。次のようになっているはずです：
...
server_name demo.domain.com;
...
そうなっている場合は、エディタを終了して次のステップに進みます。
そうでない場合は、一致するように更新してください。その後、ファイルを保存し、エディタを終了して、設定編集の構文を確認します：
sudo nginx -t
エラーが発生した場合は、サーバーブロックファイルを再度開き、タイプミスや欠落している文字がないか確認してください。設定ファイルの構文が正しくなったら、Nginxをリロードして新しい設定を読み込みます：
sudo systemctl reload nginx
Certbotは正しいserverブロックを見つけて自動的に更新できるようになります。
次に、ファイアウォールを更新してHTTPSトラフィックを許可しましょう。
ステップ3 — SSL証明書の取得
Certbotは、プラグインを通じてSSL証明書を取得するさまざまな方法を提供しています。Nginxプラグインは、必要に応じてNginxの再設定と設定のリロードを処理します。このプラグインを使用するには、次のように入力します：
sudo certbot --nginx -d demo.domain.com
これにより、--nginxプラグインでcertbotが実行され、-dを使用して証明書を有効にするドメイン名を指定します。
初めてcertbotを実行する場合は、メールアドレスの入力と利用規約への同意が求められます。その後、certbotはLet's Encryptサーバーと通信し、証明書を要求しているドメインを制御していることを確認するチャレンジを実行します。
ステップ4 — Certbot自動更新の確認
Let's Encryptの証明書は90日間のみ有効です。これは、ユーザーが証明書の更新プロセスを自動化することを奨励するためです。インストールしたcertbotパッケージは、1日に2回実行され、有効期限まで30日以内の証明書を自動的に更新するsystemdタイマーを追加することで、これを処理します。
systemctlでタイマーのステータスを照会できます：
sudo systemctl status certbot.timer
更新プロセスをテストするには、certbotでドライランを実行できます：
sudo certbot renew --dry-run
エラーが表示されなければ、すべて設定完了です。必要に応じて、Certbotは証明書を更新し、Nginxをリロードして変更を反映します。自動更新プロセスが失敗した場合、Let's Encryptは指定したメールアドレスにメッセージを送信し、証明書の有効期限が近づいていることを警告します。