To ELK or Not to ELK？这是一个问题

选择开源方案还是商业解决方案？这一直是软件行业的争议话题。本文谈的是日志管理工具的选择，从五个方面讲解，应该选择ELK还是商业方案。
开源还是商业？争议会一直持续下去，但本文的思路却可以给迷茫中的人们一个参考。

为什么Elastic Stack／ELK在日志管理圈这么火
自从2015年Elastic发布ELK Stack，并在今年早些时候重新命名为Elastic Stack，这件事吸引了开发者及DevOps团队的广泛关注。很多客户已经在评估在Elastic Stack上运用我们的基于云的日志管理服务。而作为业内拥有最大最复杂的Elasticsearch部署集群之一的我们来说，我们的工程师团队一直在关注Elastic Stack的演变。
老实说，Elastic创建了一个非常好的开源项目。事实上，我们用了Elastic Stack中的Elasticsearch搜索引擎部分，作为Loggly架构的核心。Elastic Stack的确提供了很多重要的东西，而且还在迅速发展。作为开源项目，它有“免费”的地方。当然，“免费”并不是意味着无成本。引用自由软件基金会的话：

“自由软件”是一个自由的问题，而不是价格。可以这么理解这个概念，应该把“自由”理解为“言论自由”，而不是“免费的啤酒”。我们有时称之为“自由软件”以表明它不是免费的。

本文中，我们将看一下，你在决定用Elastic Stack还是一个商业的日志管理工具时，应该考虑哪些因素。
自己酿造 vs 买现成的？
让我们尝试用大家都能接触到的东西来类比：啤酒！自己酿啤酒是很容易的。花点钱准备下硬件，研究一下如何使用，自己买些麦芽、啤酒花和酵母，就可以开始了。
但你真的付诸行动了吗？

用同样的方式思考一下你在面对日志管理问题的决策。

你想投入多少内部资源进行日志管理？

先不考虑你是用自己的设备来运行Elastic Stack堆栈还是用Elastic、Amazon或其它厂商提供的云服务来运行，使用这些资源来运行日志管理，需要投入大量工程资源，包括：

并不打算让你的产品运行更好的人员

并不搭载这个产品的服务器，需要管理（并且要花钱）

请记住，在多数组织中，维护一个内部的日志管理平台的人，并不会被认为多荣耀的专家。而且当它运行的好时，没人知道你，但如果它运行出问题时，你可就成焦点了。

Elastic Stack的客户引用两个需要特别专业知识的方面：

数据处理：用Elastic Stack，任何日志数据预处理都需要你去写天书般的过滤器。同时也意味着日志数据变化时需要维护这些过滤器。而相反的，Loggly提供很多日志类型的自动解析。任何我们解析不了的日志类型，你可以不用借助特殊语言，构建自定义字段。用Loggly，你可以通过一个点选界面或者表达式定义自己的字段。

用户管理：多数人都说使用Elastic Stack很痛苦。托管的Elastic Stack服务能避免很多问题，但是你仍然需要配备一些内部专家资源。

部署和运行Elastic Stack组件是很容易的。但关于部署你仍然需要搞清楚：需要多少台服务器，应该如果配置它们，需要多少冗余。类似的问题，在考虑Elasticsearch 拓扑（例如，多少节点？无数据主节点？Hot节点？多少堆栈？）及参数（例如，多少？多少分片？多少种类型？）时，也需要有答案。

你会说，没什么大不了的？好，这些问题随着时间会改变。当你需要往Elastic Stack推送更多日志或者深度使用时，你就必须得管理各种参数。事情会越来越糟。随着新版发布，就需要花时间升级你的集群。

你最终成了一个Elastic的专家，而你本该成为自己产品及业务的专家。

如果你的产品本来就是基于Elastic Stack构建的，那么这的确是个好主意。但如果你只是用它来记录日志，那还有意义吗？获取这些所谓“专家知识”的精力，本来应该花在自己的产品上：如果同样的时间和资源花在产品上，能否更好，更快，更稳定？你如何理解你对数据的需求？

