如果企业采用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是系统层的，对应用层无倾入，但是开发人员的控制和定制弱。具体框架和运维团队要协商综合考虑，哪种更适合，当然也可以两个都用结合起来。

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！