HighLoad++、Mikhail Makurov、Maxim Chernetsov (Intersvyaz): Zabbix、100 つのサーバー上で XNUMXkNVPS

次回の HighLoad++ カンファレンスは、6 年 7 月 2020 日と XNUMX 日にサンクトペテルブルクで開催されます 詳細とチケット リンク。 HighLoad++ モスクワ 2018。ホール「モスクワ」。 9月15日00時。 論文や プレゼンテーション.

* モニタリング - オンラインと分析。
* ZABBIX プラットフォームの基本的な制限。
* 分析ストレージを拡張するためのソリューション。
* ZABBIX サーバーの最適化。
* UIの最適化。
* 40k NVPS を超える負荷下でシステムを操作した経験。
* 簡単な結論。

ミハイル・マクロフ（以下、MM）： - こんにちは、みんな！

マキシム・チェルネツォフ（以下、MCH）： - こんにちは！

んん： –マキシムを紹介しましょう。 マックスは才能のあるエンジニアであり、私が知る限り最高のネットワーカーです。 マキシムはネットワークとサービス、その開発と運用に携わっています。

母子家庭: –そしてミハイルについて話したいと思います。 Mikhail は C 開発者です。 彼は、当社のためにいくつかの高負荷トラフィック処理ソリューションを作成しました。 私たちはウラル山脈、屈強な男たちの街、チェリャビンスク、インタースヴィヤズ社に住み、働いています。 当社は、16 都市の XNUMX 万人にインターネットとケーブル テレビ サービスを提供しています。

んん： – そして、Intersvyaz は単なるプロバイダーではなく、IT 企業であると言う価値があります。 当社のソリューションのほとんどは IT 部門によって作成されています。

A： トラフィックを処理するサーバーからコールセンターやモバイル アプリケーションまで。 IT 部門には現在、非常に多様な能力を持った約 80 名がいます。

Zabbix とそのアーキテクチャについて

母子家庭: – それでは、個人記録を樹立して、Zabbix (以下、「Zabbix」と呼びます) とは何かを XNUMX 分で説明してみます。

Zabbix は、自らをエンタープライズレベルのすぐに使える監視システムとして位置づけています。 これには、高度なエスカレーション ルール、統合用の API、グループ化、ホストとメトリクスの自動検出など、作業を容易にする多くの機能があります。 Zabbix には、いわゆるスケーリング ツール、つまりプロキシがあります。 Zabbix はオープンソース システムです。

建築について簡単に。 それは XNUMX つの要素で構成されていると言えます。

• サーバ。 C で書かれています。 かなり複雑な処理とスレッド間の情報転送を伴います。 受信からデータベースへの保存まで、すべての処理がそこで行われます。
• すべてのデータはデータベースに保存されます。 Zabbix は MySQL、PostreSQL、Oracle をサポートしています。
• Web インターフェイスは PHP で書かれています。 ほとんどのシステムには Apache サーバーが付属していますが、nginx + php と組み合わせるとより効率的に動作します。

今日は、Zabbix に関連する当社の人生の物語を XNUMX つお話したいと思います。

Intersvyaz 社の生涯の物語。 私たちは何を持っていて、何が必要なのでしょうか？

5、6か月前です。 ある日の仕事帰り…

母子家庭: - ミーシャ、こんにちは！ なんとか捕まえられてよかったです - 会話があります。 またしてもモニタリングで問題が発生しました。 大規模な事故が発生したときは、すべてが遅くなり、ネットワークの状態に関する情報がありませんでした。 残念ながら、このようなことが起こったのはこれが初めてではありません。 あなたの助けが必要です。 どんな状況でもモニタリングを機能させましょう！

んん： - ただし、まず同期しましょう。 ここ数年はそこを見ていませんでした。 私が覚えている限り、私たちは約 8 年前に Nagios を放棄し、Zabbix に切り替えました。 そして現在、6 つの強力なサーバーと約 XNUMX のプロキシがあるようです。 私は何か混乱していますか？

