👨‍🚒 🤾 👩🏿‍🔬 Zabbixのスケーリング 🚄 ✍🏻 👨🏼

Zabbixを工業規模で使用する、または使用するつもりの人は、Zabbixが最終的に窒息および窒息する前にどれだけの実際のデータを「ダイジェスト」できるかという質問を常に心配しています。私の最近の仕事の一部はこの問題を扱っています。実際、32,000以上のノードを持つ巨大なネットワークがあり、Zabbixによって将来的に完全に監視される可能性があります。フォーラムでは、Zabbixを大規模に動作するように最適化する方法について長い間議論してきましたが、残念ながら、まだ完全な解決策を見つけることができませんでした。

この記事では、大量のデータを処理できるシステムのセットアップ方法を示したいと思います。あなたがそれが何であるかを理解するために、ここにシステムの統計を含む写真があります：

最初に、「必要なサーバーパフォーマンス、1秒あたりの新しい値（NVPS）」項目が実際に意味するものについて説明します。そのため、1秒間にシステムに入力される実際のデータの量とは一致しませんが、ポーリング間隔を考慮した、すべてのアクティブなデータ要素の単純な数学的計算です。そして、Zabbix-trapperは計算に関与していないことがわかりました。私たちのネットワークでは、トラッパーが非常に積極的に使用されていたため、問題の環境に実際のNVPSがいくつあるかを見てみましょう。

グラフに示すように、Zabbixは平均して1秒あたり約9,260のリクエストを処理します。さらに、ネットワーク上に最大15,000 NVPSの短いバーストがあり、サーバーは問題なく対処しました。正直なところ、これは素晴らしいです！

建築

最初に理解することは、監視システムのアーキテクチャです。 Zabbixはフォールトトレラントであるべきですか？ 1時間または2時間のダウンタイムが問題になりますか？データベースがクラッシュした場合、どのような結果が待っていますか？ベースにはどのドライブが必要で、どのRAIDを構成する必要がありますか？ ZabbixサーバーとZabbixプロキシ間の帯域幅はどのくらいですか？最大遅延とは何ですか？データを収集する方法は？ネットワークに問い合わせる（パッシブモニタリング）か、ネットワークをリッスンする（アクティブモニタリング）か？

各質問を詳しく見てみましょう。正直に言うと、システムを展開するときにネットワークの問題を考慮しなかったため、将来的に診断が困難な問題が発生しました。そのため、ここに監視システムアーキテクチャの一般的な概要を示します。

鉄

適切な鉄を見つけることは簡単なプロセスではありません。 Zabbixデータベースは大量のI / Oディスクシステムを必要とするため、ここで行った主なことはSANを使用してデータを保存することでした。簡単に言えば、データベースサーバー上のディスクが高速であるほど、Zabbixが処理できるデータが増えます。

もちろん、CPUとメモリもMySQLにとって非常に重要です。大量のRAMにより、Zabbixは頻繁に読み取られたデータをメモリに保存できます。これは当然、システムの速度に貢献します。当初、64GBのデータベースサーバーを計画していましたが、これまでのところすべてが32GBで正常に機能していました。

zabbix_server自体がインストールされているサーバーも、十分に高速なCPUを備えている必要があります。何十万ものトリガーを落ち着いて処理する必要があるためです。また、Zabbixサーバー自体には多くのプロセスがないため、12GBで十分なメモリになります（ほとんどすべての監視はプロキシ経由です）。

DBMSやzabbix_serverとは異なり、Zabbixプロキシは深刻なハードウェアを必要としないため、仮想マシンを使用しました。基本的に、アクティブなデータ要素が収集されるため、プロキシ自体はデータ収集ポイントとして機能しますが、プロキシ自体は実際には何も調査しません。

私のシステムで使用した要約表は次のとおりです。

