IT界有一個迷信：“如果它有效，就不要碰它。” 我們的監控系統也是如此。 在南橋，我們使用 Zabbix——當我們選擇它時，它非常酷。 事實上，他別無選擇。
隨著時間的推移，我們的生態系統已經獲得了指令、額外的綁定，並且出現了與 redmine 的整合。 Zabbix 有一個強大的競爭對手，它在許多方面都表現出色：速度、幾乎開箱即用的 HA、漂亮的視覺化、在 kubernetes 環境中工作的最佳化。
但我們並不急於繼續前進。 我們決定看看 Zabbix 並詢問他們計劃在即將發布的版本中提供哪些功能。 我們沒有客氣，向 Zabbix 開發總監 Sergey Sorokin 和解決方案架構師 Vitaly Zhuravlev 提出了一些令人不安的問題。 請繼續閱讀以了解結果。
1. 請介紹一下公司的歷史。 產品的想法是如何產生的？
公司的歷史始於 1997 年，當時公司的創始人兼所有者 Alexey Vladyshev 在一家銀行擔任資料庫管理員。 在阿列克謝看來，如果沒有各種參數的歷史值數據，如果不了解環境的當前和歷史狀態，管理資料庫將是無效的。
同時，目前市場上的監控解決方案非常昂貴、繁瑣，需要大量資源。 因此，Alexey 開始編寫各種腳本，使他能夠有效地監控委託給他的基礎設施部分。 它正在變成一種愛好。 阿列克謝換了工作，但對該項目的興趣仍然存在。 2000-2001 年，該專案從頭開始重寫，Alexey 考慮為其他管理員提供使用這些開發成果的機會。 同時，出現了在什麼許可證下發布現有程式碼的問題。 Alexey 決定根據 GPLv2 許可證發布它。 該工具立即在專業環境中引起注意。 隨著時間的推移，Alexey 開始收到支援、培訓和擴展軟體功能的請求。 此類訂單的數量不斷增加。 於是，很自然地，我們就做出了創建公司的決定。 公司成立於12年2005月XNUMX日
2. Zabbix發展史上有哪些要點？
目前有這樣幾個點：
A。 Alexey 於 1997 年開始創作劇本。
b. 根據 GPLv2 許可證發布代碼 - 2001 年。
五、 Zabbix 成立於 2005 年。
d. 簽訂第一份合作夥伴協議，創建附屬計畫 - 2007 年。
d. Zabbix Japan LLC 成立 - 2012 年。
e. Zabbix LLC（美國）成立 - 2015 年
和。 Zabbix LLC 成立 - 2018 年
3. 你們有多少員工？
目前，Zabbix 集團公司擁有 70 多名員工：開發人員、測試人員、專案經理、支援工程師、顧問、銷售人員和行銷人員。
4. 你如何寫路線圖，是否收集使用者回饋？ 您如何確定下一步搬到哪裡？
在為Zabbix的下一版本建立Roadmap時，我們專注於以下重要因素，更準確地說，我們根據以下類別收集Roadmap：
A。 Zabbix 策略改進。 Zabbix 本身認為非常重要的東西。 例如，用Go編寫的Zabbix代理程式。
b. Zabbix 客戶和合作夥伴希望在 Zabbix 中看到的東西。 而他們願意為此付出代價。
五、 來自 Zabbix 社區的願望/建議。
d. 技術債。 🙂 我們在以前的版本中發布了一些東西，但沒有提供完整的功能，沒有使它們足夠靈活，沒有提供所有選項。
5.可以比較一下Zabbix和prometheus嗎？ Zabbix 中什麼比較好、什麼更糟？
我們認為，主要區別在於 Prometheus 是一個主要用於收集指標的系統 - 為了在企業中收集全面的監控，有必要向 Prometheus 添加許多其他組件，例如用於可視化的 grafana、單獨的長期存儲，並單獨管理某處的問題，單獨處理日誌......
Prometheus 中不會有標準的監控模板；在收到來自導出器的數千個指標後，您將需要獨立尋找其中有問題的訊號。 設定 Prometheus - 設定檔。 在某些地方比較方便，在有些地方則不然。
Zabbix是一個用於創建「從和到」監控的通用平台，我們有自己的視覺化、問題及其顯示的關聯、系統存取權限的分配、操作審計、透過代理收集資料的許多選項，代理，使用完全不同的協議，能夠透過插件、腳本、模組快速擴展系統......
或者，您可以簡單地按原樣收集數據，例如透過 HTTP 協議，然後使用 JavaScript、JSONPath、XMLPath、CSV 等預處理函數將回應轉換為有用的指標。 許多用戶重視Zabbix，因為它能夠透過Web介面配置和管理系統，能夠以可以相互共享的模板的形式描述典型的監控配置，並且不僅包含指標，還包含檢測規則，閾值、圖表、描述- 用於監視典型物件的完整物件集。
許多人也喜歡透過 Zabbix API 實現自動化管理和配置的能力。 總的來說，我不想辦一場節日。 在我們看來，這兩個系統都非常適合各自的任務，並且可以和諧地互補，例如，4.2 版本的 Zabbix 可以從 Prometheus 導出器或自身收集資料。
6.有沒有想過要做zabbix saas？
我們考慮過，將來也會這樣做，但我們希望讓這個解決方案盡可能為客戶提供方便。 在這種情況下，應該提供標準的 Zabbix 以及通訊工具、高級資料收集工具等。
7. 什麼時候我應該期待zabbix ha？ 我們應該等待嗎？
Zabbix HA 絕對是一個等待。 我們確實希望在 Zabbix 5.0 LTS 中看到一些東西，但到 2019 年 5.0 月 Zabbix XNUMX 路線圖完全確認時，情況將會變得更加清晰。
8. 為什麼媒體類型的開箱即用選擇如此糟糕？ 您是否計劃添加 Slack、telegram 等？ 還有人使用 Jabber 嗎？
Jabber 在 Zabbix 4.4 中被刪除，但新增了 Webhooks。 關於媒體類型，我不想從系統中製作特定的應用程序，而是想製作標準的訊息工具。 眾所周知，許多類似的聊天或桌面服務都透過 HTTP 提供 API - 因此，隨著今年 4.4 的發布，情況將會改變。
隨著 Zabbix 中 webhooks 的出現，您可以在不久的將來期待所有最受歡迎的整合。 在這種情況下，整合將是雙向的，而不僅僅是簡單的單向通知。 而那些我們無法訪問的媒體類型將由我們的社區來完成 - 因為現在整個媒體類型可以導出到配置文件並發佈在 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。 我們現在正在積極努力簡化此類支票的創建。
聚苯乙烯：在其中一次 Slurms 中，Zabbix 開發人員詢問我們希望在產品中看到什麼，以便使用 Zabbix 而不是 Prometheus 來監控 Kubernetes 叢集。
當開發人員與客戶進行半途而廢並且不再只顧自己時，這真是太好了。 現在，我們懷著真誠的興趣迎接每個版本 - 好消息是我們談論的越來越多的功能正在變得有血有肉。
只要開發人員不退縮，而是對客戶的需求感興趣，產品就能生存和發展。 我們將密切關注新的 Zabbix 版本。
聚苯硫醚：我們將在幾個月內推出線上監控課程。 如果您有興趣，請訂閱以免錯過公告。 在此期間，您可以透過我們的 .
來源： www.habr.com