母子家庭: - ほとんど。 15 台のサーバー (一部は仮想マシン)。 最も重要なことは、それは私たちが最も必要とする瞬間に私たちを救わないということです。 事故のようなものです - サーバーの速度が低下し、何も表示されなくなります。 構成の最適化を試みましたが、最適なパフォーマンスの向上は得られませんでした。

んん： - それは明らかだ。 何かを見ましたか、診断からすでに何かを掘り出しましたか？

母子家庭: – 最初に対処しなければならないのはデータベースです。 MySQL は常にロードされて新しいメトリクスを保存しており、Zabbix が大量のイベントの生成を開始すると、データベースは文字通り数時間オーバードライブ状態になります。 構成の最適化についてはすでにお話ししましたが、文字通り今年、ハードウェアが更新されました。サーバーには XNUMX ギガバイトを超えるメモリと SSD RAID 上のディスク アレイが搭載されています。長期的に見て直線的に増加させることに意味はありません。 私たちは何をしますか？

んん： - それは明らかだ。 一般に、MySQL は LTP データベースです。 どうやら、このサイズのメトリクスのアーカイブを保存するのには適していないようです。 それを理解しましょう。

母子家庭: - しましょう！

ハッカソンの結果としてのZabbixとClickhouseの統合

しばらくして、興味深いデータを受け取りました。

データベース内のスペースのほとんどはメトリクス アーカイブで占められており、構成、テンプレート、設定に使用されたのは 1% 未満でした。 その時点までに、私たちは Clickhouse をベースとしたビッグデータ ソリューションを XNUMX 年以上運用していました。 進行方向は私たちにとって明らかでした。 春のハッカソンで、私はサーバーとフロントエンド用の Zabbix と Clickhouse の統合について書きました。 当時、Zabbix はすでに ElasticSearch をサポートしていたので、それらを比較することにしました。

クリックハウスとエラスティックサーチの比較

んん： – 比較のために、Zabbix サーバーが提供するのと同じ負荷を生成し、システムがどのように動作するかを調べました。 CURL を使用して、1000 行のバッチでデータを書き込みました。 Zabbix が行う負荷プロファイルに対しては、Clickhouse の方が効率的であると事前に想定していました。 結果は私たちの予想をさらに上回りました。

同じテスト条件下で、Clickhouse は XNUMX 倍多くのデータを書き込みました。 同時に、両方のシステムはデータの読み取り時に非常に効率的に (少量のリソースを) 消費しました。 ただし、Elastic は記録時に大量のプロセッサを必要としました。

総合すると、プロセッサ消費量と速度の点で、Clickhouse は Elastix よりも大幅に優れていました。 同時に、データ圧縮により、Clickhouse はハード ドライブの使用量を 11 分の 30 に減らし、ディスク操作の実行量を約 XNUMX 分の XNUMX に減らします。

母子家庭: – はい、Clickhouse とディスク サブシステムの連携は非常に効率的に実装されています。 データベースに巨大な SATA ディスクを使用し、XNUMX 秒あたり数十万行の書き込み速度を得ることができます。 すぐに使えるシステムはシャーディング、レプリケーションをサポートしており、構成は非常に簡単です。 年間を通してご利用いただき、大変満足しております。

リソースを最適化するには、Clickhouse を既存のメイン データベースの隣にインストールすることで、CPU 時間とディスク操作を大幅に節約できます。 メトリクスのアーカイブを既存の Clickhouse クラスターに移動しました。

私たちはメインの MySQL データベースを大幅に軽減し、それを XNUMX 台のマシン上で Zabbix サーバーと組み合わせて、MySQL 専用サーバーを廃止することができました。

Zabbix ではポーリングはどのように機能しますか?

4ヶ月前

んん： – そうですね、基地の問題は忘れてもいいですか？

母子家庭: - それは確かだ！ 解決する必要があるもう 15 つの問題は、データ収集が遅いことです。 現在、XNUMX 台のプロキシ サーバーすべてが SNMP およびポーリング プロセスで過負荷になっています。 そして、新しいサーバーをインストールする以外に方法はありません。

んん： - 素晴らしい。 その前に、Zabbix でポーリングがどのように機能するかを教えてください。

