プロファイルは、 ktranslate が収集して New Relic アカウントに送信する SNMP OID を定義します。このドキュメントでは、既存のプロファイルを変更する方法、または新しいプロファイルを作成する方法について説明します。
始めましょう
カスタムプロファイルを作成するか、オープンソースプロファイルの1つを変更することにした場合は、いくつかの重要なツールが必要です。
- Git リポジトリ: これは多くの場合 GitHub ですが、任意のクラウドまたはローカル Git ツールを使用できます。
- これにより、開始点として Kentik SNMP プロファイル コレクションのクローンを作成し、必要に応じて独自の変更や新しいプロファイルを追加できます。
- プロファイルで作業するネットワークデバイスからのSNMPウォーク。詳細については、 SNMPの設定と
snmpwalkの使用に関するドキュメントを参照してください。
ヒント
New Relic は 、 kentik/snmp-profilesの内容に対する直接のサポートを提供しません。 New Relic テクニカル サポートは、問題を提起するためにユーザーをリダイレクトする以外の追加のサポートを提供することはできません。
カスタムプロファイルを非公開で使用する
新しいプロファイルを追加したり、ktranslate に含まれるプロファイルを変更したりする最も効果的な方法は、 Kentik/snmp-profiles リポジトリ の独自のプライベート コピーを作成し、起動時にカスタム プロファイル ディレクトリを Docker コンテナにロードすることです。
ヒント
devices.[deviceName].providerの値は、NewRelicでのエンティティ合成にとって重要です。詳細については、デバイス構成に関するドキュメントを参照してください。
これを行うには、Docker のボリューム マウントを使用して、カスタマイズしたファイルを etc/ktranslate/profiles/ ディレクトリ内の KTranslate コンテナに渡します。これを実現する方法は他にもありますが、この例では、GitHub を使用してローカルでデータをフォークしてクローンを作成する方法を示します。
- ファイルを保持するディレクトリにいることを確認してから、GitHubリポジトリのフォークをDockerホストに複製します。
git clone https://github.com/<YourGitUser>/snmp-profiles.git- SNMPコンテナを起動するために通常使用するコマンドを取得し、
snmp-base.yamlで渡したものの後に2番目のボリュームマウント引数を追加します。
-v `pwd`/snmp-profiles/profiles:/etc/ktranslate/profiles \mountコマンドは、組み込みのプロファイルディレクトリをカスタマイズされたデータに置き換えます。
最終結果は次のようになります。
docker run -ti --name ktranslate-discovery --rm --net=host \--user `id -u`:`id -g` \-v `pwd`/snmp-base.yaml:/snmp-base.yaml \-v `pwd`/snmp-profiles/profiles:/etc/ktranslate/profiles \kentik/ktranslate:v2 \-snmp /snmp-base.yaml \-log_level info \-snmp_discovery=trueヒント
検出コンテナまたはSNMPポーリングコンテナを起動するたびに、必ずカスタムバージョンのプロファイルを渡してください。すべてのSNMPインスタンスセットで一貫して使用しないと、信頼性の低い動作が発生する可能性があります。
ヒント
既存の SNMP プロファイルが不正なデータやその他の破壊的な動作を返している場合、または新しい SNMP プロファイルまたは変更された SNMP プロファイルをリクエストする場合は、 次の手順 に従って snmp-profiles Github リポジトリで問題をオープンしてください。サードパーティ プロジェクト GitHub - kentik/snmp-profiles: SNMP Profiles for ktranslate では、SNMP プロファイルの変更または作成のタイムラインを提供できません。
New Relic アカウントに関連付けられたサービス レベルに応じて、New Relic グローバル テクニカル サポートからケース サポートを受ける資格がある場合があります。当社の グローバル テクニカル サポート サービスに従って、問題が New Relic 製品にあるのか、それとも当社の制御と範囲外にあるものによって引き起こされたのかを判断するために最善を尽くします。当社が解決できないサードパーティ ツールの問題については、商業的に合理的な努力を払って、強化、パッチ、またはその他の機能開発を上流のオープン ソース プロジェクトに提供します。
プロファイルと変更を公に提供する
オープンソース リポジトリとして、新しいプロファイルを作成したり、既存のプロファイルを改善したりするための誰からの貢献も歓迎されます。
- プロファイルの構造に慣れるために、GitHubでこのコメントの多いtemplate.ymlを確認してください。
- GitHubにログインし、 snmp-profilesリポジトリに移動します。
- アカウントに同じ情報のコピーを作成するには、上部にあるフォークボタンをクリックします。
- フォーク内で、ファイルに必要な変更を加えるか、必要に応じて新しいベンダー ディレクトリとプロファイルを作成します。
- プルリクエストを送信する前に、必ずcodebeautifyなどのYAMLバリデーターを介してプロファイルを渡してください。
- 変更が完了したら、 プルリクエストをアップストリームリポジトリに送信します。
New Relic は、サードパーティ リポジトリのプロファイルをレビューするプロセスには関与していません。変更と更新のすべてのリクエストは、Github の問題を通じて Kentik のメンテナーに対処する必要があります。
プロファイルがマージされた直後に、新しいバージョンの Docker イメージをプルし、環境内で新しいコンテナを起動することにより、新しい SNMP プロファイルが自動的に使用可能になります。詳細については、 SNMP 手動セットアップに関するドキュメントを参照してください。
ヒント
フォークを定期的に同期して、アップストリームリポジトリの変更に合わせて最新の状態に保つようにしてください。
実際にプロファイルにはどのような種類の OID を含めるべきですか?
多くの場合、SNMPは大量のデータを提供しますが、そのデータの多くは実用的な情報を提供しません。または、データが提供する価値は非常にまれで影響が少ないため、NewRelicアカウントに持ち込む価値がない可能性があります。
デバイスが期待する機能を実行できなくなる原因となるものがあるかどうかを知らせるデータの収集に焦点を当てたいと考えています。それを基に、これらの機能をどの程度実行しているかを示す測定値を収集する必要があります。
例1： VPNコンセントレーターとして動作しているデバイスの場合、次のような高レベルのシステムメトリックを収集します。
- CPUとメモリの使用率
- ファンの故障などが原因でデバイスがシャットダウンしないようにするためのハードウェアセンサー情報
- 集約された接続とスループットについて教えてくれるOID
例2：利用可能であるが価値が非常に低いデータの例は、ネットワークアプライアンスで実行中のすべてのプロセスを一覧表示するOIDテーブルです。サーバー管理者の観点からすると、これは便利に聞こえるかもしれませんが、これはアプライアンスであるため、通常、その内部で実行されるプロセスを処理する機能や必要はありません。実際には何もできない何百ものアイテムを含むテーブルをポーリングして保存するのは効率的ではありません。