UlricQin
commented
4 years ago 这不是改造prometheus-exporter-collector的事，这是一个比较大的服务端改造，使用方式上会发生变化，系统还未演进到这一步，目前不下结论。promql虽然灵活，但是大的查询经常会oom，并且灵活性是需要陡峭的学习成本的，我们后面会引入实时计算方案来做指标聚合，针对k8s的场景做定制化支持，但是是否会引入prom的一些能力，待系统演化到相应阶段的时候再行考虑
需求描述: prometheus-exporter-collector支持prometheus查询语法
需求背景: 如果将prometheus 切到prometheus-exporter-collector,好多图表展示就用不了,建议在适当情况兼容这种场景,应该大多数会遇到这种情况,大部分容器和虚拟机监控用的prometheus+grafana
影响: 弊: 当前未支持将影响原生使用prometheus+grafana用户,需要与n9e做技术妥协,带来高额维护成本; 不利于运维监控体系构建完整性;
利: 实现后,将完美与prometheus结合,提高n9e监控覆盖率; 有效降低运维监控维护成本; 对n9e来说,将吸引一大批想要真正迁移到n9e的潜在用户,提升该开源项目知名度;