母子家庭: – つまり、メトリクスは 20 種類あり、その取得方法は十数通りあります。 Zabbix は、「リクエスト/レスポンス」モードでデータを収集することも、「トラッパー インターフェイス」を通じて新しいデータを待つこともできます。

オリジナルの Zabbix では、このメソッド (Trapper) が最も高速であることは注目に値します。

負荷分散のためのプロキシ サーバーがあります。

プロキシは、Zabbix サーバーと同じ収集機能を実行でき、Zabbix サーバーからタスクを受信し、収集したメトリクスを Trapper インターフェイス経由で送信します。 これは、負荷を分散するために公式に推奨されている方法です。 プロキシは、NAT または低速チャネルを介して動作するリモート インフラストラクチャを監視する場合にも役立ちます。

んん： – 建築に関してはすべてが明確です。 ソースを確認する必要があります...

数日後

nmap fping がどのように勝利したかの物語

んん： 「何かを掘り出した気がする。」

母子家庭: - 教えて！

んん： – 可用性をチェックするときに、Zabbix は一度に最大 128 のホストをチェックすることがわかりました。 この数値を 500 に増やし、ping のパケット間間隔を削除してみました。これにより、パフォーマンスが XNUMX 倍になりました。 しかし、私はもっと大きな数字が欲しいです。

母子家庭: – 私の実務では、数千のホストの可用性をチェックする必要があることがありますが、これに関しては nmap より高速なものを見たことがありません。 これが一番早い方法だと確信しています。 試してみよう！ 反復ごとのホスト数を大幅に増やす必要があります。

んん： – 600以上を確認しますか？ XNUMX？

母子家庭: - 少なくとも数千です。

んん： - わかりました。 私が言いたかった最も重要なことは、Zabbix でのほとんどのポーリングは同期的に行われることがわかったということです。 必ず非同期モードに変更する必要があります。 そうすれば、特に反復ごとのメトリクスの数を増やすと、ポーラーによって収集されるメトリクスの数を大幅に増やすことができます。

母子家庭: - 素晴らしい！ そしていつ?

んん： – いつものように、昨日。

母子家庭: – fping と nmap の両方のバージョンを比較しました。

多数のホストでは、nmap は最大 4 倍の効果が期待できます。 nmap は可用性と応答時間のみをチェックするため、損失の計算をトリガーに移動し、可用性チェックの間隔を大幅に短縮しました。 nmap の最適なホスト数は、反復ごとに約 120 であることがわかりました。 Nmap により、可用性チェックの CPU コストが 10 分の XNUMX に削減され、間隔が XNUMX 秒から XNUMX 秒に短縮されました。

ポーリングの最適化

んん： 「その後、ポーラーを始めました。 私たちは主に SNMP 検出とエージェントに興味がありました。 Zabbix では、ポーリングは同期的に行われ、システムの効率を高めるために特別な対策が講じられています。 同期モードでは、ホストが利用できないとポーリングが大幅に低下します。 状態のシステム全体があり、特別なプロセス、いわゆる到達不能ポーラーがあり、到達不能なホストでのみ動作します。

これは、状態マトリックス、つまりシステムが効果を維持するために必要な遷移システムのすべての複雑さを示す解説です。 さらに、同期ポーリング自体は非常に遅いです。

そのため、数十のプロキシ上の数千のポーラー ストリームが必要な量のデータを収集できませんでした。 非同期実装により、スレッド数の問題が解決されただけでなく、使用できないホストの状態システムも大幅に簡素化されました。これは、1 回のポーリング反復でチェックされる任意の数の最大待機時間が XNUMX タイムアウトだったためです。

さらに、SNMP リクエストのポーリング システムを変更および改善しました。 実際、ほとんどの人は複数の SNMP 要求に同時に応答することはできません。 したがって、同じホストの SNMP ポーリングが非同期で行われるハイブリッド モードを作成しました。

これはホストのパック全体に対して行われます。 このモードは、1 個の SNMP 値をポーリングしても XNUMX つのタイムアウトよりもはるかに高速であるため、最終的には完全な非同期モードと同じくらい遅くなります。

