Service discovery机制让配置工作更简单
开源社区提供的数以百计的数据导出工具
仪表盘相关的library可以自定义应用的监控指标
背靠云原生基金会的大树,继K8S之后,第二个毕业的项目,而且是OSS
K8S已经仪表盘化了而且把Prometheus的参数暴漏给它的服务了
并不支持全局的可视性,一些生产集群会把它当成新的需求
操作会很笨重而且花费大量时间
模型会复杂化管理和监督工作
Prometheus并不提供安全的特性。如果Prometheus和Grafana通信在集群内部还好说,如果Grafana在集群之外,你需要在Prometheus上限制连接和访问数据。应对此问题有很多解决方案,但是管理证书,创建ingress controller,Grafana配置安全信息等等工作,需要花费更多的时间和精力。
如果集群是动态变化的,那么在部署Prometheus到集群的时候,最好实现自动化添加数据源到Grafana的功能。
一个dashboard可以提供不同的数据源用于展示,但是我们还是不能跨越不同集群来检索服务。
数据访问的控制更重要了,RBAC的系统可能会需要。大概率会需要集成身份验证系统来保持用户信息实时更新。
架构复杂,需要大量精力部署,优化,维护监控自启动服务
操作成本高,你可以使用DynamoDB等数据库,但是依然需要扩展其他的监控服务,而且数据吞 吐量会很高。
这些项目还在早期地开发阶段,即使有专职小组来负责,生产环境中运行仍然有风险。
联系客服