Zabbix へのインタビュー: 12 の率直な回答

IT には「機能するなら触るな」という迷信があります。これは当社の監視システムにも言えることです。サウスブリッジでは Zabbix を使用しています。これを選択したとき、それは非常にクールでした。そして実際、彼には他に選択肢がなかったのです。

時間の経過とともに、私たちのエコシステムは命令、追加のバインディングを取得し、Redmine との統合が登場しました。 Zabbix には、速度、ほぼすぐに使える HA、美しい視覚化、kubernethes 環境での作業の最適化など、多くの面で優れた強力な競合他社がいました。

しかし、私たちは先に進むことを急いでいません。私たちは、Zabbix を調べて、今後のリリースでどのような機能が追加される予定であるかを尋ねることにしました。私たちは式典には出席せず、Zabbix 開発ディレクターの Sergey Sorokin 氏とソリューション アーキテクトの Vitaly Zhuravlev 氏に不快な質問をしました。それから何が起こったのかを知るために読んでください。

1. 会社の歴史について教えてください。製品のアイデアはどのようにして生まれたのですか？

同社の歴史は 1997 年に始まり、創業者兼所有者の Alexey Vladyshev が銀行の XNUMX つでデータベース管理者として働いていました。アレクセイには、環境の現在および過去の状態を理解せずに、さまざまなパラメータの過去の値に関するデータがなければデータベースを管理するのは効果がないと思われました。

同時に、現在市場にある監視ソリューションは非常に高価で扱いにくく、大量のリソースを必要とします。したがって、Alexey は、自分に任されたインフラストラクチャの部分を効果的に監視できるようにするさまざまなスクリプトを書き始めます。趣味と化しつつあります。 Alexey は転職しましたが、プロジェクトへの関心は残りました。 2000 年から 2001 年にかけて、プロジェクトは最初から書き直されました。そこで Alexey は、他の管理者に開発内容を使用する機会を与えることを考えました。同時に、既存のコードをどのライセンスに基づいてリリースするかという疑問も生じました。 Alexey は、GPLv2 ライセンスに基づいてリリースすることにしました。このツールはプロフェッショナルな環境ですぐに注目されました。時間が経つにつれて、Alexey はサポート、トレーニング、ソフトウェアの機能拡張のリクエストを受けるようになりました。そのような注文の数は増え続けていました。そこで、当然のことながら、会社を設立するという決断が下されました。当社は12年2005月XNUMX日に設立されました。

2. Zabbix 開発の歴史の中でどのような重要な点を強調できますか?

現在、そのような点がいくつかあります。
A.アレクセイは 1997 年に脚本に取り組み始めました。
b. GPLv2 ライセンスに基づくコードの公開 - 2001 年。
V. Zabbix は 2005 年に設立されました。
d. 最初のパートナーシップ契約の締結、アフィリエイト プログラムの創設 - 2007 年。
d. Zabbix Japan LLC 設立 - 2012 年。
e. Zabbix LLC (米国) の設立 - 2015
そして。 Zabbix LLC の設立 - 2018

3. 何人雇用していますか?

現在、Zabbix グループ企業は、開発者、テスター、プロジェクト マネージャー、サポート エンジニア、コンサルタント、営業担当者、マーケティング担当者など、70 人強の従業員を雇用しています。

4. ロードマップはどのように作成しますか? ユーザーからのフィードバックは収集しますか?次にどこに移動するかをどのように決定しますか?

Zabbix の次のバージョンのロードマップを作成するときは、次の重要な要素に焦点を当てます。より正確には、次のカテゴリに従ってロードマップを収集します。

A. Zabbix の戦略的改善。 Zabbix 自体が非常に重要であると考えているもの。たとえば、Go で書かれた Zabbix エージェントです。
b. Zabbix クライアントとパートナーが Zabbix で見たいもの。そしてその対価として彼らは喜んで支払います。
V. Zabbix コミュニティからの要望/提案。
d. 技術的負債。 🙂 以前のバージョンでリリースしましたが、完全な機能を提供しておらず、十分な柔軟性を持たず、すべてのオプションを提供していませんでした。

5. Zabbix と prometheus を比較できますか? Zabbix の何が優れていて、何が劣っているのでしょうか?

私たちの意見では、主な違いは、Prometheus が主にメトリクスを収集するためのシステムであることです。企業内で本格的なモニタリングを収集するには、視覚化のための grafana など、他の多くのコンポーネントを Prometheus に追加する必要があります。別個の長期保管、別個の管理が必要な場合は、ログを別個に処理する必要があります...

Prometheus には標準の監視テンプレートは存在しないため、エクスポータから数千のメトリクスをすべて受け取った後、その中から問題のあるシグナルを独自に見つける必要があります。 Prometheus のセットアップ - 構成ファイル。より便利な場所もあれば、そうでない場所もあります。

Zabbix は、「から」と「から」の監視を作成するためのユニバーサル プラットフォームです。独自の視覚化、問題とその表示の関連付け、システムへのアクセス権の配布、アクションの監査、エージェントを介してデータを収集するための多くのオプションがあります。プロキシ、まったく異なるプロトコルを使用し、プラグイン、スクリプト、モジュールを使用してシステムを迅速に拡張する機能...

あるいは、たとえば HTTP プロトコル経由でデータをそのまま収集し、JavaScript、JSONPath、XMLPath、CSV などの前処理関数を使用して応答を有用なメトリクスに変換することもできます。多くのユーザーは、Web インターフェイスを介してシステムを構成および管理できる機能、相互に共有できるテンプレートの形式で一般的な監視構成を記述できる機能、メトリクスだけでなく検出ルールも含まれる機能などの点で Zabbix を高く評価しています。しきい値、グラフ、説明 - 典型的なオブジェクトを監視するためのオブジェクトの完全なセット。