Zabbixサーバー	Zabbix DB	Zabbixプロキシ	サン
HP ProLiant BL460c Gen8 12x Intel Xeon E5-2630 16GBメモリ 128GBディスク CentOS 6.2 x64 Zabbix 2.0.6	HP ProLiant BL460c Gen8 12x Intel Xeon E5-2630 32GBのメモリ 2TB SAN-backedストレージ（4Gbps FC） CentOS 6.2 x64 MySQL 5.6.12	VMware仮想マシン 4x vCPU 8GBメモリ 50GBのディスク CentOS 6.2 x64 Zabbix 2.0.6 MySQL 5.5.18	Hitachi Unified Storage VM 2TB LUN x 2 階層型ストレージ（2TB SSDを搭載）

フォールトトレランスZabbixサーバー

上で述べたアーキテクチャの問題に戻りましょう。大規模なネットワークでは、明らかな理由から、監視が機能しないことが実際の災害です。ただし、Zabbixアーキテクチャでは、zabbixサーバープロセスの複数のインスタンスを実行できません。

そこで、PacemakerとCMANでLinux HAを使用することにしました。基本的なセットアップについては、 RedHat 6.4マニュアルをご覧ください。残念ながら、命令は使用した時点から変更されましたが、最終的な結果は同じになるはずです。基本的なセットアップの後、さらに構成しました：

共有IPアドレス
1. feyloverの場合、IPアドレスはサーバーに送られ、サーバーがアクティブになります
2. 共有IPアドレスは常にアクティブなZabbixサーバーによって使用されるため、次の3つの利点があります。
  - どのサーバーがアクティブであるかを常に簡単に見つけることができます
  - Zabbixサーバーからのすべての接続は常に同じIPからです（zabbix_server.confでSourceIP =パラメーターを設定した後）
  - すべてのZabbixプロキシおよびZabbixエージェントは、サーバーとして共通のIPを使用するだけです
Zabbix_serverプロセス
- feyloverの場合、zabbix_serverは古いサーバーで停止され、新しいサーバーで開始されます
cronジョブのシンボリックリンク
1. Simlinkは、タスクが存在するディレクトリを指します。これは、アクティブなZabbixサーバーでのみ実行する必要があります。 Crontabは、このシンボリックリンクを介してすべてのタスクにアクセスできる必要があります
2. feyloverの場合、シンボリックリンクは古いサーバーで削除され、新しいサーバーで作成されます
crond
- feyloverの場合、crondは古いサーバーで停止し、新しいアクティブサーバーで起動します

構成ファイルの例と、zabbixサーバーのLSB initスクリプトは、こちらからダウンロードできます。「<>」で囲まれたパラメーターを忘れずに編集してください。さらに、すべてのZabbixファイルが同じフォルダー（/ usr / local / zabbix）にあるという事実を考慮して、initスクリプトが作成されます。そのため、必要に応じてスクリプト内のパスを調整します。

DBMSのフォールトトレランス

データベースがいつでもクラッシュする可能性がある場合、明らかにZabbixサーバーを備えたサーバーのフォールトトレランスの利点はありません。 MySQLには、クラスターを作成する方法が数多くあります。使用した方法について説明します。

また、Linux HAをPacemakerとCMANとともに、データベースに使用しました。結局のところ、MySQLレプリケーションを管理するための優れた機能がいくつかあります。アクティブ（マスター）とスタンバイ（スレーブ）MySQLの間でデータを同期するためにレプリケーションを使用します（使用、「未解決の問題」セクションを参照）。まず、Zabbixサーバーサーバーと同様に、基本的なクラスター構成を行います。次に、アドオンで以下を構成しました。

共有IPアドレス
1. feyloverの場合、IPアドレスはサーバーに送られ、サーバーがアクティブになります
2. 共有IPアドレスは常にアクティブなZabbixサーバーによって使用されるため、次の2つの利点があります。
  - どのサーバーがアクティブであるかを見つけるのは常に簡単です。
  - フェイルオーバーの場合、Zabbixサーバー自体で新しいアクティブなMySQLサーバーのアドレスを示すアクションは不要です
共通スレーブIPアドレス
1. このIPアドレスは、データベースへの読み取り要求が発生したときに使用できます。したがって、クエリは、使用可能な場合、MySQLスレーブサーバーによって処理できます。
2. どのサーバーにも追加のアドレスを設定できますが、次の条件に依存します。
  - スレーブサーバーが利用可能であり、クロックが60秒以上遅れない場合、アドレスを持ちます。
  - それ以外の場合、MySQLマスターサーバーのアドレスは