Elasticsearch可以成为一头复杂的怪兽。如果你配置的不对或者滥用它，那可能会导致严重的后果。你可以轻易用上Elastic Stack赋予你的能力，但它毁掉你也很容易，最终你被拖入深渊，无法自拔。我们已经在做Loggly时遇到太多教训，我们的系统足够强大，因为我们不仅知道Elasticsearch适合什么用途，更知道它不适合什么用途。

例如，当用Elasticsearch查询非常大的索引时会导致OOM问题，解决这个问题需要很高的技能要求（或者堆硬件）。（benchmarking上我写的电子书种，有相当篇幅是分析这个问题的。）Tapiki也曾分享过这个问题的处理经验。

在那之上，如果你确实想从日志中获得更多信息，你将不得不深入了解Elastic是如何收集日志并把它们转化成有用数据的。Elastic是无模式的，所以你不必提前定义好数据。这很好，但你必须知道想要如何使用这些数据，然后按照能获取最大信息量的格式来发送它。我并不想把这个说的像多尖端的科技，但当你开始时，的确会遇到一些坑，导致浪费宝贵但时间。

如果仅仅是少数几个开发者查看应用程序日志，那事情还算简单。但当你的产品进入生产环境后会怎么样？或者当你想分析一下它如何运行的？或者你意识到还需要处理数据库日志？系统日志？。。。而真正灵活、强大的工具，好处就在于你总能发现它可以处理更多的新数据类型。我发誓：一旦你看到这样的系统，你就会迷上它。不利影响就是，你会沉迷，沉迷于将时间戳数据流转换成你可以过滤的，或按不同方式分片、分块的格式化数据。

你对你的日志数据量有足够的认识吗？

就像前面提到的，我们服务过75000多家客户，经验告诉我们日志数据量是多么难以预期。当我们的其中一个客户有问题时，我们看到它的日志数据量以10倍甚至更大倍数增长。谁没有过在生产环境错误地启用了调试日志开关？当我们能管理尽量多日志时，这都不是问题，但如果你只是做了一个简单的日志方案时，这就是大问题了。这就是为什么任何日志管理系统都需要建立大量冗余以及强大的队列机制的主要原因。

当然，冗余意味着代价。Elastic Stack的TCO不可预测性也是需要随时预备额外硬件的原因之一。一旦人们依赖于这套安装，问题和故障将会更让人痛苦。初期的一两次中断可以作为成长代价，但当中断出现在了错误的时间节点（例如，一个C级策略会议上），那唯一的解决方案就是加机器，事情开始越来越有趣了。

使用托管的ELK服务可以减轻不可预测性，但也会增加你的使用成本。我们已经花了6年来优化我们的搜索基础设施，我们在做的事，单个客户系统来做都没有太大意义。如果你每天要处理TB级日志数据，那么为Elastic Stack付出时间和努力也许还有意义。如果没那么多数据，你应该停下来想想如何支配你的时间（和资金）。

你需要多快收到问题告警？

一旦将日志接入Elastic Stack，你去探索那些框架、应用、服务，看发生了什么。你会发现可怕的事情。但你不能只是坐在屏幕前每10分钟按一次搜索按钮（尽管这也可能有些乐趣）。幸运的是，你可以让系统帮你做－自动运行这些搜索，并在出现问题时提醒你。

告警，这不仅仅只是一个好主意而已。。。

如果你做了订阅，Elastic提供了观察者模块，也有些使用Elasticsearch实现的开源告警模块，你要么为了订阅付钱给Elastic（会增加你的TCO），要么花精力和时间研究其它的开源项目。再次强调一下，我并不是想说这需要多高智商，但需要更多时间，可能导致潜在的升级成本。

如果你在开发过程中，是否及时发现问题也许无所谓。如果你是在生产环境中运行一个app，服务很多用户，甚或有服务级协议用户，那及时报警就是必须的。这也是Loggly不仅提供邮件告警，还集成了很多您可能准备用来运维您的应用的终端的主要原因，这些终端有PagerDuty, HipChat, Slack,和 VictorOps。

你需要商业级支持或者SLA吗？