私たちの実験では、SNMP ポーリングを使用した場合、8 回の反復での最適なリクエスト数は約 200 であることがわかりました。 非同期モードへの移行により、合計でポーリングのパフォーマンスが XNUMX 倍、数百倍高速化されました。

母子家庭: – ポーリングの最適化の結果、すべてのプロキシを削除できるだけでなく、多くのチェックの間隔を短縮できることがわかり、負荷を分散する方法としてプロキシは必要なくなりました。

XNUMXヶ月ほど前

アーキテクチャを変更して負荷を増やしてください。

んん： - さて、マックス、生産性を高める時期ですか? 強力なサーバーと優秀なエンジニアが必要です。

母子家庭: - わかりました、計画しましょう。 毎秒 5 メトリクスというデッドポイントから脱却する時期が来ています。

アップグレード後の朝

母子家庭: - ミーシャ、私たちはアップデートしましたが、朝までにロールバックしてしまいました...私たちが達成できた速度はどれくらいだと思いますか?

んん： – 最大 20 個。

母子家庭: - はい、25歳です！ 残念ながら、私たちはまさに出発点に立っています。

んん： - なぜ？ 何か診断を実行しましたか?

母子家庭: - はい、確かに！ たとえば、ここに興味深いトップがあります。

んん： - 見よう。 膨大な数のポーリング スレッドを試したことがわかります。

しかし同時に、システムを半分もリサイクルすることはできませんでした。

全体的なパフォーマンスは非常に小さく、4 秒あたり約 XNUMX メトリクスです。

他に何かありますか？

母子家庭: – はい、ポーラーの XNUMX 人の痕跡:

んん： – ここでは、ポーリング プロセスが「セマフォ」を待っていることがはっきりとわかります。 これらはロックです:

母子家庭: - 不明瞭です。

んん： – これは、多数のスレッドが一度に XNUMX つのスレッドしか操作できないリソースを操作しようとしている状況に似ています。 その後、彼らにできることは、このリソースを時間をかけて共有することだけです。

そして、そのようなリソースを操作する場合の全体的なパフォーマンスは、XNUMX つのコアの速度によって制限されます。

この問題を解決するには XNUMX つの方法があります。

マシンのハードウェアをアップグレードし、より高速なコアに切り替えます。

または、アーキテクチャを変更し、同時に負荷を変更します。

母子家庭: – ちなみに、テスト マシンでは実戦マシンよりも少ないコアを使用しますが、コアあたりの周波数は 1,5 倍高速です。

んん： - クリア？ サーバーコードを確認する必要があります。

Zabbixサーバーのデータパス

母子家庭: – それを解明するために、Zabbix サーバー内でデータがどのように転送されるかを分析し始めました。

クールな写真ですよね？ 多かれ少なかれ明確にするために、段階的に見てみましょう。 データ収集を担当するスレッドとサービスがあります。

収集したメトリクスはソケット経由でプリプロセッサ マネージャに送信され、そこでキューに保存されます。

「プリプロセッサ マネージャー」はデータをワーカーに送信し、ワーカーは前処理命令を実行し、同じソケット経由でその命令を返します。

この後、プリプロセッサ マネージャーはそれらを履歴キャッシュに保存します。

そこから、それらはヒストリーシンカーによって取得され、ヒストリーシンカーは非常に多くの機能を実行します。例えば、トリガーの計算、値キャッシュへの書き込み、そして最も重要なことに、ヒストリーストレージへのメトリクスの保存です。 一般に、このプロセスは複雑で非常に混乱を招きます。

んん： – 最初に目にしたのは、ほとんどのスレッドがいわゆる「構成キャッシュ」(すべてのサーバー構成が保存されるメモリ領域) をめぐって競合しているということでした。 データ収集を担当するスレッドは、特に多くのブロックを行います。

...構成にはパラメータを含むメトリクスだけでなく、ポーラーが次に何を行うかに関する情報を取得するキューも保存されるためです。 多数のポーラーがあり、XNUMX つが構成をブロックすると、他のポーラーはリクエストを待ちます。

ポーラーは競合しないようにする必要があります

