運用および保守の監視シナリオでOpenTSDBからTDengineに移行する方法

OpenTSDBは、古典的な時系列データベースシステムです。独自のストレージエンジンを開発していませんが、HBaseに基づいています。すでにHBaseの基本サービスを利用している企業の場合、しきい値は低くなります。また、先発者の利点のおかげで、OpenTSDBには、運用および保守の監視の分野で多くのアプリケーションがあります。ただし、HBaseに依存しているため、システムのパフォーマンスと圧縮効率が徐々にボトルネックになっています。ビジネスシステムの規模の拡大に伴い、導入コストと運用効率の問題はますます深刻になっています。さらに、OpenTSDBの機能アップグレードは比較的遅いです。それと比較して、TDengineには明らかな利点があります。

データの書き込みとクエリのパフォーマンスは、OpenTSDBのパフォーマンスをはるかに上回っています。
時系列データの効率的な圧縮メカニズム。圧縮後のディスク上のストレージスペースは、OpenTSDBの1/5未満です。
インストールと展開は非常に簡単です。単一のインストールパッケージでインストールと展開が完了します。Goオペレーティング環境に依存する必要があるtaosAdapterを除いて、他のサードパーティソフトウェアに依存しません。インストールと展開全体は非常に簡単です。速い;
提供される組み込み関数は、OpenTSDBでサポートされるすべてのクエリ関数をカバーし、さらに多くの時系列データクエリ関数、スカラー関数、および集計関数をサポートし、複数の時間ウィンドウ集計、結合クエリ、式操作、複数のグループ化集計、ユーザーをサポートします。ソートなどの定義済みの高度なクエリ機能、およびユーザー定義関数。SQLのような文法規則を使用すると、学習がより簡単になり、基本的に学習コストがかかりません。
最大128個のタグをサポートし、タグの全長は16KBに達する可能性があります。
HTTPに加えて、Java、Python、C、Rust、Go、およびその他の言語のインターフェースも提供します。

OpenTSDBで最初に実行されていたアプリケーションをTDengineに移行すると、コンピューティングリソースとストレージリソースの占有を効果的に削減し、展開サーバーの規模を削減できるだけでなく、運用と保守のコストを大幅に削減して、運用と保守の管理作業を簡素化できます。簡単かつ劇的に総所有コストを削減します。

この記事では、「最も一般的で広く使用されている運用および保守の監視シナリオ」を使用して、コードを1行も記述せずに、OpenTSDBベースのアプリケーションをTDengineに迅速、安全、確実に移行する方法を説明します。

1.一般的な運用および保守監視アプリケーションのシナリオ

次の図に、一般的な運用および保守監視アプリケーションシナリオの全体的なシステムアーキテクチャを示します（図1）。

図1.運用および保守の監視シナリオの一般的なアーキテクチャ

このアプリケーションシナリオでは、マシンメトリクス（メトリクス）、ネットワークメトリクス（メトリクス）、アプリケーションメトリクス（メトリクス）の収集を担当するアプリケーション環境にデプロイされたエージェントツール、エージェントによって収集された情報を集約するデータコレクター、およびデータを担当するエージェントツールがあります。永続性ストレージおよび管理システムと監視データ視覚化ツール（例：Grafanaなど）。

その中で、アプリケーションノードにデプロイされたエージェントは、さまざまなソースからcollectd / Statsdに操作インジケーターを提供し、collectd / StatsDは、集約されたデータをOpenTSDBクラスターシステムにプッシュし、Grafanaを使用してデータを視覚化する役割を果たします。

2.移行サービス

TDengineのインストールと展開

1つ目はTDengineのインストールです。公式Webサイトから最新の安定バージョンのTDengineをダウンロードし、解凍してinstall.shを実行してインストールします。さまざまなインストールパッケージの使用ヘルプについては、「TDengineのさまざまなインストールパッケージのインストールとアンインストール」を参照してください。インストールの完了後、すぐにtaosdサービスを開始せず、パラメーターが正しく構成された後に開始することに注意してください。

データコレクターの構成を調整する

TDengine 2.3バージョンでは、バックグラウンドサービスtaosdが開始された後、taosAdapterと呼ばれるHTTPサービスも自動的に有効になります。taosAdapterを使用すると、InfluxdbのLineProtocolおよびOpenTSDBのtelnet/ Json書き込みプロトコルと互換性があるため、collectdおよびStatsDによって収集されたデータをTDengineに直接プッシュできます。

collectdを使用する場合は/etc/collectd/collectd.conf、デフォルトの場所にある構成ファイルを変更して、taosAdapterがデプロイされているノードのIPアドレスとポートを指すようにします。taosAdapterのIPアドレスが192.168.1.130で、ポートが6046であるとすると、構成は次のようになります。

LoadPlugin write_tsdb
<Plugin write_tsdb>
    <Node>
        Host "192.168.1.130"
        Port "6046"
        HostTags "status=production"
        StoreRates false
        AlwaysAppendDS false
    </Node>
</Plugin>

このようにして、collectdはtaosAdapterを介してTDengineにデータを書き込むことができます。StatsDを使用している場合は、それに応じて構成ファイルを調整できます。

Dashboradシステムの調整

データをTDengineに正常に書き込むことができたら、Grafanaを調整および適合させて、TDengineに書き込まれるデータを視覚化できます。TDengineのインストールディレクトリにGrafana用の接続プラグイン（コネクタ/ grafanaplugin）があります。使い方は簡単です：

まず、grafanapluginディレクトリの下のdistディレクトリ全体をGrafanaプラグインディレクトリ（デフォルトのアドレスは/var/lib/grafana/plugins/）にコピーしてから、Grafanaを再起動すると、[データソースの追加]メニューにTDengineデータソースが表示されます。

さらに、TDengineには、ユーザーがTDengineライブラリに保存されている情報をすばやく表示するための2セットのデフォルトのダッシュボードテンプレートも用意されています。Grafanaにインポートしてアクティブ化するだけです。

図2.Grafanaテンプレートのインポート

これまでに、OpenTSDBをTDengineに置き換えるための移行が完了しました。プロセス全体が非常に単純で、コードを記述する必要がなく、特定の構成ファイルを調整するだけであることがわかります。

3.移行後のアーキテクチャ

移行が完了した後の、この時点でのシステムの全体的なアーキテクチャを次の図に示します（図3）。プロセス全体を通じて、収集終了、データ書き込み終了、および監視と表示の終了は安定しています。いくつかの構成の調整を除いて、重要な変更や変更は含まれていません。

図3.移行後のシステムアーキテクチャ

OpenTSDBの主なアプリケーションシナリオは、運用と保守の監視です。この場合、TDengineのより強力な処理能力とクエリパフォーマンスを使用するために、TDengineへの移行を簡単に完了することができます。

ほとんどの運用および保守監視シナリオでは、監視データのストレージ側として小規模のOpenTSDBクラスター（3ノード以下）があり、OpenTSDBが提供するデータストレージおよびクエリ機能に依存している場合は、TDengineおよびより多くのコンピューティングおよびストレージリソースを節約します。同じコンピューティングリソース構成の下で、単一のTDengineが3〜5個のOpenTSDBノードによって提供されるサービス機能を実現できます。規模が比較的大きい場合は、TDengineクラスターを使用する必要があります。

アプリケーションが特に複雑な場合、またはアプリケーションドメインが運用および保守の監視シナリオではない場合は、次の記事を読み続けて、OpenTSDBアプリケーションのTDengineへの移行に関する高度なトピックをより包括的かつ詳細に理解することができます。