高パフォーマンスとネイティブ パーティショニング: TimescaleDB をサポートする Zabbix

Zabbix は監視システムです。 他のシステムと同様に、すべての監視システムの XNUMX つの主要な問題、つまりデータの収集と処理、履歴の保存、およびクリーニングという問題に直面しています。

データの受信、処理、記録の段階には時間がかかります。 それほど大きなことではありませんが、大規模なシステムの場合、これにより大きな遅延が発生する可能性があります。 ストレージの問題はデータ アクセスの問題です。 これらはレポート、チェック、トリガーに使用されます。 データ アクセスの遅延もパフォーマンスに影響します。 データベースが大きくなると、無関係なデータを削除する必要があります。 削除は難しい操作であり、リソースも消費します。

Zabbix での収集および保存中の遅延の問題は、キャッシュによって解決されます。いくつかの種類のキャッシュ、データベース内のキャッシュです。 XNUMX番目の問題を解決するには、キャッシュは適さないため、ZabbixはTimescaleDBを使用しました。 彼がそれについて教えてくれるでしょう アンドレイ・グシュチン - テクニカルサポートエンジニア Zabbix SIA。 Andrey は 6 年以上 Zabbix をサポートしており、パフォーマンスに関する直接の経験があります。

TimescaleDB はどのように動作し、通常の PostgreSQL と比較してどのようなパフォーマンスが得られますか? Zabbix は TimescaleDB データベースに対してどのような役割を果たしますか? ゼロから始める方法と PostgreSQL から移行する方法、そしてどの構成の方がパフォーマンスが良いか? このすべてについてはカットの下で。

生産性の課題

すべての監視システムは、特定のパフォーマンスの課題に直面しています。 そのうちの XNUMX つ、データの収集と処理、ストレージ、履歴の消去について説明します。

高速なデータ収集と処理。 優れた監視システムは、すべてのデータを迅速に受信し、トリガー式に従って、その基準に従って処理する必要があります。 処理後、システムはこのデータを後で使用できるようにデータベースに迅速に保存する必要もあります。

履歴ストレージ。 優れた監視システムでは、履歴をデータベースに保存し、メトリクスに簡単にアクセスできるようにする必要があります。 履歴は、レポート、グラフ、トリガー、しきい値、および計算されたアラート データ項目で使用するために必要です。

履歴をクリアします。 場合によっては、メトリクスを保存する必要がなくなる日が来ることがあります。 なぜ 5 年前、XNUMX ～ XNUMX か月前に収集されたデータが必要なのでしょうか。一部のノードは削除されており、一部のホストまたはメトリクスは古くなって収集されなくなったため不要になっています。 優れた監視システムでは、データベースが増大しないように履歴データを保存し、時々削除する必要があります。

古いデータのクリーンアップは、データベースのパフォーマンスに大きな影響を与える重要な問題です。

Zabbix でのキャッシュ

Zabbix では、最初と XNUMX 番目の呼び出しはキャッシュを使用して解決されます。 RAM はデータの収集と処理に使用されます。 ストレージ用 - トリガー、グラフ、計算されたデータ要素の履歴。 データベース側では、グラフなどの基本的な選択に対してキャッシュが行われます。

Zabbix サーバー自体の側でのキャッシュは次のとおりです。

• 構成キャッシュ;
• 値キャッシュ;
• 履歴キャッシュ;
• トレンドキャッシュ。

それらをより詳細に検討してください。

構成キャッシュ

これは、メトリクス、ホスト、データ項目、トリガーなど、前処理とデータ収集に必要なものすべてを保存するメイン キャッシュです。

データベース内に不要なクエリが作成されないように、これらはすべて ConfigurationCache に保存されます。 サーバーの起動後、このキャッシュを更新し、構成を作成し、定期的に更新します。

データ収集

この図は非常に大きいですが、その中の主なものは次のとおりです。 コレクター。 これらはさまざまな「ポーラー」、つまり組み立てプロセスです。 これらはさまざまなタイプのアセンブリを担当し、SNMP、IPMI 経由でデータを収集し、それをすべて PreProcessing に転送します。

コレクターはオレンジ色の枠で囲まれています。

