最近会社の案件で一台のzabbixサーバを使って20万台＊5項目＝100万項目を5分間隔のポーリングでやるプランを検討中ですが、果たして可能でしょうか。 トラフィック条件は一日平均アラーム件数1,000,000件、バースト時1,000件/秒です。 もし可能でしたらサイジングに関してCPUやメモリ情報をお願いします。 もし不可能でしたら最低限何台サーバが必要でしょうか。 ご存知の方がいればぜひご教授願います。
パッと見ただけで、かなり無謀な気がしますが・・・。 少なくとも私の周辺ではそれほど大規模なものは見たことありません。
まあ、Zabbix のページ https://www.zabbix.com/jp/ には ＞スケーラビリティ ＞100,000のデバイスの監視 ＞1,000,000の監視項目 ＞秒間1000項目の監視 なんて書いてあるので、その気になればできるんでしょうかね。
一応参考までに、このページも見てみてください。 https://www.zabbix.com/documentation/3.4/manual/installation/requirements
たぶん、それだけ監視対象が多いなら、プロキシを複数台用意して監視することになるんじゃないかと思います。
あんまり大した情報なくてすみません・・・。
大規模での活用事例として、Zabbix公式から公開されているもので めぼしい規模のモノがあります
Conference 2015 オープニングスピーチにおいて、Alexei氏が発表された中の ロシアのスーパーマーケットでの事例 https://www.zabbix.com/jp/conf_japan_2015_agenda https://www.zabbix.com/img/zabconf2015_jp/presentations/01_zabconf2015_a... 11000店舗・拠点にプロキシを配置して監視を実施 20万監視対象ホスト・500万監視項目‥とのことでした
相応の規模のサーバスペックや、DBのチューニング、 拠点・監視対象ホスト間を結び、最終的にサーバ側で大量のトラフィックを受ける 通信回線・速度等、インフラ面での整備はかなり大変だと思いますが‥
１台のサーバから全てをポーリングというのは非現実的なので 拠点毎・ラック毎等で、適度にサイジングしたProxyを分散配置する構成として 設計されることをお奨めします ＃Proxy利用によって、バージョンアップしにくくなってしまう点だけは要注意です
広瀬です
■利用バージョンについて 追加情報として、ZABBIX3.4以上をおすすめします。アラートが1000件/秒となると、 3.2までのZABBIXではAlertポーラーが恐らく厳しいと思います。
※3.2まではAlertポーラーがシングル
また、3.4はポイントリリースなので、長期的な利用は望めませんので、そうなると4.0 を待つのが得策とも言えます。
■冗長化するか否か ZABBIXサーバ本体、Proxy、DBなどの組み合わせをどうするか次第ですが、SPoFを 作らない事も重要なポイントになります。作るとどうしても台数が2倍になるので、留意は すべきかと
※私的経験としてはAct/Stb構成のClusterにZABBIXとDBを別々に乗っけてました
広瀬さん
度々すみません、 利用バージョンについてもう少し質問したいですが、 ※3.2まではAlertポーラーがシングル とおっしゃいましたが、シングルのアラートポーラーは何件/秒ですか？ もう少し具体的に言うとLTS版の3.0のアラートは何件/秒ですか？
お答えしていただけると幸いです。
Alerterプロセスで何を実行するかと、サーバーの性能に依存しま す。
また、メール送信以外にも、スクリプトやリモートコマンドの実行 も可能ですので、それらの処理内で、他のサーバーと通信するよう な場合は、その相手のサーバーの応答が遅ければ、1秒あたりに処 理できる数もさらに制限されることとなります。
例えば、メール送信だけであっても、そのメールサーバーで1秒あ たりに何通送れるのか、その性能が上限となるでしょう。
・・・既にTNKさんにお答え頂いてますが、念のため
Alertポーラーはあくまでも指定した先に出力するためのZABBIX内部の機構の一部に過ぎないので、 そこから先はメールだったりScriptだったり、またはパトランプだったりと様々です。
メールならローカル内でも解決出来るでしょうけど、connect⇒disconnectまでのSMTPの通常会話は 数ミリでは終わりません。Gmailに飛ばすとGmailまでの往復分も加味されます。どこのリージョンに行く のか解りませんから、子細不明。
パトランプの場合SNMPかrshなどが主流だと思いますが、それぞれサーバ本体とはかけ離れた場所 にあるはずです。SNMPは純粋なUDP、rshも一部にUDP通信を持つので、プロトコル特性上、再送 処理を行わないなど遅延要因はさまざまですので、数値化はできません。
Scriptは当然そのスクリプトの作り(awkよりcutコマンドの方が早いとか)＋H/W性能に左右されます。
・・・なので、ZABBIXが耐久出来るホスト数やアイテム数の上限を知るより、遙かに数値化は難しいと お考え頂くと幸いです。 ZABBIXに限らず様々なソフトウェアに言えますが、中々数値化出来ないものがあるのであまり数値に 捕らわれ過ぎない方が良いと思います。 100万アイテムなら5等分して20万アイテムづつに平均化し、負荷状況みつつ、方向性を変えて行くな どなら、最小5台でも良い訳です。ログ監視など負荷の高い監視を行わない前提で、10万アイテム程度 なら1台（※）でも十分賄えます。
※それなりのチューニングは必要。ICMP監視だけ見てもデフォルト設定では負荷が高いです
heyaさん、fripperさん、wakabaさん 早速の返信ありがとうございます。 大変参考になりました。 スペックとプロキシ次第で出来なくはないみたいだけど、不安です… もう少し検証をしてから慎重に行きます。 皆様の返答に感謝します。 何かあったらまたよろしくお願いします。
TNKさん、広瀬さん 返信をありがとうございます。 お二人の意見を考慮して、 もう少し構成状況と相談しながら決めたいです。 何かあったらまた相談させて頂きます。
参考になる規模ではないかもしれませんが… 一応今、新ハードとZabbix3.4での性能検証中でして、そのデータを簡単に。
[仮想基盤] Hypervisor：VMware ESXi6.0 CPU：2P20C 2.27GHz メモリ：256GB ストレージ： OS用：10kSAS 600GB *6 RAID10 DB用：FusionIO 600GB*6 ネットワーク：1GB*2 LACP
[Zabbix VM] OS：CentOS6.9 CPU：12core割当 メモリ：200GB割当 ストレージ： OS用から100GB DB用から1.8TB（OS上でソフトウェアRAID10） DB：MySQL 5.7 Zabbix：3.4.1 PHP：7.1 Proxy：無し（本番移行時にはProxy12台構成） DBレコード件数：約150億レコード DBパーティションニング：有り。COMPOSITE（RANGE+LINEAR HASH）
[監視] 監視対象：200（もっと増やしたいが物理的なリソースなくて出来てない…） 秒間当たりの監視項目数：約7000
現状、これぐらいですが、さっくさく動作しており、 使用リソースもかなり余裕があります。消費量20%程度ぐらい。
※この環境より低スペックなHWで現状本番運用中で、それが以下。 これよりポーリングとDB性能を大幅強化したくて新環境検証中。 監視対象：1500台 アイテム数：約25万 トリガー数：約3万 秒間当たりの監視項目数：約1500
参考になれば・・・
TF0814さん 返信をありがとうございます。 貴重なテストデータを教えていただき、大変参考になります。 相談したいことがあったらまたよろしくお願いします。
ちょっと有益そうな情報が取れたので。
あれから、監視対象ホスト数を増加させ、継続検証してみました。 （同一サーバを別ホスト名でZabbixに登録すれば良いと今更気づく…）
監視対象：550台 アイテム数：25,000 トリガー数：11,000 秒間当たりの監視項目数：25,000 ※監視アイテム全てを1秒周期で取得してます。
上記状態から、監視対象を600台まで増加させたところ、バージョン3.4からの新機能 preprocessing managerのbusy率が100%に張り付き、Agentからのアイテムが収集 されない状態に陥りました。
どうやら保存前処理の機能を使用していなくても、このmanagerは通過するようで…？ manageは1プロセスのため、ここで処理が律速しているようでした…。 （topで見た時、queuedに大量に溜まってた）
ultramanさんの環境が、100万アイテムを5分間隔ポーリングとのことなので nvpsは3333程度？になると思われるので、恐らくpreprocessing managerで 律速することはなさそうですが、ちょっと気になります。
今後のバージョンUPでこの辺りが改善されると、ハード的にはまだまだいけそうです。 ※3.4のsource読んだ訳ではないので、間違ってたらきっと有識者の方が指摘して…くれるはず？
ご参考： 3.4.1で、Preprocessing関連の不具合が確認されています。 次バージョンで改善されるようです。
ZBX-12618 : item became not supported: Item preprocessing step #1 failed: (null) https://support.zabbix.com/browse/ZBX-12618 ZBX-12725 : Preprocessing issues (Huge Queue & Zabbix server crash) https://support.zabbix.com/browse/ZBX-12725
TNKさん
不具合でしたか…。 確かにPreprocessingの稼働数増やしたら1度クラッシュしました…。 3.4.2が出たらこちらについては解消されることを期待しておきます。 情報ありがとうございました！
TF0814さん、TNKさん 返信をありがとうございます。 貴重なテストデータを教えていただき、大変参考になります。 ただ、3.4からの新機能とのことで、 保守を考えたらLTS版を採用した上でアラート問題をなんとかする方針に、 なのでpreprocessing manager機能は多分使えないことになります。
アカウント名 ultraman
居住地 東京
Zabbix関連
heya - 投稿数: 319
パッと見ただけで、かなり無謀な気がしますが・・・。
少なくとも私の周辺ではそれほど大規模なものは見たことありません。
まあ、Zabbix のページ https://www.zabbix.com/jp/ には
＞スケーラビリティ
＞100,000のデバイスの監視
＞1,000,000の監視項目
＞秒間1000項目の監視
なんて書いてあるので、その気になればできるんでしょうかね。
一応参考までに、このページも見てみてください。
https://www.zabbix.com/documentation/3.4/manual/installation/requirements
たぶん、それだけ監視対象が多いなら、プロキシを複数台用意して監視することになるんじゃないかと思います。
あんまり大した情報なくてすみません・・・。
fripper - 投稿数: 495
大規模での活用事例として、Zabbix公式から公開されているもので
めぼしい規模のモノがあります
Conference 2015 オープニングスピーチにおいて、Alexei氏が発表された中の
ロシアのスーパーマーケットでの事例
https://www.zabbix.com/jp/conf_japan_2015_agenda
https://www.zabbix.com/img/zabconf2015_jp/presentations/01_zabconf2015_a...
11000店舗・拠点にプロキシを配置して監視を実施
20万監視対象ホスト・500万監視項目‥とのことでした
相応の規模のサーバスペックや、DBのチューニング、
拠点・監視対象ホスト間を結び、最終的にサーバ側で大量のトラフィックを受ける
通信回線・速度等、インフラ面での整備はかなり大変だと思いますが‥
１台のサーバから全てをポーリングというのは非現実的なので
拠点毎・ラック毎等で、適度にサイジングしたProxyを分散配置する構成として
設計されることをお奨めします
＃Proxy利用によって、バージョンアップしにくくなってしまう点だけは要注意です
wakaba - 投稿数: 228
広瀬です
■利用バージョンについて
追加情報として、ZABBIX3.4以上をおすすめします。アラートが1000件/秒となると、
3.2までのZABBIXではAlertポーラーが恐らく厳しいと思います。
※3.2まではAlertポーラーがシングル
また、3.4はポイントリリースなので、長期的な利用は望めませんので、そうなると4.0
を待つのが得策とも言えます。
■冗長化するか否か
ZABBIXサーバ本体、Proxy、DBなどの組み合わせをどうするか次第ですが、SPoFを
作らない事も重要なポイントになります。作るとどうしても台数が2倍になるので、留意は
すべきかと
※私的経験としてはAct/Stb構成のClusterにZABBIXとDBを別々に乗っけてました
ultraman - 投稿数: 8
広瀬さん
度々すみません、
利用バージョンについてもう少し質問したいですが、
※3.2まではAlertポーラーがシングル
とおっしゃいましたが、シングルのアラートポーラーは何件/秒ですか？
もう少し具体的に言うとLTS版の3.0のアラートは何件/秒ですか？
お答えしていただけると幸いです。
TNK - 投稿数: 4720
Alerterプロセスで何を実行するかと、サーバーの性能に依存しま
す。
また、メール送信以外にも、スクリプトやリモートコマンドの実行
も可能ですので、それらの処理内で、他のサーバーと通信するよう
な場合は、その相手のサーバーの応答が遅ければ、1秒あたりに処
理できる数もさらに制限されることとなります。
例えば、メール送信だけであっても、そのメールサーバーで1秒あ
たりに何通送れるのか、その性能が上限となるでしょう。
wakaba - 投稿数: 228
広瀬です
・・・既にTNKさんにお答え頂いてますが、念のため
Alertポーラーはあくまでも指定した先に出力するためのZABBIX内部の機構の一部に過ぎないので、
そこから先はメールだったりScriptだったり、またはパトランプだったりと様々です。
メールならローカル内でも解決出来るでしょうけど、connect⇒disconnectまでのSMTPの通常会話は
数ミリでは終わりません。Gmailに飛ばすとGmailまでの往復分も加味されます。どこのリージョンに行く
のか解りませんから、子細不明。
パトランプの場合SNMPかrshなどが主流だと思いますが、それぞれサーバ本体とはかけ離れた場所
にあるはずです。SNMPは純粋なUDP、rshも一部にUDP通信を持つので、プロトコル特性上、再送
処理を行わないなど遅延要因はさまざまですので、数値化はできません。
Scriptは当然そのスクリプトの作り(awkよりcutコマンドの方が早いとか)＋H/W性能に左右されます。
・・・なので、ZABBIXが耐久出来るホスト数やアイテム数の上限を知るより、遙かに数値化は難しいと
お考え頂くと幸いです。
ZABBIXに限らず様々なソフトウェアに言えますが、中々数値化出来ないものがあるのであまり数値に
捕らわれ過ぎない方が良いと思います。
100万アイテムなら5等分して20万アイテムづつに平均化し、負荷状況みつつ、方向性を変えて行くな
どなら、最小5台でも良い訳です。ログ監視など負荷の高い監視を行わない前提で、10万アイテム程度
なら1台（※）でも十分賄えます。
※それなりのチューニングは必要。ICMP監視だけ見てもデフォルト設定では負荷が高いです
ultraman - 投稿数: 8
heyaさん、fripperさん、wakabaさん
早速の返信ありがとうございます。
大変参考になりました。
スペックとプロキシ次第で出来なくはないみたいだけど、不安です…
もう少し検証をしてから慎重に行きます。
皆様の返答に感謝します。
何かあったらまたよろしくお願いします。
ultraman - 投稿数: 8
TNKさん、広瀬さん
返信をありがとうございます。
お二人の意見を考慮して、
もう少し構成状況と相談しながら決めたいです。
何かあったらまた相談させて頂きます。
TF0814 - 投稿数: 49
参考になる規模ではないかもしれませんが…
一応今、新ハードとZabbix3.4での性能検証中でして、そのデータを簡単に。
[仮想基盤]
Hypervisor：VMware ESXi6.0
CPU：2P20C 2.27GHz
メモリ：256GB
ストレージ：
OS用：10kSAS 600GB *6 RAID10
DB用：FusionIO 600GB*6
ネットワーク：1GB*2 LACP
[Zabbix VM]
OS：CentOS6.9
CPU：12core割当
メモリ：200GB割当
ストレージ：
OS用から100GB
DB用から1.8TB（OS上でソフトウェアRAID10）
DB：MySQL 5.7
Zabbix：3.4.1
PHP：7.1
Proxy：無し（本番移行時にはProxy12台構成）
DBレコード件数：約150億レコード
DBパーティションニング：有り。COMPOSITE（RANGE+LINEAR HASH）
[監視]
監視対象：200（もっと増やしたいが物理的なリソースなくて出来てない…）
秒間当たりの監視項目数：約7000
現状、これぐらいですが、さっくさく動作しており、
使用リソースもかなり余裕があります。消費量20%程度ぐらい。
※この環境より低スペックなHWで現状本番運用中で、それが以下。
これよりポーリングとDB性能を大幅強化したくて新環境検証中。
監視対象：1500台
アイテム数：約25万
トリガー数：約3万
秒間当たりの監視項目数：約1500
参考になれば・・・
ultraman - 投稿数: 8
TF0814さん
返信をありがとうございます。
貴重なテストデータを教えていただき、大変参考になります。
相談したいことがあったらまたよろしくお願いします。
TF0814 - 投稿数: 49
ちょっと有益そうな情報が取れたので。
あれから、監視対象ホスト数を増加させ、継続検証してみました。
（同一サーバを別ホスト名でZabbixに登録すれば良いと今更気づく…）
監視対象：550台
アイテム数：25,000
トリガー数：11,000
秒間当たりの監視項目数：25,000
※監視アイテム全てを1秒周期で取得してます。
上記状態から、監視対象を600台まで増加させたところ、バージョン3.4からの新機能
preprocessing managerのbusy率が100%に張り付き、Agentからのアイテムが収集
されない状態に陥りました。
どうやら保存前処理の機能を使用していなくても、このmanagerは通過するようで…？
manageは1プロセスのため、ここで処理が律速しているようでした…。
（topで見た時、queuedに大量に溜まってた）
ultramanさんの環境が、100万アイテムを5分間隔ポーリングとのことなので
nvpsは3333程度？になると思われるので、恐らくpreprocessing managerで
律速することはなさそうですが、ちょっと気になります。
今後のバージョンUPでこの辺りが改善されると、ハード的にはまだまだいけそうです。
※3.4のsource読んだ訳ではないので、間違ってたらきっと有識者の方が指摘して…くれるはず？
TNK - 投稿数: 4720
ご参考：
3.4.1で、Preprocessing関連の不具合が確認されています。
次バージョンで改善されるようです。
ZBX-12618 : item became not supported: Item preprocessing step #1 failed: (null)
https://support.zabbix.com/browse/ZBX-12618
ZBX-12725 : Preprocessing issues (Huge Queue & Zabbix server crash)
https://support.zabbix.com/browse/ZBX-12725
TF0814 - 投稿数: 49
TNKさん
不具合でしたか…。
確かにPreprocessingの稼働数増やしたら1度クラッシュしました…。
3.4.2が出たらこちらについては解消されることを期待しておきます。
情報ありがとうございました！
ultraman - 投稿数: 8
TF0814さん、TNKさん
返信をありがとうございます。
貴重なテストデータを教えていただき、大変参考になります。
ただ、3.4からの新機能とのことで、
保守を考えたらLTS版を採用した上でアラート問題をなんとかする方針に、
なのでpreprocessing manager機能は多分使えないことになります。