また、Zabbix API を通じて管理と構成を自動化できる機能も多くの人に好まれています。一般的に、私はホリバーを組織したくありません。どちらのシステムもそれぞれのタスクに適しており、相互に調和して補完できるように思えます。たとえば、バージョン 4.2 の Zabbix は Prometheus エクスポータまたはそれ自体からデータを収集できます。

6. zabbix saas を作成することを考えたことはありますか?

私たちはそれを検討し、将来もそうする予定ですが、このソリューションをお客様にとってできる限り便利なものにしたいと考えています。この場合、標準の Zabbix を通信ツール、高度なデータ収集ツールなどとともに提供する必要があります。

7. zabbix はいつ頃期待できますか?待ったほうがいいでしょうか？

Zabbix HA は間違いなく待ちます。 Zabbix 5.0 LTS で何かが実現することを心から望んでいますが、Zabbix 2019 ロードマップが完全に確認される 5.0 年 XNUMX 月に状況がより明確になるでしょう。

8. すぐに使用できるメディア タイプの選択肢がこれほど貧弱なのはなぜですか? Slackや電報などを追加する予定はありますか?他に Jabber を使用している人はいますか?

Jabber は Zabbix 4.4 で削除されましたが、Webhook が追加されました。メディアの種類に関しては、システムから特定のアプリケーションを作成するのではなく、標準のメッセージング ツールを作成したいと考えています。同様のチャット サービスやデスク サービスの多くが HTTP 経由の API を備えていることは周知の事実です。そのため、今年の 4.4 のリリースにより状況は変わります。

Zabbix での Webhook の出現により、近い将来、最も人気のあるすべての統合がすぐに利用できるようになることが予想されます。この場合、統合は単純な一方向の通知だけではなく、双方向になります。そして、私たちがアクセスできないメディア タイプはコミュニティによって処理されます。メディア タイプ全体を構成ファイルにエクスポートして、share.zabbix.com または github に投稿できるようになったからです。また、他のユーザーはファイルをインポートするだけでこの統合の使用を開始できます。この場合、追加のスクリプトをインストールする必要はありません。

9. 仮想マシンの検出の方向性が発展していないのはなぜですか? VMware しかありません。多くの人がec2、openstackとの統合を待っています。

いや、方向性は発展してるよ。たとえば、4.4 では、データストア検出は vm.datastore.discovery キーを通じて行われました。 4.4 では、非常にクールな wmi.getall キーも登場しました。これにより、perf_counter_en キーと合わせて、適切な Hyper-V 監視が可能になることが期待されています。 Zabbix 5.0 では、この方向で他にも重要な変更が加えられる予定です。

10. テンプレートを放棄して、与えられたものすべてが奪われるプロメテウスのようにやろうと考えたことはありますか?

Prometheus はすべてのメトリクスを自動的に取得するため、これは便利です。また、テンプレートは単なるメトリクスのセットではなく、特定のタイプのリソースまたはサービスを監視するために必要な一般的な構成をすべて含む「コンテナ」です。重要なトリガー、グラフ、検出ルールのセットがすでにあり、何が収集されているのか、どのしきい値がチェックされるのか、その理由をユーザーが理解するのに役立つメトリクスとしきい値の説明が含まれています。同時に、テンプレートは他のユーザーと簡単に共有でき、必ずしもその専門家でなくても、システムを適切に監視できます。

11. すぐに使えるメトリクスが非常に少ないのはなぜですか?これにより、操作の観点からもセットアップが非常に複雑になります。

すぐに使える既製のテンプレートのことを指すのであれば、現在、テンプレートの拡張と改善に取り組んでいます。 Zabbix 4.4 には、新しく改良されたセットと優れた機能が付属しています。

Zabbix の場合は、share.zabbix.com でほぼすべてのシステム用の既製のテンプレートをいつでも見つけることができます。しかし、私たちは基本的なテンプレートを自分たちで作成し、他の人に手本を示すとともに、ユーザーが再び一部の MySQL 用のテンプレートを作成することから解放されるべきだと判断しました。したがって、Zabbix では、各バージョンの公式テンプレートのみが追加されます。

12. ホストに関連付けられていない、たとえばラベルに基づいたトリガーを構築できるのはいつになりますか。たとえば、n 個の異なるポイントからサイトを監視しており、サイトが 2 つ以上のポイントからアクセスできない場合に起動する単純なトリガーが必要です。

実際、そのような機能は、あるクライアント向けに作成されたもので、数年前から Zabbix で利用可能でした。クライアント - ICANN。同様のチェックは、たとえば、集約されたアイテムや Zabbix API を使用して実行することもできます。現在、このような小切手の作成を簡素化するために積極的に取り組んでいます。

PS: Slurms の 1 つで、Zabbix 開発者は、Prometheus ではなく Zabbix を使用して Kubernetes クラスターを監視するために、製品に何が欲しいのかを尋ねました。

開発者が顧客と中途半端に出会い、自分だけのものに留まらなくなるのは素晴らしいことです。そして今、私たちは各リリースを心からの関心を持って迎えています。嬉しいことに、これまで話してきた機能がますます血肉となりつつあります。

開発者が自分自身に閉じこもるのではなく、クライアントのニーズに関心を持っている限り、製品は生き続け、発展します。私たちは新しい Zabbix リリースに注目していきます。

PPS：数か月以内にオンラインモニタリングコースを開始する予定です。興味のある方は、お知らせを見逃さないように購読してください。それまでの間、次の手順を実行してください。 Kubernetes でのスラーム.

出所： habr.com