このページでは、NewRelicのネットワーク監視で使用されるktranslateコンテナを管理するためのオプションの概要を説明します。
コンテナの要件
ktranslate コンテナイメージには、以下のリソースをお勧めします。
ディスク
- 100MBの利用可能なディスクスペース
CPU
- SNMPポーリング/トラップ収集。約1,000台のデバイスに対して1CPUコアを使用
- デバイスのフロー収集。約2,000フロー/秒（fps）ごとに1CPUコアを使用
- Syslogメッセージの収集。1秒間に約2,000件のメッセージに対して1つのCPUコアを使用
メモリー
- ktranslate は、一般的にメモリリソースによって制約されることはありません。ホストのメモリ量は、実行する予定のアプリケーション/コンテナの種類によって決定します。一般的には、 AWS t2.micro のように、1つのvCPUと1.0GBの利用可能なRAMを持つ小さなイメージサイズで成功しています。
ヒント
KTranslate コンテナ イメージは、一度に 1 つの「ジョブ タイプ」を実行します。たとえば、SNMP ポーリングとトラップ コレクション用にデプロイされたコンテナは、フロー コレクションには使用されません。さらに、フロー コレクション用にデプロイされたコンテナは、コンテナごとに 1 つの-nf.sourceタイプに制限されています。これは、単一の Docker ホストに複数のコンテナを同時にデプロイすることが一般的であることを意味します。また、共通の構成ファイルを共有することもできますが、その必要はありません。
コンテナの更新
ktranslate コンテナ・イメージを最新に保つことは、最新のアップデートを受信し、開発ライフサイクル中に適用された様々なバグフィックスによって一般的な問題を解決するための良い習慣です。コンテナを再デプロイする際には、常に最新のイメージを使用することをお勧めします。
以下のいずれかを実行して、利用可能な最新のコンテナイメージを引き出します。
既存のコンテナのIDと名前を収集します。
bash$docker ps -a --filter ancestor=kentik/ktranslate:v2 --format "{{.ID}} - {{.Names}}"出力例。
3297b134a352 - ktranslate-snmp4962a854b386 - ktranslate-sflow既存の容器の撤去
bash$docker rm -f $CONTAINER_IDktranslate コンテナを、 SNMP, flow data, syslog collection のいずれかからデプロイした元の設定を使用して再デプロイします。
重要
ktranslateが使用する構成ファイルは、実行時にコンテナーに適用されます。このファイルを変更するには、統合された検出ジョブを使用する場合を除いて、実行中のコンテナーを削除して再起動し、編集を適用する必要があります。
コンテナのランタイムオプション
以下は、 ktranslate コンテナイメージのDockerランタイム中に利用できる様々なオプションです。
オプション名 | タイプ | 必須 | 説明 |
|---|---|---|---|
| 旗 | ✓✓ | 実行時にオプションとして渡されたDockerホストからのボリュームマウントに基づいて、Dockerコンテナ上の |
| 旗 | ✓✓ | ktranslateがデータを送信するNewRelicアカウントID。 |
| 旗 | ktranslateのデフォルトの情報ログレベルを上書きします。使用可能なオプションは、 | |
| 旗 | コンテナーをSNMP検出モードでセットアップして、単一の検出ジョブを実行し、提供されたYAML構成ファイルを更新して、終了するために使用されます。 | |
| 旗 | 一定の間隔で実行するようにスケジュールされたSNMPポーリングコンテナ内に統合された検出ジョブを設定するために使用されます。この設定により、検出ジョブが実行され、提供されたYAML構成ファイルが更新され、SNMPポーリングコンテナーでSNMP収集スレッドが再起動され、検出されたデバイスのコンテナー全体を破棄/再起動する必要がなくなります。 | |
| 旗 |
| |
| 旗 | オンデマンドでターゲットデバイスをポーリングするようにコンテナを設定するために使用します。 | |
| 旗 | DockerログをktranslateからNewRelicLogsに転送します。 | |
| 旗 | ktranslateからNewRelicにヘルスメトリックを転送します。 | |
| 旗 | Dockerログのコンテナ名に追加され、NewRelicLogのさまざまなコンテナからログを分離できるようになります。 | |
| 旗 | ktranslateのリージョナルAPIエンドポイントを設定して、テレメトリをNewRelicに転送します。オプションは、 | |
| 旗 | 大量のデータを処理できます。送信されるネットワークフローデータの毎秒2,000フロー（fps）ごと、監視対象のSNMPデバイス1,000ごと、またはコンテナによって収集される毎秒2,000のsyslogメッセージごとに1つのCPUコアを使用することをお勧めします。デフォルトは | |
| 旗 | フローがNewRelicイベントに渡されるデフォルトのサンプルレート値を変更します。これにより、デバイスのフローサンプルレートのローカル構成が高速化されることはありませんが、速度が低下する可能性があります。これを | |
| 旗 | ネットワークパケットの処理に使用されるワーカーの数を上書きします。送信されるネットワークフローデータの毎秒4,000フロー（fps）ごとに1つのワーカーを使用します。デフォルトは | |
| 旗 | 着信フローパケットのリスニングポートを上書きします。デフォルトは | |
| 旗 | ✓ （フロー容器の場合） | このコンテナが処理するフローのタイプを設定します。オプションは、 |
| 旗 | ランタイム中にオプションとして渡されたDockerホストからのボリュームマウントに基づいて、Dockerコンテナ上の アプリケーションマップ ファイルへのパスを設定します。 | |
| 旗 | IPアドレスのDNS解決中に使用するktranslateの | |
| 議論 | ✓ （フロー容器の場合） | この引数は、次のフラグを静的に設定します： |
| 議論 | ✓ (SNMPコンテナの場合) | この引数は、次のオプションを静的に設定します： |
| 議論 | ✓ (syslogコンテナの場合) | この引数は、次のフラグを静的に設定します： |
| 環境変数 | ✓✓ | Docker ランタイム中に New Relic を保持するために使用する必要がある環境変数 ktranslate が データを New Relic API に送信するため。 例: |
| 環境変数 | Dockerランタイム中にktranslateをセットアップして、プロキシ経由でNewRelicにデータを送信するために使用できる環境変数。例： | |
| 環境変数 | ktranslateの SNMPv3構成でAWS Secrets Managerを使用するように設定するために、Dockerのランタイム中に使用できる環境変数です。ユーザーを認証するためのクレデンシャルの一部として使用されるAWSアクセスキーを指定します。 | |
| 環境変数 | ktranslateの SNMPv3構成にAWS Secrets Managerを使用するように設定するために、Dockerランタイム中に使用できる環境変数です。ユーザーを認証するためのクレデンシャルの一部として使用されるAWSシークレットキーを指定します。 | |
| 環境変数 | ktranslateの AWS Secrets Managerを使用するためのSNMPv3構成をセットアップするために、Dockerのランタイム中に使用できる環境変数です。このプロファイルを使用してリクエストされたコマンドのリクエストを送信するAWSリージョンを指定します。 | |
| 環境変数 | Dockerランタイム中にktranslateの |