mysqld
- feyloverの場合、新しいMySQLサーバーがアクティブになります。その後、古いサーバーが動作に戻ると、すでに新しく作成されたマスターのスレーブのままになります。

設定ファイルの例は、ここで取得できます。「<>」で囲まれたペースメーカーパラメータを編集することを忘れないでください。また、ペースメーカーで使用するために別のMySQLリソースエージェントをダウンロードする必要があります。リンクは、Percona github リポジトリにペースメーカーを使用してMySQLクラスターをインストールするためのドキュメントに記載されています。また、「火災事故」の場合に備えて、コピーがここにあります。

Zabbixプロキシ

何らかの理由でZabbixプロキシについて聞いたことがない場合は、ドキュメントを早急にご覧ください。プロキシにより、Zabbixは複数のマシンに監視負荷を分散できます。その後、すべてのZabbixプロキシは、収集されたすべてのデータをZabbixサーバーに送信します。

Zabbixプロキシを使用する場合、次の点に注意することが重要です。

Zabbixプロキシは、適切に設定されていれば、非常に大量のデータを処理できます。そのため、たとえば、テスト中、プロキシ（プロキシAと呼びます）は1500-1750 NVPSを問題なく処理しました。これは、2つの仮想CPU、4GBのRAM、およびSQLite3データベースを備えた仮想マシンです。同時に、プロキシはサーバー自体と同じサイト上にあったため、ネットワークの遅延を単純に考慮することはできませんでした。また、収集されたほとんどすべてがアクティブなZabbixエージェントのデータ要素でした
前に、監視する際のネットワーク遅延がどれほど重要かを述べました。したがって、これは大規模システムの場合に当てはまります。実際、プロキシが遅れることなく送信できるデータの量は、ネットワークに直接依存します。

以下のグラフは、ネットワーク遅延を考慮しない場合に問題がどのように蓄積されるかを明確に示しています。時間がないプロキシ：

おそらく、送信用のデータからのキューが増加してはならないことは明らかです。グラフは別のZabbixプロキシ（プロキシB）を参照しますが、プロキシAとハードウェアの違いはありませんが、プロキシAのような1500NVPSではなく500NVPSのみを問題なく送信できます。違いは、Bがシンガポールとそれ自体にあることです。北米のサーバー、およびサイト間の遅延は約230ミリ秒です。データの送信方法を考えると、この遅延は深刻な影響を及ぼします。この場合、プロキシBは2〜3秒ごとに収集されたZabbix要素を1000個だけサーバーに送信できます。私の観察によれば、これは何が起こるかです：

プロキシはサーバーへの接続を確立します
最大プロキシは、一度に1000個の収集されたデータ項目値を送信します。
プロキシが接続を閉じます

この手順は、必要な回数だけ繰り返されます。大きな遅延の場合、この方法にはいくつかの重大な問題があります。

初期接続は非常に遅いです。私の場合、0.25秒で発生します。ふう！
1000個のデータ要素を送信した後に接続が閉じられるため、TCP接続はチャネルの利用可能なすべての帯域幅を使用するのに十分なほど長く続くことはありません。

データベースのパフォーマンス

収集されたすべての情報が確実にそこに到達するため、高いデータベースパフォーマンスが監視システムの鍵となります。同時に、データベースへの多数の書き込み操作を考えると、ディスクパフォーマンスが最初のボトルネックです。幸運にもSSDを自由に使用できましたが、それでもベースの高速動作を保証するものではありません。以下に例を示します。

最初は、システムでMySQL 5.5.18を使用しました。ただし、700-750 NVPS MySQLがプロセッサを100％でロードし始め、システムが文字通り「フリーズ」した後、最初は目に見えるパフォーマンスの問題は観察されませんでした。構成ファイルのパラメーターを変更したり、大きなページをアクティブにしたり、パーティションを作成したりして、状況を修正しようと試みたが、何も起こりませんでした。私の妻は、より良い解決策を提案しました。最初にMySQL 5.6にアップグレードしてから、それを見つけ出します。驚いたことに、簡単な更新ですべてのパフォーマンスの問題が解決されました。これは5.5.18では解決できませんでした。念のため、ここにmy.cnfのコピーを示します。