当使用开源软件（即便是被托管的），遇到中断或者bug，你需要自己解决。开发者社区在处理bug时，可能反应很快，很高效，但也可能恰恰相反。你遇到的导致实例无法运行的bug，可能是一个罕见的，大家都不关心的问题，至少短期内是这样。也或者你在某段时间在运行一个旧版本，开发者社区早已经迭代到下一个版本，且新版本已经解决了这个问题。但没人会对修复旧版感兴趣，而你也可能没人或资源去做这件事。这都是要考虑的情况。

当然，你可以付钱给Elastic，让他们提供技术支持（他们肯定能做的很棒），但你的“免费”软件，突然就会变的比你预想中要昂贵的多。

如何让日志管理更好的服务于核心业务？

总的来说，开源vs商业软件的辩论，问题不在谁更好或更强大上。大多数时候，会简化为自建vs购买的讨论，要考虑TCO、支持和维护等问题。

事实上，很多开源日志解决方案都是基于开源基础之上的，Loggly也不例外。当你使用Loggly时，你实际上利用了Elasticsearch，Apache Lucene，Apache Kafka，还有很多开源软件组件。归究起来，问题就是：你是投钱和资源构建并维护自己的解决方案，还是购买给你的业务带来最好回报的解决方案？

如果你正在开发的初期，相比资金来说，更不缺时间，Elastic Stack可能是一个不错的选择。（至少应该是一次有趣的尝试）如果你的应用本来就用到Elasticsearch，那么拿它来做日志管理就不需要额外的专门知识，但其它成本因素仍然需要考虑。

如果你已经不是早期发展阶段，且产品中没有用到Elastic，你会发现作为单个个体的用户，你是很难实现Loggly提供的这种规模经济的优势的。你还需要处理维护、升级、中断、对接新数据源，为旧数据提供新的解析模板。对Loggly，成千上万的客户付费给我们，支持我们的维护工作，对他们来说，这些工作都像魔法一样发生了。而且，我们以提供日志管理服务为生，你的开发者应该还有其它事情要做。

To Stack or Not to Stack？你来决定

让我们回到自酿啤酒上，问题：你真的付诸行动了吗？

如果酿啤酒是你的爱好，你喜欢尝试不同的技术，也有闲钱购买大玻璃瓶，专用比重计，和你自建的粮食加工厂，那么，你就做吧。但如果你的啤酒被污染了，或者溢出来了，你需要花数个小时清理，那就另当别论了。要酿出一杯好啤酒，有很多恼人的事情需要做。清洁、消毒，各种注意事项，不断重复，然后等待。。。等待。。。就为成功的发酵。你可能会省很多钱（如果你酿的多的话），但你肯定会浪费大量时间。

生活中，这些由你自己决定。但当你在工作中，这些事情就更复杂了。

对于多数公司来说，时间比金钱更宝贵。有时，你只是立刻需要一杯啤酒！而自酿啤酒的难点就是怎么确保每一批都像最后成功的那批一样好。也许你应该直接买六瓶装的Firestone Wookey Jack？

规模也是很多公司面临的问题。如果你每个月增长10%，一年就会增加到原来三倍。从何时起，你从家庭作坊自酿变成了一个小型啤酒厂，而一时的兴趣成为了全职的工作（这还是你的初衷吗？）

我并不是争辩说家庭自酿就一定是个坏的决定。给出我们自己在Loggly开发了多少代码？这是很愚蠢的。老实说，维护Elastic Stack会让你感觉像一个超级英雄（我们有些人也这么认为！）但“As A Service”（即现成的）方式正越来越普及的一个重要原因就是，你不需要成为X技术的专家，也能受益于它的巨大价值。有时候，你甚至可以完全不懂它。变成一个Elastic Stack专家，可能让你更有实力，但如果达到那个水平了，你是否有其它事情还没做呢？

如果你在研究Elastic Stack，我个人邀请你测试一下Loggly。你有30天体验我们的全部功能，并仔细思考本文提到的问题。

本文翻译自：https://www.loggly.com/blog/to-elk-or-not-to-elk-that-is-the-question/
原文作者：Jon Gifford
译者：日志帮（微信id：rizhibang）