iLogtail作为阿里云开源的可观测数据采集器，以其高效、灵活和可扩展的特性，在可观测采集、处理与分析领域受到了广泛的关注与应用。在iLogtail两周年之际，我们对iLogtail开源社区进行了一次使用调研，旨在深化理解用户初次接触与采纳iLogtail的最佳路径，同时为促进社区生态繁荣，确保输出内容的高质量与高度相关性提供数据支撑。
尽管收集到的有效问卷数量可能未达到传统统计显著性的门槛，但这批反馈却异常宝贵，为我们的策略制定与优化提供了第一手的洞察力。这些见解不仅直接源自实际应用场景，还蕴含了用户对于提升iLogtail功能体验、文档丰富度及社区互动多样性的真切期待，为后续的社区建设与发展指明了方向。
关键要点
- 51.85%的使用者已经将开源版iLogtail用于灰度或大规模生产环境，22.22%的使用者的部署规模超过1000台。
- 绝大部分开源版iLogtail使用者，在容器化场景中部署iLogtail（85.19%），其中81.48%使用Kubernetes，18.52%使用Docker。
- 66.67%的受访者有参与社区开发的意愿。在有开发意愿的受访者中，实际参与过开发的占40%，85%的受访者表示完善文档有助于他们进行开发，55%的受访者认为社区需要及时更新开发需求。
- 40%的受访者留下了联系方式，并愿意通过文章、开发者会议等方式分享使用iLogtail的案例、场景，在此向他们致谢。
详细分析
社区眼中的开源版iLogtail
本次调查，有90%的受访者正在使用iLogtail。
调研结果显示，大多数用户是通过官方渠道，如宣传文章和公众号，首次接触到iLogtail，这不仅体现了官方宣传的有效性，也反映了高质量技术内容对于开源项目推广的重要性。
高性能、容器化友好以及丰富的插件生态成为用户采纳iLogtail的关键驱动力，凸显了项目设计之初便紧密贴合现代IT架构需求的前瞻性。
尽管用户对iLogtail的性能与稳定性给予高度评价，但对文档质量的反馈也明确指出，加强文档的详实性和易用性是当前社区发展的关键一环。
开源版iLogtail的使用情况
使用iLogtail的受访者们，分享了他们的使用场景。
容器化技术，尤其是Kubernetes的广泛应用，成为iLogtail部署的主流场景，占比高达81.48%，反映了iLogtail在云原生环境下的高度适配能力。
所有主机/服务器/虚拟机环境的开源iLogtail使用者，均在Linux环境部署了iLogtail，同时也有部分用户在Windows环境下部署iLogtail。
而Kubernetes场景的使用者，绝大部分都选择使用Daemonset方式部署iLogtail：
大半使用者所在的组织将iLogtail应用到生产环境，更是有22.22%的使用者的iLogtail部署规模达到了1000+台。
我们也统计了开发者对iLogtail插件的使用情况。受访者最常使用的处理流水线插件排名前三的是：
- input插件
- 采集文本日志（file_log/input_file），70.37%
- 采集容器标准输出（service_docker_stdout/input_container_stdio）48.15%
- 消费kafka数据（service_kafka），48.15%
- processor插件：
- json解析（processor_json），59.26%
- 正则解析（processor_regex），59.26%
- 添加字段（processor_add_fields），44.44%
- flusher插件：
- kafka输出（flusher_kafka/flusher_kafka_v2），74.07%
- 标准输出（flusher_stdout），25.93%
- ES输出（flusher_elasticsearch），25.93%
- input插件
我们发现，在数据输入场景，文件与容器的标准输出扮演着不可或缺的基础角色，作为历经时间验证的数据源，其核心价值不容忽视。Kafka作为数据流处理领域的中坚力量，日益凸显其重要性，成为数据摄入的首选工具，这一趋势不仅彰显了实时数据消费模式的飞速发展，亦反映了市场对此类解决方案的广泛接纳与信赖。
在数据解析的维度上，正则表达式与JSON解析是经久不衰的常青树，是数据解析最坚实的底座。在此基础上，自定义字段功能，包括但不限于字段的动态增删等精细化操作，它们的价值逐渐凸显，越来越多的开发者在使用、开发相关的功能。
谈及数据的最终归宿与应用输出，大家愈发倾向于将数据流导向那些历经市场验证、稳定性与效率并重的日志管理平台及顶级消息队列服务，诸如阿里云SLS、Elasticsearch与业界领先的消息中间件Kafka等，这些平台以其强大的数据处理与集成能力，确保了数据价值的最大化利用与洞察的即时性。相对地，使用http、grpc、otlp协议消费数据的配置就少很多，可能是因为这些方式需要自建消费端，没有直接使用成熟的方案来得快捷稳定。
另外，我们惊喜地发现有部分开发者已经在尝试使用新推出的SPL处理功能，期待更多来自社区的反馈。
ConfigServer欢迎大家使用
ConfigServer是iLogtail社区为开源开发者提供的简单iLogtail采集配置管控工具。
在本次调查中，我们发现大半受访者（76.67%）没有使用过管控工具ConfigServer。没有使用过ConfigServer的受访者中，65.21%不了解或不知道ConfigServer是什么，其余21.74%认为ConfigServer的功能不符合预期，13.04%没有管控需求，8.7%是自建平台管控iLogtail的采集配置。
在使用过ConfigServer的受访者中，57.14%对ConfigServer做了自定义改造。使用者们对ConfigServer的功能需求最大，其次是UI界面和配置管控。ConfigServer会在这个夏天进行一次升级，届时欢迎大家使用全新版本。
诚挚邀请各位参与iLogtail社区的开发
我们很高兴地发现，有66.67%的受访者表示有意愿参与社区的开发，这一高比例体现了iLogtail社区的活力及用户的参与热情。
然而，“不知道如何开发”（75%）与“不清楚开发方向”（33.33%）成为了阻碍用户参与的主要障碍，这要求社区不仅要优化文档资源，还需要建立更加透明和动态的开发需求沟通机制。我们将致力于减少这类问题的发生，将文档中的开发指南进一步细化、完善，并增加一些开发样例，让每一个开发者都能快速上手iLogtail的开发。
此外，受访者对于完善文档、增加实用教程的呼声，再次强调了高质量文档对降低技术门槛、激发开发兴趣的关键作用。有开发意愿的受访者们一致认为，完善的文档（85%）和社区及时更新开发需求（55%）有助于他们进行开发工作。我们这一方面也在努力，后续我们会推出开源社区的全新官网，重点解决当前Gitbook连接不稳定，文档、活动、需求等杂糅在一起，界面不够美观、重点不够突出等问题，也会定期在新官网上同步社区的需求。
而部分没有开发意愿的受访者们，大部分认为简单通俗的教程有助于激发他们的开发兴趣。
总结
iLogtail作为一款高效、灵活的可观测数据采集器，不仅在容器化部署中展现出卓越的性能与兼容性，也在不断增长的用户需求中发现了改进空间。在iLogtail开源两周年之后，我们的品牌即将升级为LoongCollector，这是一段全新的旅程。新的旅程中，面对开源社区用户的期待与挑战，我们将会：
- 持续强化对外输出体系：
- 搭建新官网，更新社区动态与需求
- 优化开发文档，持续补充开发样例
- 提升插件生态的丰富度与灵活性：
- 关注用户更感兴趣的方向，提供更多功能性插件
- 优化高频使用插件的性能，推出部分高频使用插件的C++版本
- 优化配置管理工具：
- 提供开箱即用的版本
- 优化前端展示
- 增加监控与告警功能
- ……
我们将以更开放的姿态邀请开发者共同塑造项目的未来。我们有理由相信，升级后的LoongCollector将在可观测领域扮演更加重要的角色，引领技术创新与社区共建的新篇章。