グラフは、データベース内の1秒あたりのリクエスト数を示しています。

ほとんどのリクエストは「Com_update」であることに注意してください。その理由は、受け取った各値が「アイテム」テーブルの更新につながるという事実にあります。データベースには主に書き込み操作もあるため、MySQLクエリキャッシュは役に立ちません。実際、リクエストを常に無効としてマークする必要があるため、パフォーマンスに悪影響を与える可能性さえあります。

別のパフォーマンスの問題は、Zabbix Housekeeperである可能性があります。大規模なネットワークでは、オフにすることを強くお勧めします。これを行うには、構成ファイルでDisableHousekeeping = 1を設定します。ハウスキーピングがなければ、古いデータ（データ要素、イベント、アクション）がデータベースから削除されないことは明らかです。その後、パーティション分割によって削除を整理できます。

ただし、MySQL 5.6.12の制限の1つは、外部キーを持つテーブルではパーティション化を使用できないことであり、Zabbixデータベースのほぼすべての場所に存在します。しかし、必要な履歴テーブルのほかに。パーティション化には2つの利点があります。

日/週/月/などで分割されたすべての履歴テーブルデータデータベースに影響を与えることなく、将来的にデータを削除できる別のファイルにすることができます。また、一定期間に収集されるデータ量を理解することも非常に簡単です。
テーブルをクリアした後、InnoDBはディスク容量を返さず、新しいデータ用にそれ自体を残します。その結果、InnoDBを使用してディスク領域をクリアすることはできません。パーティショニングの場合、これは問題ではなく、単に古いパーティションを削除するだけでスペースを解放できます。

Zabbiksでのパーティション分割については、すでにHabréで書かれています。

収集または聞く

Zabbixには、アクティブとパッシブの2つのデータ収集方法があります。Zabbixのパッシブ監視の場合、サーバー自体がZabbixエージェントをポーリングし、アクティブの場合、Zabbixエージェントがサーバー自体に接続するのを待機します。 Zabbixトラッパーも、ホスト側に送信開始が残っているため、アクティブな監視の対象となります。

いずれかの方法を主な方法として選択すると、パフォーマンスの違いが深刻になる可能性があります。パッシブモニタリングでは、Zabbixサーバーでプロセスを実行する必要があります。Zabbixサーバーは、Zabbixエージェントに定期的にリクエストを送信し、応答を待機します。場合によっては、待機が最大数秒遅れることもあります。この時間に少なくとも1000台のサーバーを掛けると、ポーリングに時間がかかることが明らかになります。

アクティブな監視の場合、ポーリングプロセスはありません。監視対象のデータ項目のリストを取得するためにエージェント自体がZabbixサーバーへの接続を開始すると、サーバーは待機状態になります。

さらに、エージェントは、サーバーから受信した間隔を考慮してデータ要素の収集を開始し、それらを送信しますが、接続は、エージェントに送信するものがある場合にのみ開かれます。したがって、データを受信する前に検証する必要はありません。これは、パッシブモニタリングに存在します。結論：アクティブモニタリングは、大規模ネットワークで必要なデータ収集の速度を向上させます。

Zabbix自身を監視する

Zabbix自体を監視しないと、大規模システムの効果的な運用はまったく不可能です。システムが新しいデータの受信を拒否したときに「プラグ」が発生する場所を理解することは非常に重要です。既存のZabbix監視データ要素は、ここにあります。 Zabbixのバージョン2.xでは、「箱から出してすぐに」提供されるZabbixサーバー監視テンプレートに親切に組み込まれました。それを使用してください！

有用なメトリックの1つは、History Write Cacheの空き領域（サーバー構成ファイルのHistoryCacheSize）です。このパラメーターは常に100％に近い値にする必要があります。キャッシュがいっぱいの場合、Zabbixに着信データをデータベースに追加する時間がありません。