Zabbix には、チェックを集計するために必要な集計項目が計算されています。 それらがある場合は、そのデータを ValueCache から直接フェッチします。

前処理履歴キャッシュ

すべてのコレクターは、ConfigurationCache を使用してジョブを受信します。 次に、それらを前処理に転送します。

PreProcessing は、ConfigurationCache を使用して PreProcessing ステップを受け取ります。 このデータはさまざまな方法で処理されます。

PreProcessing を使用してデータを処理した後、処理のために HistoryCache にデータを保存します。 これでデータ収集が終了し、Zabbix のメインプロセスに進みます。 履歴同期装置モノリシックアーキテクチャなので。

注: 前処理は非常に難しい操作です。 v 4.2 ではプロキシに移動されました。 多数のデータ要素と収集頻度を備えた非常に大規模な Zabbix がある場合、これにより作業がはるかに簡単になります。

ValueCache、履歴とトレンドのキャッシュ

History Syncer は、各データ要素、つまり各値をアトミックに処理するメインプロセスです。

履歴同期機能は、HistoryCache から値を取得し、計算用のトリガーの存在について構成をチェックします。 存在する場合は計算されます。

履歴同期機能は、イベント、設定で必要な場合にアラートを作成するためのエスカレーション、および記録を作成します。 後続の処理のトリガーがある場合は、履歴テーブルにアクセスしないように、この値を ValueCache に保存します。 このようにして、トリガーと計算要素の計算に必要なデータが ValueCache に格納されます。

履歴同期機能はすべてのデータをデータベースに書き込み、ディスクに書き込みます。 以上で加工処理は終了となります。

データベース内のキャッシュ

イベントに関するグラフやレポートを表示する場合、データベース側にはさまざまなキャッシュがあります。

• Innodb_buffer_pool MySQL 側。
• shared_buffers PostgreSQL 側。
• effective_cache_size オラクル側。
• shared_pool DB2側。

他にも多くのキャッシュがありますが、これらはすべてのデータベースの主要なものです。 これらを使用すると、クエリによく必要となるデータを RAM に保存できます。 彼らはこのための独自の技術を持っています。

データベースのパフォーマンスは重要です

Zabbix サーバーは常にデータを収集し、書き込みます。 再起動すると、履歴から読み取り、ValueCache に書き込みます。 スクリプトとレポートを使用する Zabbix API、Web インターフェイス上に構築されています。 Zabbix APIはデータベースにアクセスし、グラフ、レポート、イベントリスト、最新号などに必要なデータを取得します。

視覚化のために - グラファナ。 これはユーザーの間で人気のあるソリューションです。 Zabbix API を介してデータベースにリクエストを直接送信でき、データの受信に関して一定の競合が発生します。 したがって、結果とテストを迅速に提供するには、データベースをより細かく、より適切に調整する必要があります。

お手伝いさん

Zabbix における XNUMX 番目のパフォーマンスの課題は、Housekeeper を使用した履歴のクリアです。 これはすべての設定に従います。データ要素は、変化のダイナミクス (傾向) を保存する期間を日単位で示します。

TrendsCache をその場で計算します。 データが到着すると、それを XNUMX 時間集計し、傾向変化のダイナミクスを表に記録します。

ハウスキーパーは、通常の「選択」を使用してデータベースから情報を開始および削除します。 内部プロセスのパフォーマンス グラフからわかるように、これは常に効果的であるとは限りません。

赤いグラフは、履歴同期機能が常にビジー状態であることを示しています。 上部のオレンジ色のグラフは、常に実行されている Housekeeper です。 彼は、データベースが指定したすべての行を削除するのを待ちます。

ハウスキーパーを無効にする必要があるのはどのような場合ですか? たとえば、「アイテム ID」があり、一定期間内に最後の 5 行を削除する必要があるとします。 もちろん、これはインデックスによって行われます。 ただし、通常、データセットは非常に大きく、データベースは依然としてディスクから読み取り、それをキャッシュに置きます。 これは常にデータベースにとって非常にコストのかかる操作であり、データベースのサイズによってはパフォーマンスの問題を引き起こす可能性があります。

ハウスキーパーを無効にするのは簡単です。 Web インターフェースの「管理全般」にハウスキーパー用の設定があります。 内部トレンド履歴の内部ハウスキーピングを無効にし、管理されなくなりました。

