はじめに：
モニターになるための新会社、面接が必要草が常に環境に優しいプログラマであるようプロメテウスは、同社の監視ソリューションであると呼ばれ、私はもちろん、スーツに従うことを選択し、企業がプロメテウスを必要とするため、主な仕事は、ZABBIXになる前に、無リコースことなく、取るにいくつかのコントラスト、理解の下で、すべてのスキルの後に、より体よりも、少し少し深く、私は、これら二つの監視方法をまとめるために、プロメテウスの利点を実現：
監視ツールの一つまたは2の簡単な履歴：
プロメテウス：
2012年以来のKubernetes、オープンソースは、コンテナのスケジューリングと振り付けの分野でのリーダーになるための魅力的な傾向となり、KubernetesはGoogleのボルグシステムのオープンソース実装である、これは、プロメテウスがグーグルBorgMonのオープンソース実装である対応しています。プロメテウスは、オープンソースの監視警報システムと時系列データベースのSoundCloudが開発です。文字通り、プロメテウスは、警報システムが監視され、2つの部分から成り、他方は（TSDB）組み込み配列データベースです。2016年には、Googleがその第二位のオープンソースプロジェクトにプロメテウスにLinux Foundationの、財団のネイティブクラウド（クラウドコンピュネイティブ財団）が主催しました。プロメテウスは、Kubernetesがネイティブクラウドオーラが付属してその「兄弟」で、また、オープンソースコミュニティでは非常に活発であるGitHubの上で20,000以上のスターを持っており、システムごとに12週間更新の小型版があるだろう、とプロメテウス友好協力関係の自然にできます。
ZABBIX：
ZABBIX公式リリース時間は4年前プロメテウスよりも、ZabbixはアレクセイVladishevによる監視システムの分散オープンソースであり、2012年までさかのぼることができ、ソリューションを監視し、分散オープンソースは、エンタープライズクラスです。あなたは、さまざまなネットワークパラメータやサーバソフトウェアの健全性と完全性を監視することができます。事実上すべてのイベントのためのconfigureメールベースのアラートにユーザーを可能にする柔軟な通知メカニズムを使用してください。この迅速なフィードバックサーバーの問題。保存されたデータに基づいて、それは優れたレポーティングやデータの可視化機能を提供します。
第二に、アーキテクチャのコントラスト：
プロメテウス：
Prometheus的基本原理是通过HTTP周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口并且符合Prometheus定义的数据格式，就可以接入Prometheus监控。
Prometheus Server负责定时在目标上抓取metrics（指标）数据并保存到本地存储里面。Prometheus采用了一种Pull（拉）的方式获取数据，不仅降低客户端的复杂度，客户端只需要采集数据，无需了解服务端情况，而且服务端可以更加方便的水平扩展。
如果监控数据达到告警阈值Prometheus Server会通过HTTP将告警发送到告警模块alertmanger，通过告警的抑制后触发邮件或者webhook。Prometheus支持PromQL提供多维度数据模型和灵活的查询，通过监控指标关联多个tag的方式，将监控数据进行任意维度的组合以及聚合。
Zabbix：
三、综合对比：
综合比对：
如上面的表格，从开发语言上看，为了应对高并发和快速迭代的需求，监控系统的开发语言已经慢慢从C语言转移到Go。不得不说，Go凭借简洁的语法和优雅的并发，在Java占据业务开发，C占领底层开发的情况下，准确定位中间件开发需求，在当前开源中间件产品中被广泛应用。从系统成熟度上看，Zabbix是老牌的监控系统：Zabbix是在1998年就出现的，系统功能比较稳定，成熟度较高。而Prometheus是最近几年才诞生的，虽然功能还在不断迭代更新，但站在巨人的肩膀之上，在架构设计上借鉴了很多老牌监控系统的经验；从数据存储方面来看，Zabbix采用关系数据库保存，这极大限制了Zabbix采集的性能，而Prometheus自研一套高性能的时序数据库，在V3版本可以达到每秒千万级别的数据存储，通过对接第三方时序数据库扩展历史数据的存储；从配置复杂度上看，Prometheus只有一个核心server组件，一条命令便可以启动，相比而言，其他系统配置相对麻烦，从社区活跃度上看，目前Zabbix比较活跃，但基本都是国内的公司参与，Prometheus在这方面占据绝对优势，社区活跃度虽然不如，但是受到CNCF的支持，后期的发展值得期待；从容器支持角度看，由于Zabbix出现得比较早，当时容器还没有诞生，自然对容器的支持也比较差。而Prometheus的动态发现机制，不仅可以支持swarm原生集群，还支持Kubernetes容器集群的监控，是目前容器监控最好解决方案。
总结：
综合来看，Zabbix 的成熟度更高，上手更快，但更好的集成导致灵活性较差，问题更大是，监控数据的复杂度增加后，Zabbix 做进一步定制难度很高，即使做好了定制，也没法利用之前收集到的数据了（关系型数据库造成的问题）。Prometheus 基本上是正相反，上手难度大一些，但由于定制灵活度高，数据也有更多的聚合可能，起步后的使用难度远小于 Zabbix。但如果已经对传统监控系统有技术积累的话，还是要谨慎考虑更换监控。
结论：
如果监控的是物理机，用 Zabbix 没毛病，Zabbix在传统监控系统中，尤其是在服务器相关监控方面，占据绝对优势。甚至环境变动不会很频繁的情况下，Zabbix 也会比 Prometheus 好使；但如果是云环境的话，除非是 Zabbix 玩的非常溜，可以做各种定制，否则还是 Prometheus 吧，毕竟人家就是干这个的。Prometheus开始成为主导及容器监控方面的标配，并且在未来可见的时间内被广泛应用。如果是刚刚要上监控系统的话，不用犹豫了，Prometheus 准没错。