こんにちは。サイオステクノロジー OSS サポート担当 山本です。 今回は OpenTelemetry について、他の「監視」関連の OSS を交えながら概要をざっくり見ていこうと思います。 ■OpenTelemetry ってなんだ？ OpenTelemetry は、Linux Foundation 傘下のプロジェクト CNCF (Cloud Native Computing Foundation) から生まれた OSS で、 「 Observability (可観測性)」と呼ばれるものの実現・標準化を目指した フレームワーク です。 ■そもそも Observability ってなんだ？ Observability (可観測性) は、 システムの状態を観測・分析 できるかどうかを示す指標です。 転じて、 システムの状態を観測するため に 情報を出力・収集できるようにする のを目指した機能やソフトウェアの役割 (カテゴリ) のことを指します。 概ねの目的・方向性は「監視 (Monitoring)」と似通っていますが、複数システムでの連携 (クラウド等含む) によるシステムの複雑化などに対応して、 システム内部の処理なども含めて より広範に・より詳細に情報収集する ことを目指したものです。 雑に言えば「すごい監視」と思っておけば、そう外れた認識ではないでしょう。 OpenTelemetry では、 　・ トレース ：一連の処理の追跡記録 (複数サービスを跨ぐ場合でも追跡可) 　・ メトリクス ：システムリソースの状況などの測定値 　・ ログ ：ログ を観測できるようにすることで、Observability の実現を目指しています。 ■ざっくり理解する OpenTelemetry この OpenTelemetry ですが、単体で見ても何をするのかわかりにくい……というか 単体では機能しない ものだったりします。 なので今回は、他の「監視」ツールの極めて大まかな概要を合わせて見ることにより OpenTelemetry がどんなものかを見ていこうと思います。 ■参考：超ざっくり見る「他の “監視” ツール」 ということで、まずは脇道。”監視” ツールについてざっくり見ていきます。 これは先述のとおり Observability と似通っており、「 システムに関する情報を収集して閲覧できるようにする 」ことを目指したソフトウェアのカテゴリです。 “監視” ツールにも色々ありますが、大枠としては基本的には 　・情報の 収集 ：システムから必要な情報を収集する 　・情報の 転送 ：情報を保存する機構を持つプロセスへ収集した情報を転送する 　・情報の 保存 ：情報をデータベースなどに保存する 　・情報の 可視化 ：データベースなどに保存された情報をユーザが閲覧しやすい形で表示する という4つの役割をまとめたものになります。 もちろんこれはあくまで全体的な傾向の話であり、個々のツールを掘り下げていけば色々な違いはあります。 （「収集：”監視対象のコードへ監視用コード埋め込む” か “ツールによる監視” かなど」「転送：”収集側と一体化した Push 型” か “保存側と一体化した Pull 型” かなど」…などなど） また、 一部機能を切り捨て て、切り捨てた部分は 他のツールに任せる という思い切った構造をしているツールもたまにあります。 これの有名な例としては、 「可視化」以外の機能を切り捨てている “Grafana” が挙げられます。 ■本題：超ざっくり見る OpenTelemetry では OpenTelemetry に目を向けてみましょう。 先述のとおり、OpenTelemetry も目的・方向性は “監視” ツールとほぼ同じであり、先に見た 4つの役割 (情報の「収集・転送・保存・可視化」) が必要になるはずです。 それでは OpenTelemetry が何をするかと言うと…… 　・情報の 収集 ： 監視対象コードに組み込む API により必要な情報を出力 + それを 収集するプロセス “コレクター” 　・情報の 転送 ： “コレクター” から独自規格 “OTLP (OpenTeLemetry Protocol)” で転送 ……までです。 そう。OpenTelemetry は “4つの役割” のうち 「保存」と「可視化」を切り捨てて、他のツールに任せています 。 「単体で機能しない」という話はこれのことで、単体では説明しづらいため先に “監視” ツールのお話をしました。 「保存」「可視化」を任せる他のツールへの連携については、転送規格 “ OTLP ” の仕様を公開しておくことで連携先のツール側で対応してもらう形です。 連携先のツールとしては、「Grafana Tempo (トレースのみ) / Grafana Mimir (メトリクスのみ) / Grafana Loki (ログのみ)」や「Zabbix (8.0 以降)」などが挙げられます。 ■OpenTelemetry のメリットは？ では OpenTelemetry のメリットは何か、というところを考えてみましょう。 メリットの前に、先述の「OpenTelemetry 単体では機能しない」というのは明確に手間がかかりわかりにくい箇所と言えます。これを上回るメリットはあるのでしょうか？ ・ “ベンダーロックイン” の回避 殆どの “監視” ツールでは、それぞれ 「そのツールにだけ通用する方法・形式」で先述の “4つの役割”「収集・転送・保存・可視化」の連携 をしています。 このため、何らかの理由で「別のツールに乗り換えたい」と考えた場合、”4つの役割” の 全ての要素を完全に置き換えねばならず、移行コストが高騰しがち です。 この「移行が大変だからあまりやりたくないなあ」と思わせる戦略は、”ベンダーロックイン” などと呼ばれています。 その点、OpenTelemetry は 元々「収集・転送」のみを担当して他のツールへ連携する 構造であり、かつ「 コードに直接干渉してデータ収集させる 」という、”監視ツール” において対応コストが最も高くなりがちな部分を担当しています。 これにより、移行の前後双方で OpenTelemetry を活用しておくことにより、移行コストを大幅に下げることができる可能性があります。 ・ カバー範囲の広さ OpenTelemetry は、 一つで「 トレース/メトリクス/ログ 」の収集を全て行なう ことができます。 OpenTelemetry 以前にも「トレースのみ」「メトリクスのみ」「ログのみ」を収集する OSS “監視” ツールは存在していましたが、(本記事の執筆時点では) これら全てをカバーできる OSS は希少です。 ・構造自体の優位性 繰り返しになりますが、OpenTelemetry は「保存・可視化」を捨てて 「収集・転送」のみ を担当しています。 これにより、「保存・可視化」を伴う他ツールと競合せずに協力・発展が可能で、かつこれ自身の開発リソースは「収集・転送」に集中されるため、将来的な機能追加にも期待できるでしょう。 また、バックボーンが Linux Foundation 傘下の CNCF であることから、中立性の維持も期待してよいと言えます。 ■最後に 今回は OpenTelemetry の概要についてお話ししました。 改めて要点を纏めてみると、「 CNCF (Linux Foundation 傘下) による、 “監視” のためのコード組み込み型アプローチによるデータ収集の標準化 を目指している OSS」と言えるでしょう。 単体では機能しない以上、他の “監視” ツールの動向にも大きく影響を受けるソフトウェアではありますが、 高機能な UI を備えることで有名な Grafana や Zabbix などもこの OpenTelemetry のデータの「保存・可視化」の対応に踏み切っており、”監視” システムの世界へ確実な影響を与えていくものになるはずです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Observability 実現の代表格「OpenTelemetry」って何だ？ first appeared on SIOS Tech Lab .