ハウスキーパーがオフになり、グラフは平準化されました。この場合、どのような問題が考えられますか?また、XNUMX 番目のパフォーマンスの課題の解決に何が役立つでしょうか?

パーティショニング - パーティショニングまたはパーティショニング

通常、パーティショニングは、リストした各リレーショナル データベースで異なる方法で構成されます。 それぞれに独自のテクノロジーがありますが、一般的には似ています。 新しいパーティションを作成すると、特定の問題が発生することがよくあります。

通常、パーティションは「セットアップ」、つまり 1 日に作成されるデータの量に応じて構成されます。 原則として、パーティショニングは XNUMX 日で発行されます。これは最小限です。 新しいバッチの傾向については、XNUMX か月です。

「設定」が非常に大きい場合、値が変わる可能性があります。 小規模な「セットアップ」が最大 5 nvps (000 秒あたりの新しい値) である場合、中規模の「セットアップ」は 5 ～ 000、大規模な「セットアップ」は 25 nvps を超えます。 これらは大規模および非常に大規模なインストールであり、データベースの慎重な構成が必要です。

非常に大規模なインストールでは、40 日という期間は最適ではない可能性があります。 XNUMX 日あたり XNUMX GB 以上の MySQL パーティションを見たことがあります。 これは非常に大量のデータであり、問​​題を引き起こす可能性があるため、削減する必要があります。

パーティショニングによって何が得られるのでしょうか?

テーブルのパーティショニング。 多くの場合、これらはディスク上の別個のファイルです。 クエリ プランは、XNUMX つのパーティションをより最適に選択します。 通常、パーティショニングは範囲によって使用されます。これは Zabbix にも当てはまります。 そこでは「タイムスタンプ」、つまり時代の始まりからの時間を使用します。 これらは私たちにとっては普通の数字です。 一日の始まりと終わりを設定します。これがパーティションです。

素早い取り外し - DELETE。 削除する行を選択するのではなく、XNUMX つのファイル/サブテーブルが選択されます。

データ検索を大幅に高速化 SELECT - テーブル全体ではなく、XNUMX つ以上のパーティションを使用します。 XNUMX 日前のデータにアクセスする場合、大きなテーブルではなく XNUMX つのファイルをキャッシュにロードして返すだけでよいため、データベースからのデータの取得が速くなります。

多くの場合、多くのデータベースも高速化されます INSERT — 子テーブルへの挿入。

タイムスケールDB

v 4.2 では、TimescaleDB に注目しました。 これは、ネイティブ インターフェイスを備えた PostgreSQL の拡張機能です。 この拡張機能は、リレーショナル データベースの利点を損なうことなく、時系列データを効果的に処理します。 TimescaleDB は自動的にパーティション分割も行います。

TimescaleDBには概念があります ハイパーテーブル あなたが作成する (ハイパーテーブル)。 を含む チャンク - パーティション。 チャンクは自動的に管理されるハイパーテーブル フラグメントであり、他のフラグメントには影響を与えません。 各チャンクには独自の時間範囲があります。

TimescaleDB と PostgreSQL

TimescaleDB は非常に効率的に機能します。 この拡張機能の製造元は、より正確なクエリ処理アルゴリズム、特にinserts使用していると主張しています。 データセットの挿入サイズが大きくなっても、アルゴリズムは一定のパフォーマンスを維持します。

通常、200 億行を超えると、PostgreSQL は大幅に低下し始め、パフォーマンスが 0 まで低下します。TimescaleDB を使用すると、任意の量のデータに対して効率的に「挿入」を挿入できます。

インストール

TimescaleDB のインストールは、どのパッケージでも非常に簡単です。 で ドキュメンテーション すべてが詳細に説明されています - 公式の PostgreSQL パッケージに依存します。 TimescaleDB は手動で構築およびコンパイルすることもできます。

Zabbix データベースの場合は、拡張機能をアクティブ化するだけです。

echo "CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE;" | sudo -u postgres psql zabbix

あなたがアクティブ化します extension Zabbix データベース用に作成します。 最後のステップはハイパーテーブルを作成することです。

履歴テーブルを TimescaleDB に移行する

これには特別な機能があります create_hypertable:

