两者适用于多大规模的监控场景？超过以上监控节点时怎么办？高可用怎么解决？
两者怎么解决存储问题？对于监控信息是否有历史存储和分析，能从历史信息中挖掘到哪些有价值的信息？
两者怎么应对告警风暴和误报？
在智能监控和自动治愈方面是否有可借鉴的实践？基于什么算法或策略？怎么进行故障预判和预处理？
监控大屏是怎么设计的？
自动化运维管理是两者同时使用还是二选一更合适？
两者在配合使用时，应该怎么分工？怎么落地？
如果已经部署了Zabbix，怎么平稳过渡到Prometheus？
分布式链路的可观测性和端到端诊断怎么做？
大规模场景下，两者的性能和成本哪个比较低？
监控，为什么总让我们头痛监控一直都是运维工作中不可或缺的部分，一个高效、契合的监控系统是服务赖以健康稳定的基石。随着业务规模的增长、技术的发展、行业的变革，企业对用户体验越来越重视，监控的需求发生着日新月异的变化，相应的监控工具和解决方案也层出不穷。其中，Zabbix和Prometheus就是两款非常典型的监控工具，应用颇为广泛。
说起来，监控在不同的团队和公司之间，可能会存在各种差异化的需求。如何基于开源产品打造一个符合自己业务场景的监控体系，并且持续迭代？这成为了大家无法绕开的课题。
比如说，如何选择监控方案和开源工具？如何为自己的业务场景做定制化适配？如何实现端到端的全链路监控？如何让业务方以更低成本接入到这个系统中？如何做监控的自动化？如何做异常告警的路由、分发、收敛和抑制？如何做统一化的监控大屏、Dashboard等等……这些都是我们在构建监控系统中可能会面临的问题。
围绕这些问题，dbaplus社群特别邀请到美图SRE负责人-石鹏(东方德胜)作为主持人、招商银行技术经理-蔡翔华作为Zabbix使用方、甜橙金融基础技术架构师-刘宇作为Prometheus使用方，针对Zabbix和Prometheus展开实用选型探讨。
十问十答，监控工具怎么选Q1：Zabbix和Prometheus分别适用于多大规模的监控场景？超过以上监控节点时怎么办？高可用怎么解决？
蔡翔华：我们和Zabbix官方其实有沟通过，业内他们有一些监控到了40万以上的节点数，当然这个节点数也要根据你每个节点上监控多少东西。Zabbix其实有一个指标叫做NVPS（NewValuePerSecond），也就是每秒新增的值的指标，来判断你的监控规模是不是合适的。
那么对于个节点以上的场景来说，其实Zabbix还是OK的，你可以通过多布署一些Proxy，去对后台数据库做一些性能调优等等，以这些方式去提高整个监控平台的可承受、负载的性能。
另外关于高可用，我们的数据库端是会有Mycat或者HAProxy高可用，但服务器端本身它其实没有高可用，那么我们可以依赖于虚拟化平台，或者是比如像我们有Vmotion等热迁移这些技术。另外，在未来的5.x版本或者6版本以上的话，官方已经将原生的高可用纳入到Zabbix的Roadmap里面了，大家可以期待一下。
石鹏：好的，蔡老师的核心观点其实就是我们需要