したがって、私たちが最初に行ったことは、キューを 4 つの部分に分割し、安全な条件下でポーラーがこれらのキューを同時にブロックできるようにすることでした。

これにより、構成キャッシュの競合がなくなり、ポーラーの速度が大幅に向上しました。 しかしその後、プリプロセッサ マネージャーがジョブのキューを蓄積し始めているという事実に遭遇しました。

プリプロセッサ マネージャは優先順位を付けることができなければなりません

これは彼がパフォーマンスを欠いた場合に起こりました。 その後、彼ができることは、データ収集プロセスからのリクエストを蓄積し、すべてのメモリを消費してクラッシュするまでバッファを合計することだけでした。

この問題を解決するために、ワーカー専用の XNUMX 番目のソケットを追加しました。

したがって、プリプロセッサ マネージャは自分の作業に優先順位を付ける機会があり、バッファが大きくなった場合には、作業者にこのバッファを取得する機会を与えて削除を遅くすることがタスクになります。

その後、速度低下の原因の XNUMX つは労働者自身にあることがわかりました。労働者は、自分たちの仕事にとってまったく重要ではないリソースを奪い合っていたからです。 この問題はバグ修正として文書化されており、Zabbix の新しいバージョンではすでに解決されています。

ソケットの数を増やします - 結果が得られます

さらに、プリプロセッサ マネージャ自体が 70 つのスレッドであるため、ボトルネックになりました。 これはコア速度に基づいており、最大速度は XNUMX 秒あたり約 XNUMX メトリクスになります。

したがって、XNUMX セットのソケットを備えた XNUMX つのワーカーを作成しました。

これにより、速度を約 130 メトリクスまで向上させることができました。

成長の非線形性は、履歴キャッシュをめぐる競争が発生しているという事実によって説明されます。 4 人のプリプロセッサ マネージャーと歴史をシンカーが競い合いました。 この時点で、テスト マシンでは 130 秒あたり約 95 メトリクスを受信し、プロセッサの約 XNUMX% がそれを利用していました。

約2,5ヶ月前

SNMP コミュニティからの拒否により NVP が XNUMX 倍に増加

んん： – マックス、新しいテストカーが必要です! 私たちはもはや現在の状況に適合しません。

母子家庭: - 今は何を持っていますか？

んん： – 現在 – 130 個の NVP とシェルフ対応プロセッサー。

母子家庭: - おお！ いいね！ 待ってください、質問が 15 つあります。 私の計算によると、必要なメトリクスは 20 秒あたり約 XNUMX ～ XNUMX です。 なぜさらに必要があるのでしょうか?

んん： 「仕事を終わらせたい。」 このシステムからどれだけの利益が得られるか見てみたいと思います。

母子家庭: - だが ...

んん： 「でもビジネスには役に立たないよ」

母子家庭: - それは明らかだ。 そして XNUMX 番目の質問は、開発者の助けを借りずに、現在あるものを自分たちだけでサポートできるかということです。

んん： - 思いません。 構成キャッシュの動作方法を変更するのは問題です。 これはほとんどのスレッドの変更に影響を与えるため、維持するのが非常に困難です。 おそらく、それを維持するのは非常に困難になるでしょう。

母子家庭: 「それなら、何らかの代替手段が必要だ。」

んん： ――そういう選択肢もあるんですね。 新しいロック システムを放棄しながら、高速コアに切り替えることができます。 それでも 60 ～ 80 メトリクスのパフォーマンスが得られます。 同時に、コードの残りの部分はすべて残すことができます。 クリックハウスと非同期ポーリングは機能します。 そしてメンテナンスも簡単になります。

母子家庭: - すばらしい！ ここでやめることをお勧めします。

サーバー側を最適化した後、最終的に新しいコードを運用環境に導入することができました。 高速コアを搭載したマシンに切り替えてコード変更の数を最小限に抑えるために、一部の変更を放棄しました。 また、追加のロックが必要となるため、設定を簡素化し、データ項目内のマクロを可能な限り削除しました。

たとえば、ドキュメントや例でよく見られる snmp-community マクロを廃止することで、この例では NVP をさらに約 1,5 倍高速化することができました。

