大規模監視での検討課題について
フォーラムの皆様
単一のZabbixサーバーで、90万アイテム、nvps:3000程度の監視を検討中です。
通常時のアラームは、殆ど発生しない想定です。
2017年9月の ultraman さんの投稿を参考に、サーバースペックなどを考えているところで、通常の平穏なときは問題なさそうに思えています。
気になるのは、パッシブチェックやシンプルチェックのタイムアウトが多数のホストで同時に多発した場合や、SNMPトラップを短時間に大量に受信したとき、ログがエージェントから大量に送られてきたときなどです。
同時多発や大量を、どの位に想定するかで違うとは思いますが、皆様の経験上、どのような対策を取られているのか、
ご教授いただけないでしょうか。
また、他に検討するべきケースなどありましたら、ご教示いただけると助かります。
よろしくお願いします。
fripper - 投稿数: 495
サーバ側の負荷・必要ハード性能は、以下により大きく変わるかと思います
・DBはサーバと同居させるか、外部に構築（別ホスト上やRDS利用等）するか
Zabbixサーバモジュールそのものの負荷と同じくらいには
DBの I/O 負荷・処理負荷によるサーバ負荷の比率が大きいので
同居の場合は１台に相応の性能を必要とします
ZabbixサーバとDBサーバに分ける場合は、個々の必要スペックは下げられるのですが
どちらにしても、各々のサーバで負荷がさばけるだけの性能は必要になります
・アイテムで「Zabbixエージェント」「Zabbixエージェント（アクティブ）」の割合
アクティブ系を多用すれば、サーバがアイテム毎にポーリングせずに済むので
サーバ側の負荷は比較的低くすることができます
同様に、SNMPチェック等もサーバ側がポーリングするので
少ないほうがZabbixサーバの負荷は下がります
全てアクティブ系のみにしてしまうと、サーバ側負荷は下げられるのですが
「ポーリングに対する応答がない」で監視対象のダウンを検知できていたのが
「延々と待ってもエージェントからの報告が来ない」で監視対象のダウンを検知するように
設計・構築しなければいけないので、nodata等を利用したトリガーの採用等も
考慮に入れる必要が出てくるかと思います
・プロキシの利用
「Zabbixエージェント」「SNMP」等のポーリング系の監視動作を肩代わりさせられるので
ある程度の監視対象ホスト単位でプロキシで分けておくと
サーバ側は「プロキシからの纏まった結果報告」だけを受信すれば済むので
負荷を小分けにできます
代わりに、プロキシが同一メジャーバージョンでないといけない制約や
プロキシの管理等が必要となってしまうデメリットもありますが‥
SNMPトラップ受信まわりもプロキシ単位での構築となってしまうので面倒とも言えます‥
393959532 - 投稿数: 3
fripper さん
ありがとうございます。
DBを別居することは考えてませんでした。
ご指摘のように、個々のサーバーのスペックは下げられても2台必要になることと、
サーバー間のNWのオーバーヘッドも発生するように思います。
I/O負荷についてはSSDを利用するのも検討しています。
費用は掛かりますが、以前に比べるとかなり安くなってきていますので。
SSDを利用する場合のリスクは何か考えられますでしょうか。
Zabbixエージェント（アクティブ）を増やした場合、
エージェント側の処理がシングルプロセスにならないでしょうか。
ログ監視で大量のログが書かれたときに、エージェントの負荷が高くなった経験があり、
そのような時に他の監視ができなくなってしまう気がしました。
Zabbixエージェントであれば、StartAgentsを増やすこともできます。
そのような点も踏まえて、割合と書かれていると理解しました。
やはりプロキシを利用するのが無難なのでしょうか。
fripper - 投稿数: 495
・DBについて
仰るとおり、２台必要となることと、サーバ間NWのオーバーヘッドも有るかと思います
外部サーバとすることによるメリットは、バックアップ・メンテナンス時の取り回しで
少しでも’疎’な関係としておくことで融通がきく可能性がある点でしょうか
私自身、同居サーバの管理をしていて、負荷・ボトルネック調査に手間取った経験があり
別サーバなら原因特定が手早くできた可能性に後から気づいたことがあった次第です
故障リスク等も上がってしまうのも事実ですし、選択次第かと
・SSD利用
前述規模となると、おそらくは平常時でも数十MB/sの書込が常時発生
ログのバースト等があると100MB/s単位のI/Oとなるかと思います
まず注意すべきは、SSDの書換耐性でしょう
最近のSSDだと1DWPD (1日あたりドライブ容量x1 分の書込耐性) を超える
製品も出ているようですので、書換耐性の高いモデルを選択されるのが
良いかと思います
また、カタログスペックにある書込速度は瞬間値で、連続書込を1時間ほど続けると
スループットがどんどん下がるモデルもあったりするので
そのあたりにも注意して、ピーク速度が低くても、カタログスペックが常時安定する
データセンター向けのモデルを選択されるのが良いかと思います
・エージェント・アクティブについて
確かに、アクティブ処理はエージェント側１プロセスで処理されるようです
ログバースト等の事象発生や、UserParameter/モジュール等で収集に時間が掛かる処理があると
監視収集処理が詰まることもあるかと思います‥
パッシブ監視だと仰るとおりStartAgentsで複数プロセスにできるので
サーバ側のPollerも増やせば、遅滞は起こりにくいとは思います
逆に、サーバ側視点で見ると
特定ホストに対するパッシブ監視が想定を超えて詰まってしまうと
サーバ側のPollerプロセスが詰まった数だけBusyになってしまうので
Pollerプロセス不足によって他のホストの監視・収集にも影響を及ぼすことも起こり得てしまいます
が、アクティブ監視の場合は、当該ホストの監視・収集が詰まるのみで
他のホストの監視・収集には特に影響しません
また、データの連続性の観点でみると、中央サーバがダウンした際に
パッシブ監視項目は「そもそも問い合わせに行かないので監視結果も無し・歯抜け状態」になりますが
アクティブ監視項目は、エージェントが稼働している限りは収集し続けてくれていて
中央サーバ復旧後にまとめて報告が届く‥ということになります
（もちろんエージェント側のバッファ量を超えると欠落しますが‥
連続性観点で「データの欠落は少なくできる」というメリットがある代わりに
「サーバ側を再起動したりすると、全ホストから一斉にダウン時間中の報告がDoS攻撃のように届くことになるので
サーバ負荷が一気にあがってしまう」というような欠点もあります
このあたり、適宜使い分けかと思います‥
プロキシは、管理は煩雑になるものの、このバースト・欠落単位をある程度制御しやすく
小分けにできる‥という意味では有用かと思います
393959532 - 投稿数: 3
fripper さん
ありがとうございます。
大変詳細な情報を頂きまして、感謝しております。
関係者と相談してみます。