残念ながら、このオプションはZabbixプロキシではサポートされていません。さらに、Zabbixには、Zabbixサーバーへの送信を待機しているデータ量を示すデータ要素はありません。ただし、このデータ項目は、プロキシデータベースへのSQLクエリを使用して簡単に実行できます。

SELECT ((SELECT MAX(proxy_history.id) FROM proxy_history)-nextid) FROM ids WHERE field_name='history_lastid'

要求は、必要な数を返します。 ZabbixプロキシのデータベースとしてSQLite3を使用している場合、Zabbixプロキシが実行されているマシンにインストールされているZabbixエージェントの設定ファイルにUserParameterとして次のコマンドを追加するだけです。

UserParameter=zabbix.proxy.items.sync.remaining,/usr/bin/sqlite3 /path/to/the/sqlite/database "SELECT ((SELECT MAX(proxy_history.id) FROM proxy_history)-nextid) FROM ids WHERE field_name='history_lastid'" 2>&1

次に、プロキシが対処していないことを通知するトリガーを配置します。

{Hostname:zabbix.proxy.items.sync.remaining.min(10m)}>100000

総統計

最後に、システム負荷グラフを提案します。 7月16日に何が起こったのかわからないとすぐに言います。問題を解決するために、すべてのプロキシデータベース（当時のSQLite）を再作成する必要がありました。それ以来、すべてのプロキシをMySQLに変換しましたが、問題は繰り返されていません。グラフの残りの「不規則性」は、負荷テストの時間と一致します。一般に、グラフは、使用される鉄に大きな安全マージンがあることを示しています。

次に、データベースサーバーからのグラフを示します。毎日のトラフィックの増加は、ダンプの時間（mysqldump）に対応しています。また、クエリグラフ（qps）の7月16日の失敗は、上記で説明したのと同じ問題に関連しています。

運営管理

合計で、システムは、Zabbixサーバー用に2台のサーバー、MySQL用に2台のサーバー、Zabbixプロキシ用に16台の仮想サーバー、Zabbixエージェントを備えた数千の監視対象サーバーを使用します。ホストが非常に多いため、手作業で変更を加えることに疑問の余地はありませんでした。そして、ソリューションはGitリポジトリであり、すべてのサーバーがアクセスでき、すべての構成ファイル、スクリプト、および配布する必要のあるすべてのものを配置しました。次に、エージェントのUserParameterを介して呼び出されるスクリプトを作成しました。スクリプトの実行後、サーバーはGitリポジトリに接続し、必要なすべてのファイルと更新をダウンロードし、設定ファイルに変更があった場合はZabbixエージェント/プロキシ/サーバーを再起動します。更新はzabbix_getを実行するより難しくありません！

Webインターフェイスを介して手動で新しいホストを作成することも、非常に多くのサーバーを使用する方法ではありません。当社にはCMDBがあり、そこに提供されるすべてのサーバーとサービスに関する情報が含まれています。そのため、別のマジックスクリプトが1時間ごとにCMDBから情報を収集し、それをZabbixにあるものと比較します。この比較の結論として、スクリプトはホストを削除/追加/オン/オフし、グループホストを作成し、テンプレートをホストに追加します。この場合、手動で行う必要があるのは、新しいタイプのトリガーまたはデータ要素の実装だけです。残念ながら、これらのスクリプトはシステムに強く結び付けられているため、共有できません。

未解決の問題

私が行ったすべての努力にもかかわらず、まだ解決していない重要な問題が1つ残っています。実際、システムが8000-9000NVPSに達すると、バックアップMySQLデータベースはメインデータベースに追い付かないため、実際にはフォールトトレランスはありません。

この問題を解決する方法はありますが、まだ実装する時間がありません。

データベースのパーティション分割には、DRBDでLinux-HAを使用します。
別のLUNへのレプリケーションを使用したSANでのLUNレプリケーション
Percona XtraDBクラスター。バージョン5.6ではまだ利用できないため、待つ必要があります（私が書いたように、MySQL 5.5にはパフォーマンスの問題がありました）

Zabbixのスケーリング

建築

鉄