问题描述
在使用ELK堆栈时，想要去除Logstash，并使用Filebeat、Ingest或Pipelines来替代。用户不确定这些组件之间的关系，以及如何解析自定义日志格式。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
您可以尝试直接使用Filebeat。较新版本的Filebeat引入了“模块”概念，可以应用自定义解析器。它内置了一些用于解析nginx、apache2、redis等内容的模块。虽然不确定如何编写自定义模块，但这可能是一个值得探索的途径。
然而，更高级/自定义的解析可能最好由Logstash来处理，而不是Elastic堆栈中的其他组件。
方案2
如果您愿意使用商业解决方案，可以考虑Sumo Logic。我还尝试过Logly和LogDNA，它们也不错，但功能和特性不如Sumo丰富和强大。我不是这家公司的推销员，只是一个讨厌处理糟糕和不完整日志收集的DevOps人员。
在处理复杂的ELK之后，我发现ElasticSearch并不适合初学者，特别是当你进入一个使用4年历史的ELK堆栈的公司时。需要知道的是，Sumo是一个云解决方案，只要您愿意通过HTTPS将日志和指标发送到他们的服务器，这是一个不错的选择。然后，您可以专注于配置功能，而无需维护核心服务。它提供了大部分我记得Splunk具备的功能，而且价格不会过高。正如您可能已经猜到的那样，我刚刚完成了一个项目，将生产日志数据和指标可视化从ELK迁移到Sumo，与Kibana相比，它在输出有用结果方面更容易。我发现统计功能也相似，但Kibana似乎更符合精算要求。它易于设置警报，与Slack等工具的RESTful API集成，执行复杂的数据关联，并为管理层创建漂亮的仪表板。它是一个完整的堆栈。此外，有一个非常成熟的chef cookbook，因此一旦您配置好摄取和规则集，安装和配置非常容易。这可能需要一些时间，但就cookbook而言，我认为它的复杂度中等。数据摄取非常灵活-我还没有遇到它无法处理的限制，但我放弃了尝试直接从logstash摄取，因为获取元数据进行映射比它的价值更麻烦。虽然它们的目标是吸收文本日志，但推送日志和指标也是一种选择。我们继续使用logback进行应用程序日志记录，但现在Sumo几乎收集了我们所有的日志，以及graphite数据。它也很好地处理Windows事件日志。我们正在开始将fluentd与k8s集成，但在控制日志量方面遇到了一些挑战。
Sumo Logic为许多操作系统、应用程序框架和基础设施元素提供了预构建的支持设置，这可以加快初始设置的速度。但一些供应商（如Fastly）甚至提供了先进的预构建Sumo Logic实现，非常出色，因此我们的CDN日志创建了一个出色的仪表板，提供了关于站点健康状况、负载等大量有用的数据。学习曲线肯定存在，但与ELK相比不算什么。如果您想要完美匹配所有正则表达式，以便正确处理应用程序日志中的异常等问题，可能需要一些时间，但如果您希望使用自动时间戳检测和多行检测等功能，可以几乎不费力气地完成很多工作。摄取可以像您希望的那样复杂。我发现在过去的一年中，设置是逐步演进的，我从一个非常基本的设置开始，在其中所有的模式匹配都在查询中完成，但最终我有了摄取规则，可以为我筛选出所有的字段，这使得其他用户更容易使用。此外，支持和文档非常好。作为付费服务，这个服务似乎非常值得，除非您已经是ELK的专家。
希望这些信息对您有所帮助！