Inperfoは、主にスイッチとルーターのネットワークインターフェイスの監視を目的としています。 もちろん、たとえば、ネットワーク機器にアクセスできないが、数十または数百のレンタルサーバー（物理または仮想）がある場合、サーバー上のネットワークインターフェイスを直接監視できます。
このサービスは、 物理イーサネットインターフェイスの監視を目的としています。 ちなみに、これにより、誤った設定やその他の問題があるポートチャネルのトラフィックの歪みを確認できます。 他のタスクがあり、他の種類のインターフェイスを監視する必要がある場合は、Observium'aと兄弟（LibreNMS、NetXMSなど）またはSolarWind NPMを使用してください。
サービスを作成する主な目的は、すべての問題のある場所または潜在的に問題のある場所が完全に見えるように、インターフェイス、エラーの読み込みに関するトップを確認することでした。 zabbixやcactiでは、このような動的な画面を作成することは、控えめに言っても問題があります。 さらに、私は、現在の瞬間ではなく、週の歴史でトップになりたいと思っていました-週末、週末の後に負荷が増加し、週末までに負荷が減少する、またはその逆-週末のピークで、平日は負荷が低い、多くのネットワークにとって最良のオプションです。
そして2番目に劣らない重要な目標は、不必要なフリル、複雑さ、音声学のない最小限のインターフェースです。 誰もがそれを好むわけではありません。
サービスは3つの問題を解決します
- ネットワークのボトルネックを示します。 ラッシュアワー時に過負荷になる、配信レベルの過負荷のアップリンクアクセススイッチにすることができます。 または、バックアップまたはmemcachedサーバーへの過負荷ポート。 インターフェイスを内部または外部アップリンクとして個別に割り当てて、個別の上部に表示できます。 すべてのスケジュールは最大限に構築されています-毎週、毎月、年間のスケジュールは平均化されていません。
- ホストおよびデータセンターごとにデータをグループ化し、すべてのデバイスからの上位エラーを表示するために、インターフェース上のエラーを表示します。 ホストとインターフェースのテーブルのエラー-グラフ上の週の合計-1秒あたりのエラー。
- スイッチ上の空きポートとビジーポートの数を監視し、ネットワーク拡張タスクを時間内に解決するのに役立ちます。
そして、それ自体で、インターフェースの名前変更、説明（ifDescr）、インターフェースのステータスの変更など、変更を自動的に追跡します。 唯一の手動作業は、新しいデバイスまたはサーバーをエージェント構成に追加することです。 時間が経つにつれて、自動検出機能が追加されますが、現在のところ追加されていません。
あなたが必要とする場合、Inperfoは間違いなくあなたには適していません：
-CPU /メモリの監視
-hdd、温度、その他のイーサネット以外のものの監視
-マップとネットワーク図を描画する機能
システムコンポーネント
このサービスは、サーバーとエージェントの2つのコンポーネントで構成されています。 エージェントは、インターフェースに関するSNMPデータを収集し、サーバーに送信します。 サーバーは、受信したデータを処理（ソート、rrdファイルなどの更新）し、Webベースのインターフェースを介して表示します。
サーバーの仕組み
サーバーは、ソフトウェアの「標準」セットを備えたdockerコンテナです：nginx / php-fpm / memcached / mysql / rrdtool。 サーバーは、エージェントが5分ごとにデータを送信することを期待しています。 データはデータベースに格納されます-週ごとの履歴は、インターフェイスの負荷とエラーによって保持され、95番目のパーセンタイルと最大/最大平均によって計算されます。 これは、ネットワークをさまざまな「セクション」で「見る」ために行われます-バーストのみを表示する必要があるときに、まれなバーストを発生させたり、その逆を行う必要はありません。
コンテナーデータは、サーバーの更新、バックアップ、および他のホストへの転送を容易にするために、ホストシステムに保存されます。 アップグレードできるコマンドは1つだけです（アイデアはdockerから取られました。https： //get.docker.comを参照してください ）
エージェントはどのように機能しますか？
エージェントは、5分ごとに起動されるドッカーコンテナでもあり、ネットワークデバイスまたはサーバーからインターフェイスに関するSNMPデータを収集します。 これまでのところ、デバイスの更新（ポーリング）の間隔は変更できません。
クライアントは、v2とv3の2つのバージョンのSNMPをサポートしています。
エージェント構成、ログ、および送信されたデータは、ホストシステムに保存されます。 これにより、構成を簡単に編集し、必要に応じてエージェントを他のホストに転送できます。
ユースケース
ネットワーク機器の監視
理想的には、データセンターまたはリモートオフィスごとに1つのエージェントをインストールおよび設定して、エージェントがデータセンター内のデバイスをsnmp経由でローカルにポーリングし、収集したデータをデータセンターの1つまたはどこかにある中央サーバーに送信できるようにする必要がありますクラウド（Amazon、DigitalOcean、Azureなど）。
データセンターが1つあるか、残りのDCへの「クイック」リンクがある場合は、サーバーとエージェントを同じLinuxマシンにインストールするだけで十分です。そこからすべてのネットワークデバイスがポーリングされます。 または、たとえば、すでにサボテンを持っている同じマシン上で-ネットワーク機器でSNMPアクセスを設定する必要はありません（ある場合:)
このスキームの主な欠点：ネットワーク機器へのSNMPアクセスが必要です。
サーバー上のネットワークインターフェイスを監視する
サーバー上のネットワークインターフェイスを監視するには、たとえばansible-playbookを介して、それぞれにsnmpデーモンをインストールする必要があります。 この場合、エージェントの各Linuxサーバーは、1つ以上のネットワークインターフェイスを持つ個別のネットワークデバイスのように見えます。
長所：
- ネットワーク機器にアクセスせずに行うことができます
監視のインストールと設定を非常に簡単に自動化できます
短所：
- ポート容量なし（必要な場合）
- エージェント設定に新しいサーバーを手動で追加する必要があります
混合モード
ここではすべてが明確であり、スイッチ/ルーターとサーバーの両方を一緒に監視できます。エージェントはデバイスのタイプを区別せず、MIBv2データベースからインターフェースに関する情報を取得します。 ちなみに、これはもう1つのマイナスです。インターフェイスに関する情報が「非標準」MIB（たとえば、BTI 7000）から送信されるデバイスがある場合、Inperfoは現時点では機能しません。
性能
「ミドル」ハードウェア（16CPU / 16GB）で最大100デバイス（6000以上のポート）で快適に動作するため、これまでより多くの数の作業を起動して監視する必要はありませんでした。 しかし、各デバイスをポーリングするエージェントは個別のプロセス（フォーク）を作成するため、go-routinesを使用したgolangはこのコードの一部を失い、要求します。 サーバーは、データを受信するときに同様に機能します。
将来のバージョンで追加されるもの
-インターフェイスの最大速度の表示。 1GBリンクを介してプロバイダーに接続している状況では必要ですが、実際には有料チャンネルは少なく、alaは500Mbに制限されています。
-メールによる毎週のトップレベルレポート。
-メール通知。
-Dockerコンテナのアセンブリをサーバーとエージェントに分けます。 小規模ネットワークでは、これが理想的です。 さらに、Webインターフェースを介してホストを追加することもできます。
-パッケージ別のトップス/グラフィックス
-デバイス名、インターフェース、説明、エイリアスで検索
-golangでエージェントとサーバーの一部を書き換えます。
現時点では、サービスはアラートなどを送信しませんが、URI /エクスポート/により、同じzabbixにデータをインポートして通知を受信できます。 サービスはまだ少し湿っていますが、タスクを解決します。
インストールしてお楽しみください。