纳尼?自建K8s集群日志收集还能通过JMQ保存到JES
内容提要
本文介绍了京东内网环境中基于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。
-
通过简单改造实现了与京东内部中间件的完美融合，提高了系统的高可用性和适应性。
延伸解读
新方案的优势
京东的新日志收集方案通过使用JMQ和JES替代传统的Kafka和Elasticsearch，能够在私有化环境中实现更高的可用性和适应性。这种替代方案不仅降低了对中间件的依赖，还优化了数据流向，提升了日志处理效率，适合需要高效日志管理的企业环境。
配置调整的重要性
在实施新方案时，ilogtail的nameservers和flushers配置的调整至关重要。这些配置确保了JMQ的域名解析和日志的正确发送，直接影响到系统的稳定性和性能。因此，用户在部署时需特别关注这些配置的正确性，以避免潜在的日志丢失或延迟问题。
与传统方案的比较
与传统的Kafka和Elasticsearch方案相比，京东的新方案在资源占用和维护成本上可能更具优势。由于JMQ和JES的底层架构与Kafka和ES相似，用户可以在不牺牲性能的情况下，享受更简化的部署和管理流程。这使得企业在选择日志收集方案时，可以考虑更灵活的选择。
延伸问答
京东的日志收集方案使用了哪些组件？
京东的日志收集方案使用了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的高可用性，不推荐采用单独部署的方案。