製作開始からXNUMX日後

インシデント履歴ポップアップの削除

母子家庭: – ミーシャ、システムを XNUMX 日間使用していますが、すべてうまくいきました。 ただし、それはすべてがうまくいった場合に限ります。 私たちはネットワークのかなり大きなセグメントを転送する作業を計画しており、何が上がって何が上がらないかをもう一度自分の手で確認しました。

んん： -そんなはずないよ！ すべてを10回チェックしました。 サーバーは、ネットワークが完全に利用不能になった場合でも即座に処理します。

母子家庭: - はい、すべてを理解しています: サーバー、データベース、トップ、austat、ログ - すべてが高速です...しかし、Web インターフェイスを見ると、サーバー上の「シェルフ内」にプロセッサーがあり、次のようになります。

んん： - それは明らかだ。 ウェブを見てみよう。 多数のアクティブなインシデントが存在する状況では、ほとんどのライブ ウィジェットの動作が非常に遅くなることがわかりました。

その理由は、リスト内の各項目に対して生成されるインシデント履歴ポップアップの生成でした。 したがって、これらのウィンドウの生成を放棄し (コード内の 5 行をコメントアウトしました)、これで問題は解決されました。

ウィジェットの読み込み時間は、完全に利用できない場合でも、数分から許容できる 10 ～ 15 秒に短縮されており、時間をクリックすると履歴を表示できます。

仕事の後。 2ヶ月前

母子家庭: - ミーシャ、出発するの？ 我々は話をする必要があります。

んん： -そんなつもりはなかった。 またZabbixで何か？

母子家庭: - いや、リラックスしてください！ 私が言いたかったのは、「すべてうまくいきました、ありがとう！」ということです。 ビールを持ってきました。

Zabbixは効率的です

Zabbix はかなり普遍的で豊富なシステムと機能です。 小規模なインストールにはそのまま使用できますが、ニーズが増大するにつれて最適化する必要があります。 メトリクスの大規模なアーカイブを保存するには、適切なストレージを使用します。

• Elasticsearch との統合、またはテキスト ファイルへの履歴のアップロード (バージョン XNUMX 以降で利用可能) の形式で組み込みツールを使用できます。
• 当社の経験と Clickhouse との統合を活用してください。

メトリクスの収集速度を大幅に向上するには、非同期メソッドを使用してメトリクスを収集し、トラッパー インターフェイスを介して Zabbix サーバーに送信します。 または、パッチを使用して Zabbix ポーラーを非同期にすることもできます。

Zabbix は C で書かれており、非常に効率的です。 いくつかのアーキテクチャ上のボトルネックを解決すると、パフォーマンスがさらに向上し、私たちの経験では、単一プロセッサ マシンで 100 万を超えるメトリクスを取得できます。

同じZabbixパッチ

んん： – いくつかの点を追加したいと思います。 現在のレポート全体、すべてのテスト、数値は、使用する構成に対して示されています。 現在、そこから 20 秒あたり約 XNUMX メトリクスを取得しています。 これが自分にとってうまくいくかどうかを理解しようとしている場合は、比較してみてください。 今日議論された内容は、パッチの形で GitHub に投稿されます。 github.com/miklert/zabbix

パッチには以下が含まれます:

• Clickhouse との完全な統合 (Zabbix サーバーとフロントエンドの両方)。
• プリプロセッサ マネージャで問題を解決する。
• 非同期ポーリング。

このパッチは、lts を含むすべてのバージョン 4 と互換性があります。 おそらく、最小限の変更を加えるだけでバージョン 3.4 で動作するでしょう。

ご清聴ありがとうございました。

質問

聴衆からの質問（以下、A）： – こんにちは！ 教えてください。これがパッチではなく、Zabbix の通常の動作となるように、Zabbix チームまたはあなたと一緒のチームと集中的にやり取りする計画はありますか?

んん： – はい、変更の一部は確実にコミットします。 何かが起こり、何かがパッチに残ります。

A： – 素晴らしいレポートをありがとうございました！ パッチを適用した後も Zabbix からのサポートは残りますが、上位バージョンへの更新を続ける方法を教えてください。 4.2、5.0 へのパッチ後に Zabbix を更新することはできますか?