SELECT create_hypertable(‘history’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_log’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_text’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘history_str’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
SELECT create_hypertable(‘trends_unit’, ‘clock’, chunk_time_interval => 86400, migrate_data => true);
UPDATE config SET db_extension=’timescaledb’, hk_history_global=1, hk_trends_global=1

この関数には XNUMX つのパラメータがあります。 初め - データベース内のテーブル、ハイパーテーブルを作成する必要があります。 XNUMX番 - フィールド、それに応じて作成する必要があります chunk_time_interval — 使用されるパーティション チャンクの間隔。 私の場合、間隔は 86 日 - 400 です。

XNUMX番目のパラメータ - migrate_data。 設定した場合 true、その後、現在のすべてのデータが事前に作成されたチャンクに転送されます。 自分でも使ったんですが migrate_data。 約 1 TB ありましたが、XNUMX 時間以上かかりました。 場合によっては、テスト中に保管に必要のない文字種の履歴データを削除して、転送しないようにしました。

最後のステップ - UPDATEで： db_extension 置く timescaledbこれにより、データベースはこの拡張機能が存在することを認識できるようになります。 Zabbix はそれをアクティブにし、構文とデータベースへのクエリを正しく使用します。これらの機能は TimescaleDB に必要です。

ハードウェア構成

XNUMX台のサーバーを使用しました。 初め - VMware マシン。 非常に小型です: 20 個の Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz プロセッサー、16 GB の RAM、および 200 GB SSD。

Debian 10.8-10.8.pgdg1+90 OSとxfsファイルシステムを使用してPostgreSQL 1をインストールしました。 Zabbix 自体が使用するものを除いて、この特定のデータベースを使用するためにすべてを最小限に構成しました。

同じマシン上に Zabbix サーバー、PostgreSQL、および ロードエージェント。 50 のアクティブなエージェントが使用していました LoadableModuleさまざまな結果 (数値、文字列) を非常に迅速に生成します。 データベースに大量のデータを詰め込みました。

最初に含まれていた構成は 5の要素 ホストごとのデータ。 ほぼすべての要素に、実際のインスタレーションと同様にするためのトリガーが含まれていました。 場合によっては、複数のトリガーがあった場合もあります。 XNUMX つのネットワーク ノードについては、 3 ～ 000 トリガー.

データ項目の更新間隔 - 4-7秒。 エージェントを 50 個だけではなく、さらに追加することで負荷自体を調整しました。 また、データ要素を使用して負荷を動的に調整し、更新間隔を 4 秒に短縮しました。

ポストグレSQL。 35 nvps

このハードウェアでの最初の実行は純粋な PostgreSQL でした - 35 秒あたり 200 の値。 ご覧のとおり、データの挿入にはほんの数秒しかかかりません。すべてが良好で高速です。 唯一の問題は、XNUMX GB SSD ディスクがすぐにいっぱいになってしまうことです。

これは、標準の Zabbix サーバー パフォーマンス ダッシュボードです。

最初の青いグラフは、XNUMX 秒あたりの値の数です。 右側の XNUMX 番目のグラフは、ビルド プロセスの読み込みを示しています。 XNUMX 番目は、内部ビルド プロセスの読み込みです。履歴同期機能と Housekeeper は、かなり長い間ここで実行されています。

XNUMX 番目のグラフは、HistoryCache の使用状況を示しています。 これはデータベースに挿入する前の一種のバッファです。 緑色の XNUMX 番目のグラフは、ValueCache の使用状況、つまりトリガーに対する ValueCache のヒット数を示します。これは XNUMX 秒あたり数千の値です。

ポストグレSQL。 50 nvps

次に、同じハードウェアで負荷を 50 秒あたり XNUMX の値に増加しました。

Housekeeper からロードする場合、10 個の値を挿入するのに 2 ～ 3 秒かかりました。

家政婦はすでに仕事に支障をきたし始めています。

60 番目のグラフは、一般に、トラッパーと履歴同期の負荷が依然として 20% であることを示しています。 0,5 番目のグラフでは、Housekeeper の操作中に HistoryCache がすでにかなり活発に埋められ始めています。 XNUMX% がいっぱい、つまり約 XNUMX GB です。

ポストグレSQL。 80 nvps

次に、負荷を 80 秒あたり 400 値に増加しました。 これは、約 280 万のデータ要素と XNUMX 万のトリガーに相当します。

XNUMX 個の履歴同期の読み込みコストはすでにかなり高くなります。

また、履歴同期機能やキャッシュなど、さまざまなパラメーターも増やしました。

私のハードウェアでは、履歴同期機能の負荷が最大まで増加しました。 HistoryCache はすぐにデータでいっぱいになり、処理用のデータがバッファに蓄積されました。

この間ずっと、プロセッサ、RAM、その他のシステム パラメータがどのように使用されているかを観察し、ディスク使用率が最大になっていることがわかりました。

用途を達成しました 最大ディスク容量 このハードウェアとこの仮想マシン上で。 このような激しさにより、PostgreSQL は非常に活発にデータをフラッシュし始め、ディスクには書き込みと読み取りを行う時間がなくなりました。

セカンドサーバー

私は別のサーバーを使用しましたが、そこにはすでに 48 個のプロセッサと 128 GB の RAM が搭載されていました。 私はそれを調整し、60 履歴同期に設定し、許容可能なパフォーマンスを達成しました。

実際、何かを行う必要がある場合、これはすでに生産性の限界です。

タイムスケールDB。 80nvps

私の主なタスクは、Zabbix の負荷に対して TimescaleDB の機能をテストすることです。 80秒あたりXNUMX万の値は多く、メトリクスを収集する頻度（もちろんYandexを除く）、そしてかなり大規模な「セットアップ」です。

どのグラフにもくぼみがあります。これはまさにデータの移行です。 Zabbix サーバーで障害が発生した後、履歴同期装置の読み込みプロファイルが大幅に変更され、XNUMX 回ドロップされました。

TimescaleDB を使用すると、ほぼ 3 倍の速さでデータを挿入し、HistoryCache の使用量を減らすことができます。

したがって、タイムリーにデータを受け取ることができます。

タイムスケールDB。 120nvps

次に、データ要素の数を 500 に増やし、主なタスクは TimescaleDB の機能をテストすることでした - 125 秒あたり XNUMX の値という計算値を受け取りました。

これは、長期間にわたって機能する有効な「セットアップ」です。 しかし、私のディスクは 1,5 TB しかなかったので、数日でいっぱいになりました。

最も重要なことは、同時に新しい TimescaleDB パーティションが作成されたことです。

これはパフォーマンス上はまったく問題ありません。 たとえば、MySQL でパーティションが作成される場合は、すべてが異なります。 これは通常、一般的な挿入やテーブルの操作をブロックし、サービスの低下を引き起こす可能性があるため、夜間に発生します。 TimescaleDB の場合はそうではありません。

例として、コミュニティ内の多くのグラフから XNUMX つのグラフを示します。 この図では、TimescaleDB が有効になっています。これにより、プロセッサーで io.weight を使用する際の負荷が軽減されました。 内部プロセス要素の使用も減少しました。 さらに、これは SSD ではなく、通常のパンケーキ ディスク上の通常の仮想マシンです。

所見

TimescaleDB は小規模な「セットアップ」に適したソリューションです、ディスクのパフォーマンスに影響を与えます。 これにより、データベースができるだけ早くハードウェアに移行されるまで、正常に作業を続けることができます。

TimescaleDB は構成が簡単で、パフォーマンスが向上し、Zabbix とうまく連携し、 PostgreSQL よりも優れている.

PostgreSQL を使用していて、変更する予定がない場合は、次をお勧めします。 TimescaleDB 拡張機能を備えた PostgreSQL を Zabbix と組み合わせて使用​​する。 このソリューションは、中程度の「セットアップ」までは効果的に機能します。

私たちが言う「高性能」とは、 HighLoad ++。 何百万人ものユーザーにサービスを提供できるようにするテクノロジーと実践方法について学ぶのに、それほど長くはかかりません。 リスト レポート 7月8日とXNUMX日についてはすでにまとめていますが、ここでは 交流会 さらに提案することができます。

購読してください ニュースレター и 電報では、今後のカンファレンスの特徴を明らかにし、それを最大限に活用する方法を見つけます。

出所： habr.com