纳尼?自建K8s集群日志收集还能通过JMQ保存到JES
💡
原文中文，约7700字，阅读约需19分钟。
📝
内容提要
本文介绍了京东内网环境中基于K8s的日志收集方案，采用ilogtail、JMQ和JES替代kafka和es，通过配置调整实现高可用性，提升日志处理效率。
🎯
关键要点
- 在京东内网环境中，日志收集方案采用ilogtail、JMQ和JES替代kafka和es。
- 新方案的数据流向为：应用日志 -> ilogtail -> JMQ -> logstash -> JES。
- 核心改造点包括调整ilogtail的nameservers和flushers配置，以支持JMQ的域名解析和日志发送。
- logstash的配置中，使用JMQ作为输入源，设置相应的group_id和client_id。
- 通过简单改造实现了与京东内部中间件的完美融合，提高了系统的高可用性和适应性。
❓
延伸问答
京东的日志收集方案使用了哪些组件？
京东的日志收集方案使用了ilogtail、JMQ和JES，替代了kafka和es。
新方案的数据流向是怎样的？
新方案的数据流向为：应用日志 -> ilogtail -> JMQ -> logstash -> JES。
如何配置ilogtail以支持JMQ的域名解析？
需要在ilogtail的配置中增加解析JMQ域名的nameserver，并调整flushers配置。
logstash的配置中如何使用JMQ作为输入源？
在logstash的配置中，使用JMQ作为输入源时，需要设置相应的group_id和client_id。
新方案如何提高系统的高可用性？
通过简单改造实现与京东内部中间件的融合，提高了系统的高可用性和适应性。
为什么不推荐在私有化交付中单独部署kafka和es？
因为在私有化交付中，考虑到kafka和es的高可用性，不推荐采用单独部署的方案。
➡️