んん： – サポートについては何も言えません。 私が Zabbix テクニカル サポートだったら、これは他人のコードなので、おそらく「ノー」と答えるでしょう。 4.2 コードベースに関しては、「時間の経過とともに移行し、次のバージョンで更新する」という立場です。 したがって、しばらくの間、更新バージョンのパッチを公開する予定です。 すでにレポートで述べましたが、バージョンによる変更の数はまだ非常に少ないです。 3.4 から 4 への移行には 15 分ほどかかったと思います。そこで何かが変わりましたが、それほど重要ではありませんでした。

A： – パッチをサポートし、本番環境に安全にインストールして、将来何らかの方法でアップデートを受け取ることができるようにする予定ですか?

んん： – 強くお勧めします。 これにより、多くの問題が解決されます。

母子家庭: – もう一度、アーキテクチャやブロッキングやキューに関係のない変更はモジュール式であり、別個のモジュールにあるという事実に注意していただきたいと思います。 たとえ小さな変更があったとしても、非常に簡単にメンテナンスできます。

んん： – 詳細に興味がある場合は、「クリックハウス」はいわゆる履歴ライブラリを使用します。 これは結合されていません。これは Elastics サポートのコピーであり、構成可能です。 ポーリングではポーラーのみが変更されます。 私たちはこれが長期間にわたって機能すると信じています。

A： - どうもありがとう。 教えてください、加えられた変更についての文書はありますか?

んん： – ドキュメントはパッチです。 明らかに、Clickhouse の導入と新しいタイプのポーラーの導入により、新しい構成オプションが発生します。 最後のスライドのリンクには、その使用方法についての簡単な説明が含まれています。

fping の nmap への置き換えについて

A： – 最終的にはどのようにしてこれを実装したのですか？ 具体的な例を挙げていただけますか: ストラップや外部スクリプトはありますか? これほど膨大な数のホストをなぜこれほど迅速にチェックするのでしょうか? これらのホストをどのようにマイニングするのでしょうか? 何らかの方法でそれらを nmap にフィードしたり、どこかから取得したり、入れたり、何かを実行したりする必要がありますか?...

んん： - いいね。 とても正しい質問です！ ポイントはこれです。 ICMP チェック用にライブラリ (ICMP ping、Zabbix の一部) を変更し、パケット数 (1) を示し、コードは nmap を使用しようとしました。 つまり、これは Zabbix の内部作業であり、pinger の内部作業になっています。 したがって、同期やトラッパーの使用は必要ありません。 これは、システムを無傷のままにし、XNUMX つのデータベース システムの同期に対処する必要がないようにするために意図的に行われました。つまり、何をチェックするか、ポーラーを介してアップロードするか、アップロードが壊れているかどうかを確認する必要があります。これははるかに簡単です。

A： – プロキシでも機能しますか?

んん： – はい、しかし確認しませんでした。 ポーリング コードは Zabbix とサーバーの両方で同じです。 うまくいくはずです。 もう一度強調しておきますが、システムのパフォーマンスはプロキシを必要としないほどです。

母子家庭: – 質問に対する正しい答えは、「なぜそのようなシステムでプロキシが必要なのですか?」です。 NAT またはある種の低速チャネルを介したモニタリングが原因でのみ...

A： – 私の理解が正しければ、あなたは Zabbix をアラーターとして使用しています。 それとも、グラフィックス (アーカイブ レイヤーがある場所) を Grafana などの別のシステムに移動しましたか? それともこの機能を使っていないのでしょうか？

んん： – もう一度強調しますが、私たちは完全な統合を達成しました。 私たちは Clickhouse に歴史を注ぎ込んでいますが、同時に PHP フロントエンドも変更しました。 Php フロントエンドは Clickhouse に移動し、そこからすべてのグラフィックスを実行します。 同時に、正直に言うと、同じクリックハウス、同じ Zabbix データから他のグラフィック表示システムのデータを構築する部分もあります。

母子家庭: ――『グラファン』でも。

リソースの割り当てについてはどのように決定されましたか?

