ELK、EFK、Prometheus、SkyWalking、K8s的排列组合

举报
JavaEdge 发表于 2021/06/03 23:37:24 2021/06/03
【摘要】 EFK + K8sPrometheus+ K8sSkyWalking + K8s 这3个监控组合都非常不错,那在实际生产过程中,对一家中等规模的微服务业务应用,该如何选型呢? 如果企业采用spring + k8s技术栈,EFK + Prometheus + SkyWalking就是我推荐的监控三套件,这三个分别是日志、metrics和调用链监控的利器,社区生态好。 ...
  • EFK + K8s
  • Prometheus+ K8s
  • SkyWalking + K8s

这3个监控组合都非常不错,那在实际生产过程中,对一家中等规模的微服务业务应用,该如何选型呢?
如果企业采用spring + k8s技术栈,EFK + Prometheus + SkyWalking就是我推荐的监控三套件,这三个分别是日志、metrics和调用链监控的利器,社区生态好。

而CAT主要为物理机/虚拟机场景研发,容器环境应该也支持,但是文档资料较少。总体CAT是一个不错的产品,但是相对门槛较高,社区和文档不足。相比而言,skywalking门槛较低,社区文档好,对容器环境有明确的支持。

方法级监控可以用Promethues,但是需要对方法进行埋点,如果是Spring应用,你用MicroMeter对方法添加相应的注解即可。注意,最好在框架层统一埋点。

Skywalking也可以监控到方法级,前提是需要相应的plugin支持,如果现成的plugin监控不到你的方法,你可以扩展或者自己写plugin。

elastic不适合用于数据存储 那我们项目里用elastic 也相当于给skywalking做了数据库,稳定性和效率怎么看?
elastic属于一种高性能大容量的nosql数据存储,底层基于反向索引数据结构,在大数据存储、搜索和分析方面有广泛用途。它可以做skywalking的存储,也可以做普通日志存储。关于性能稳定性和效率,elastic本身是分布式高性能设计,实际要看你的调优和运维能力,国内公司如携程,有超过50台机器做成的elastic集群,每天收集存储超过TB级别数据量。

fluentd V.S logstash 有何优势在k8s中

不能说有明显的优势,logstash历史比较老一点,fluentd比较新一点,目前是云原生支持的项目之一。尽管存在一些差异,但Logstash和Fluentd之间的相似之处大于它们的区别。 Logstash或Fluentd的用户在日志管理方面遥遥领先。

skywalking可和EFK共用ES吗?ES集群个数和内存CPU如何分配?

因为需使用istio的熔断流量控制,istio也有一些trace什么的zipkin,怎么选择?

skywalking当然可和efk共用ElasticSearch,它们用不同的index,实际要不要这样弄,具体要考虑业务场景/容量需求等因素。集群节点个数和内存CPU建议先粗略估算,然后监控起来(ES有很多监控手段),运行一段时间后根据监控数据优化容量规划。

zipkin的trace监控是应用层的,可以和应用/框架代码紧密集成,开发定制灵活性更高。istio的trace是系统层的,对应用层无倾入,但是开发人员的控制和定制弱。具体框架和运维团队要协商综合考虑,哪种更适合,当然也可以两个都用结合起来。

架构图


参考

  • https://logz.io/blog/fluentd-logstash/

文章来源: javaedge.blog.csdn.net,作者:JavaEdge.,版权归原作者所有,如需转载,请联系作者。

原文链接:javaedge.blog.csdn.net/article/details/112512500

【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。