出生問題
一般に、何も起こりませんでした（このジャンルの法律に完全に準拠）。 テンプレートを作成し、自動検出を開始して、文化的な休息のために出発しました。金曜日だったからです。 月曜日に戻ると、週末にZabbixが「自動検出」するホストは1つだけであることがわかりました。 これにうんざりして、私たちは理由を振り返り始めました。 そして、単純な考えが私たちに現れました-実際にクラスAサブネットとは何ですか？
計算機は、クラスAサブネットには約1,700万のホストが含まれることを有益に示唆しました。 さらに、私たちの電子会計士は、Zabbixが1つのアドレスを分解するのに3秒費やす場合（ネットワークの遅延、明らかに顧客ではないポーリングなど）、クラスAサブネットをバイパスするのに約1年半かかると指定しました。 あるラウンドでは、強調します。 このプロセスは並行して実行できます。たとえば、20個のバッチでアドレスを確認します。 ただし、この場合でも、クラスAサブネットのラウンドアバウトを完了するには約1か月かかります。 1ラウンドでは十分ではないことは明らかです。Zabbixが問い合わせをしようとする瞬間に端末の電源が切れたり、アクセスできなくなったりする可能性があります。 一般的に、標準のZabbix自動検出ツールは通常どおり動作しますが、大規模なネットワークを検査するようには設計されていないことに突然気付きました。
どうする ©Chernyshevsky
手でZabbixにホストを追加しますか？ これは、単純で本質的に問題に直面して恥ずべき降伏を認識することを意味しました。
インターネットは、このようなタスクに最初に遭遇するのは私たちではない、と私たちに言っています。 公式のZabbixフォーラムで、同様の質問がされました。 そして、彼らはそのようなフォーラムのために、伝統的な悲しいかな答えを受け取りました-最も複雑で非効率的な方法の申し出。 Zabbix APIを学ぶ時間がなかったので、私たちは再びデータベースで運を試してみることにしました。
決定アルゴリズム
Zabbixデータベースには、すべての監視対象ホストとそのパラメーターをリストしたテーブル、hostsテーブルがあります。 さらに、この表の各ホストは一意の識別子-整数に対応しています。 同時に、ホストを制御するために設定するのに十分なパラメーターがあまりありません-データベース内の識別子、Zabbix内のIPと名前。
アプローチは簡単です-最初に、データベース上のどのインデックスに最後のホストが追加されたかを見つけます：
select hostid from zabbix.hosts order by hostid desc limit 1;
以下、MySQLに対してクエリが提供されますが、これは原則として本質に影響しません。 取得した値を1増やします-新しいホストのデータベースのインデックスの準備ができました。 ホスト名とそのIPアドレスをそれぞれ知っているので、Zabbixにホストを追加できます。
insert into zabbix.hosts (hostid,host,useip,ip) values ($hostid,$hostname,1,$IP);
この場合：
- $ hostid-以前に受け取った新しいデータベースインデックス。
- $ hostname-ホスト名;
- $ IPはそのIPアドレスです。
上記のクエリは、DNS名ではなくアドレスでホストを制御するという仮定の下で行われます。 ただし、この2番目のオプションでは、クエリは根本的に変更されず、新しいフィールドのみが追加されます。
そのため、ホストは追加されましたが、これでは十分ではありません。各ホストはいくつかのグループに属している必要があります。 また、これはデータベースで直接行うこともできます。 確かに、ターミナルをLinuxサーバーグループに追加したいとします。
データベース内のすべてのグループは、グループテーブルに格納されます（簡単ですよね？）。 グループのインデックスが必要になります。これは簡単なクエリで確認できます。
select groupid from zabbix.groups where name='Linux servers';
データベース内のグループへのホストの帰属を説明するために、hosts_groupsという特別なテーブルがあります。 単純な一致はこのテーブルに格納されます-などのインデックスを持つグループはなどのインデックスを持つホストに対応します。 ホストごとに、このホストに含まれるグループの数とまったく同じ数の一致が入力されます。 そして、通常、各通信には一意のインデックス、つまり整数が割り当てられます。 最後の一致のインデックスを見つけます：
select hostgroupid from zabbix.hosts_groups order by hostgroupid desc limit 1;
取得した値を1増やします-新しく追加したホストの新しい一致インデックスです。 ホストインデックス、グループインデックスが判明したことを知っています。ホストをグループに追加できないのはなぜですか？
insert into zabbix.hosts_groups (hostgroupid,hostid,groupid) values ($hostgroupid,$hostid,$groupid);
この場合：
- $ hostgroupid-新しいマッピングのインデックス。
- $ hostid-新しいホストのインデックス（ホスト自体を追加するために上記で使用しました）;
- $ groupid-必要なグループのインデックス（上で見つけた）。
これらすべての操作の後、Zabbix Webインターフェースを調べて、Linuxサーバーグループでホストを見つけることができます。 パラメーターを見ると、このホストにはセンサー、トリガー、グラフィックが関連付けられていないことがわかります。Zabbixはホストを認識していますが、単一のデータ要素が設定されていないため、それを制御しません。 あらかじめ作成されたテンプレートをこのホストに適用します-それはすべて帽子です！ Zabbixは、ホストにセンサーとトリガーを個別にマウントし、監視を開始します。
その結果、私たちのタスクは結合されたアプローチによって解決されます：
- データベースを操作することにより、すべてのターミナルをZabbixに追加します。
- ホストの一括更新機能を使用して、追加された端末に適切なテンプレートを添付します。
PS記事の周りでは、ホストの名前の下に、このホストがZabbixで表示されるまさにその名前を意味します。 そして、それはDNSホスト名とは何の関係もありません（ただし、だれもそれらを一致させることはありません）。 監視エージェントを使用する場合、ホスト名はその構成ファイルのホスト名パラメータの値です。
あとがきの代わりに
データベースの操作における前世代の失敗は、テンプレートをデータベース内のホストに一致させることは、このテンプレートをZabbixインターフェースから適用することと決して同じではないことです。 明らかに、テンプレートを使用すると、ホストとセンサー、ホストとトリガーなどの間のマッピングが作成され、これらのテーブルの構造はすでに複雑になりすぎています。
ここでは既製のスクリプトを提供しません。 まず、私は持っていないので、実用的な部分は、Perlの同僚が名前とIP端末でテキストファイルを解析し、それらからSQLスクリプトを作成することによって行われました。 私はおそらくRubyですべてをするでしょう。 別の同僚は、ここで耳を傾ければ通常のシェルスクリプトで十分だと言いました。 ただし、アルゴリズムは単純であり、必要に応じて実装できます。
そして最後に...ターミナルを追加したとき、1つのポイントを考慮しませんでした。Zabbixの場合、監視センサーの数が80から4000に突然増加しました。 したがって、少なくとも人道上の理由から、このような大量のホストを追加する前に、Zabbixホストをオフにすることをお勧めします。 もちろん、テンプレートを追加して適用した後、Zabbixはその上に落ちた多数の制御オブジェクトを認識して消化するのに時間がかかりますので、我慢してください。 ただし、この時間は、クラスAサブネットをバイパスするのに必要な時間よりも桁違いに短くなっています。