こんにちは。サイオステクノロジー OSS サポート担当 山本です。 今回は TimescaleDB の具体的な活用例として、統合監視ツール「Zabbix」のバックエンドデータベースに採用する方法をご紹介します。 ■ざっくりおさらい：TimescaleDB って？ TimescaleDB は、Tiger Data 社 (旧 Timescale 社) による PostgreSQL の拡張機能 で、 超大規模データの集計処理に特化 した「 時系列データベース / 列指向データベース 」として振る舞う “hypertable” という特殊なテーブルを作成・管理する機能などを提供してくれます。 参考過去記事： 時系列データベース「TimescaleDB」って何なんだ？ ■ざっくりおさらい：Zabbix って？ Zabbix は、Zabbix 社が開発を主導する OSS の統合監視プラットフォームです。 サーバーやネットワーク機器などから多種多様なデータを収集する 監視機能 や、収集データの可視化・障害検知時のアラート通知などを行える高機能な Web インターフェース を備えています。 ■Zabbix で TimescaleDB を使う TimescaleDB は「大量の時系列データ」の扱いを得意としていますが、監視システムである Zabbix はその代表例と言えます。 また Zabbix は公式に TimescaleDB をサポートしており、導入が比較的容易と言えます。 そのセットアップの流れと、注意すべきポイントを確認していきましょう。 ■TimescaleDB (PostgreSQL) を準備する まずは PostgreSQL と TimescaleDB をインストールします。 自前の環境にセットアップする場合は、以下の TimescaleDB 公式ドキュメントに沿って実施すればよいでしょう。（OS ごとにコマンド単位でまとめられています。） 参考： Install self-hosted TimescaleDB – Tiger Data 注意点として、Zabbix 側の TimescaleDB 対応バージョンには 下限だけでなく 上限 も定められています。 そのため、「とりあえず最新バージョンを入れておけば大丈夫だろう」と考えていると躓く場合があります。 参考： 2 要件 – Zabbix Doc 7.0 未対応バージョンの TimescaleDB をインストールした場合、インストール自体は成功しても Zabbix サーバー起動時にバージョンチェックでエラーとなり起動しません 。 （以下は Zabbix7.0.32 に TimesclaDB2.31.0 を入れて実際に躓いた例です） ※一応、Zabbix の設定ファイル（zabbix_server.conf）にバージョンチェックを無効化する設定項目 AllowUnsupportedDBVersions はありますが、これを使用する場合正常に動作する保証はありません。 ■Zabbix をインストールする 続いて、Zabbix をインストールします。 こちらも公式のインストールガイドに沿って進めれば問題ないでしょう。（データベースの種類には PostgreSQL を選択してください。） 参考： Download and install Zabbix ■データベースを TimescaleDB 向けに初期化・アップグレードする （note: 元々 PostgreSQL で Zabbix サーバを運用している場合、この手順のみ実行すれば OK です。ただし、スクリプトの実行には時間がかかる可能性があります。） Zabbix の初期スキーマを投入した後、 Zabbix Server を停止させた (または起動前の) 状態で 、以下のページを参考に TimescaleDB 向けの初期化スクリプトを実行します。(以下は Zabbix 7.0 向けの手順) 参考： 6 TimescaleDBのセットアップ – Zabbix Doc 7.0 スクリプトの適用後、Zabbix サーバーを起動して Web インターフェースの「管理 > データの保存期間」を開き、以下の設定を確認・有効化します。（以下は Zabbix7.0 での例です） 　・「アイテムのヒストリの保存期間設定を上書き」： 有効 　・「アイテムのトレンドの保存期間設定を上書き」： 有効 　・「ヒストリ、トレンド、監査ログの圧縮」の項目が表示されており、有効になっていること ■Zabbix で TimescaleDB を使う場合の強みと留意点 Zabbix で TimescaleDB を使用するようにセットアップするのは (マニュアルも導入用 .sql ファイル等も整っているので) そこまで難しくなさそうだ、というところは確認できたと思います。 では、Zabbix において TimescaleDB がどんなメリットや注意点をもたらすか、主たるところを少し考えてみましょう。 ■データ容量 (=ディスク消費量) の大幅な削減 Zabbix に限らず監視システムというのは 基本的に大量のデータを保存する ことになるので、 ディスク容量の逼迫はトラブルの代表例 です。 TimescaleDB では、一定以上古くなったデータ群 (chunk) を様々な圧縮技術を使って圧縮・再構成します。 実際の圧縮率はそのデータ群がどれだけ圧縮に適しているかによりますが、これにより 最大 95% ほどデータ容量が削減できる 可能性があるとされています。 このデータ圧縮により、 ディスク容量不足の発生を抑制・低減 できる可能性が考えられます。 この性質は長期間監視データを保持したい場合や大規模監視をする場合に特に優位です。 ■housekeeper（データ削除処理）による負荷・ハングアップの防止 Zabbix では、 housekeeper というプロセスによって定期的に 古く不要になった監視データなどの削除 をしています。 Zabbix は仕組み上当然ながら大量の監視データを蓄積します。 しかし一方で、 MySQL や PostgreSQL などの標準的な RDB は、 多量のデータが蓄積されている状態で特定のデータを選択して削除する処理 を 苦手 とする傾向があり、高負荷の状況を発生させるトラブルを誘発しがちです。 実際、「 housekeeper 処理が原因でハングアップした 」というのは Zabbix あるあるトラブルの代表例だったりします。 （これは全体的な設定ミスや環境要件など複数の問題が絡んでくるので、解決が結構大変です。） ところで、TimescaleDB は主に “時間” の情報を元にデータ群を chunk と呼ばれる小さな塊に分けて整理しており、その仕組み上「 一定以上以前のデータをまとめて消す 」という処理を 極めて低い負荷 で実行できます。 この性質により、 housekeeper 処理に起因するトラブルを未然に軽減 できる可能性が考えられます。 ■留意点あれこれ ・ 古いデータの自動削除を有効にするには監視データの保存期間を統一する必要がある TimescaleDB を使用する場合、先述のとおり「管理 > データの保存期間」の “アイテムのヒストリの保存期間設定を上書き” と “アイテムのトレンドの保存期間設定を上書き” を有効にする必要があります。 この設定により、 Zabbix の全監視データの保存期間が統一されます 。 このため、 一部の監視設定のみデータの保存期間を長く/短くするということができません 。 基本的には最も長く保存したいものに合わせることになるかと思いますが、場合によってはこれにより逆に総合的なデータ容量が増えるケースもあり得るでしょう。 なお、”アイテムのヒストリの保存期間設定を上書き” と “アイテムのトレンドの保存期間設定を上書き” を有効にしなくてもほとんどの機能は動作はしますが、 有効にしていない場合は housekeeper による古いデータの自動削除処理ができなくなります 。 これはディスク容量の問題に直結するため、やめておいたほうがよいでしょう。 ・ Zabbix には元々データ容量削減の仕組みがある Zabbix では取得した実際の監視データ「ヒストリ」の他に、各1時間ごとの監視データの[取得数・最大値・最小値・平均値]を記録する「トレンド」を保存しています。 「トレンド」は1時間で1つ分のデータセットを保持すればよいため、実際の監視データである「ヒストリ」よりも大幅にデータ容量を削減できます。 これを利用し、細かく調査したい期間分だけ「ヒストリ」を保存し、それより古いデータは「トレンド」だけ残す……というデータ容量削減方法が Zabbix には昔からあります。 TimescaleDB でのデータ容量削減効果が出てくるのは圧縮の後 なので、「ヒストリ」の保存期間が短くてもよい場合には データ容量の観点では TimescaleDB を採用するメリットは相対的には小さくなるでしょう。 ■おわりに 今回は、Zabbix のデータベースに TimescaleDB を採用する構成についてお話ししました。 TimescaleDB 自体の知識があったほうがいいことやその他留意点などは多少存在するものの、手間は少なく運用上の変更点も殆どなしで導入できることがわかるかと思います。 そして、理論上は Zabbix サーバにおける負荷を全体的に軽減 してくれることが期待できる、というメリットも確認しました。 これから Zabbix での監視環境を構築する方やリプレースを検討されている方、負荷問題でお悩みの方は選択肢の一つとして検討してみてはいかがでしょうか？ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Zabbix のデータベースとして TimescaleDB を使用する first appeared on SIOS Tech Lab .

はじめに 2025年8月29日、滋賀県大津市のピアザ淡海（ピアザホール）でNaniwaNOG 3ミーティングが開催されました。関西のネットワーク技術者が一堂に会するこのイベントで、前回に引き続き、学生を中心としたNOCチ […]