A： – あなたのインナーキッチンを少し共有してください。 製品の本格的な処理にリソースを割り当てる必要があるとの判断はどのように行われましたか? これらは一般に、一定のリスクです。 そして、新しいバージョンをサポートするという事実に照らして、この決定は管理の観点からどのように正当化されるのか教えてください。

んん： –どうやら歴史のドラマをうまく伝えていなかったようです。 私たちは何かをしなければならない状況に陥っていることに気づき、基本的に XNUMX つの並行チームで行動しました。

• XNUMX つは、新しい方法を使用して監視システムを立ち上げることでした。サービスとしての監視とは、オープンソース ソリューションの標準セットを組み合わせて、新しい監視システムと連携するためにビジネス プロセスの変更を試みるというものです。
• 同時に、これを（自分自身について）やっていた熱心なプログラマーがいました。 たまたま彼が勝ちました。

A： –そしてチームの規模はどれくらいですか？

母子家庭: - 彼女はあなたの前にいます。

A： – では、いつものように、情熱を持った人が必要ですか？

んん： – 情熱家が何なのか分かりません。

A： - この場合、どうやらあなたです。 ありがとうございます、あなたは素晴らしいです。

んん： - ありがとうございます。

Zabbix用パッチについて

A： – プロキシを使用するシステム (たとえば、一部の分散システム) の場合、ポーラー、プロキシ、および部分的に Zabbix 自体のプリプロセッサを適応させてパッチを適用することは可能ですか。 そして彼らのやりとりは？ 複数のプロキシを備えたシステム用に既存の開発を最適化することは可能ですか?

んん： – Zabbix サーバーがプロキシを使用して組み立てられていることは知っています (コードはコンパイルされて取得されます)。 本番環境ではこれをテストしていません。 これについてはよくわかりませんが、プロキシではプリプロセッサ マネージャーが使用されていないと思います。 プロキシのタスクは、Zabbix から一連のメトリクスを取得し、それらをマージし (設定やローカル データベースも記録します)、それを Zabbix サーバーに返すことです。 サーバー自体は、受信時に前処理を実行します。

プロキシに対する関心は理解できます。 確認してみます。 これは興味深いトピックです。

A： – アイデアは次のとおりです。ポーラーにパッチを適用できる場合は、プロキシ上でポーラーにパッチを適用し、サーバーとの対話にパッチを適用し、サーバー上でのみプリプロセッサをこれらの目的に適応させることができます。

んん： – もっとシンプルだと思います。 コードを取得し、パッチを適用して、必要な方法で設定します。つまり、プロキシ サーバーを収集し (ODBC などを使用して)、パッチを当てたコードをシステム全体に配布します。 必要に応じてプロキシを収集し、必要に応じてサーバーを収集します。

A： – おそらく、サーバーへのプロキシ送信に追加のパッチを適用する必要はありませんか?

母子家庭: - いいえ、標準です。

んん： – 実際、アイデアの XNUMX つは実現しませんでした。 私たちは、アイデアの爆発と変更の量とサポートのしやすさとの間のバランスを常に維持してきました。

いくつかの広告 🙂

いつもご宿泊いただきありがとうございます。 私たちの記事が気に入っていますか? もっと興味深いコンテンツを見たいですか? 注文したり、友人に勧めたりして私たちをサポートしてください。 開発者向けのクラウド VPS は 4.99 ドルから, 当社があなたのために発明した、エントリーレベルのサーバーのユニークな類似物です。 VPS (KVM) E5-2697 v3 (6 コア) 10GB DDR4 480GB SSD 1Gbps 19 ドルからの真実、またはサーバーを共有する方法? (RAID1 および RAID10、最大 24 コア、最大 40GB DDR4 で利用可能)。

アムステルダムのエクイニクス Tier IV データセンターでは Dell R730xd が 2 倍安い? ここだけ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV 199 ドルから オランダで！ Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99 ドルから! について読む インフラストラクチャー企業を構築する方法730 ペニーで 5 ユーロの価値がある Dell R2650xd E4-9000 vXNUMX サーバーを使用したクラスですか?

出所： habr.com