elk加载本地日志_您应该停止在本地托管ELK堆栈的5个原因

elk加载本地日志

托管的ELK堆栈：集中管理日志以获取乐趣和收益

您的口中看不到礼物马。 特别是如果它不是一匹马，实际上是麋鹿。 它会用鹿角戳您。 或喝醉了的发酵苹果，把后院丢掉 。 尽管这是我们愿意接受的职业危害，所以让我们以任何方式来看一下。

在本文中，我们希望分享一些有关您自己部署和管理ELK堆栈的注意事项，并向您介绍托管ElasticSearch的世界。 换句话说，什么时候从管理自己的ElasticSearch部署继续进行下去，以及当您决定切换此开关时有什么选择。 经过双方的努力，并且了解每个团队和系统都有其独特的要求，我们希望分享一些见解，以帮助您根据自己的环境做出正确的决定。

自己托管ELK堆栈有什么问题？

考虑开放源代码软件的情况时，您可以将任何项目大致放在实际使用的难易程度之间。 趋于怪异并使其按自己的意愿去做是多么复杂/耗时。 然后，可以将易用性分解为诸如部署和设置，工具入门，集成，UI，可伸缩性，稳定性和…维护等参数。 剧透警报：这3个区域是我们受到打击的地方。 因此，如果您可以将诸如Logback之类的项目放置在规模较小的一方，那么ELK就会深入到困难的一方 。

1.扩大规模的痛苦

我们对内部ELK部署感到非常满意，但是随着越来越多的新用户加入Takipi，各种问题开始出现。 在Takipi的情况下，用户将Java代理附加到其JVM，然后他们可以监视其生产环境中的异常并将错误记录到导致它们的可变状态 。 考虑一下您自己的应用程序中数据的规模，每天发生数十亿个事件，现在将其乘以数千。 我们构建的Kibana仪表板不仅可以提供整个系统的概述，还可以深入查看单个用户的视图，从而使我们在需要时为用户提供支持：

Takipi较旧的Kibana仪表板的一部分

当产品达到一个阶段时，临界点就出现了，在该阶段中，拥有数十台或数百台服务器的公司能够组建完整的团队，并扩大其系统的可视性。 统计数字飞跃图表。 我们可怜的Kibana仪表板也是如此，该仪表板开始挂得太频繁了。 在此阶段，我们正在尝试将ELK堆栈主要用于BI用途以及偶尔的高接触支持，因此它并不是关键任务。

第1课：向高规模迈进时，请勿将ELK堆栈留在后面。

2.稳定性受到重创

起初是偶尔出现的缓慢且悬空的Kibana仪表板，后来Swift变成崩溃了，跌落到ElasticSearch上。 索引大小大于分配的RAM的艰难查询导致大量OutOfMemory异常，最终导致数据库无响应。 快速的解决方案是重新启动它并使查询变得容易。

第2课：浏览Kibana仪表板时，请注意那些大查询。

真正的解决方案虽然需要调整$ ES_HEAP_SIZE ，更强大的AWS实例，更多RAM，磁盘空间也用完，所以我们也需要对此进行补偿。 如果您不希望偶尔刷新数据库，则通过循环日志可以缩短历史记录记录或增加磁盘空间 。

第3课：从简单的部署和集成过程开始，很快就变成了需要不断监控和领域专业知识的问题。

3.惊喜！ 您现在是ElasticSearch DBA

在此阶段，特别是如果您不仅要使用ELK来获取BI统计信息，还要通过它来流水所有日志数据，那么使用付费订阅服务以获得专用支持和监视/安全/权限管理功能可能是有意义的。 整个shebang。

第4课：当不同团队的成员需要访问Kibana仪表板时，您可能需要设置访问权限和用户控制。 修补自己的解决方案可能不是最明智的选择。

随着ElasticSearch集群的增长和获得，还有更多需要注意的事情包括升级，备份和节点之间的分片管理……很好……有弹性。 在不知不觉中，您就充当了ElasticSearch DBA的助手，它消耗了越来越多的时间。 当然，这取决于您的开发团队的规模以及是否有必要在内部投入更多时间。

第5课：为您的ElasticSearch集群扩展更多的节点相对容易，并且只需要进行一些设置即可，但不要失控-另一个节点不一定是正确的解决方案。

输入托管的ElasticSearch服务

简而言之，如果在内部设置中，我们已经通过Logstash将日志通过管道传递到ElasticSearch集群，该集群是在几个AWS节点上设置的，顶部是Kibana仪表板，那么我们决定移至托管的ElasticSearch解决方案。 在托管模式下，ElasticSearch集群管理无所不用其事，您可以自由地专注于其他事情。 这里的两个主要问题是：它会扩展规模吗？要花多少钱？

基本要求是使用将服务器托管在您日常使用的同一云托管提供商上的服务。 因此，如果您使用的是AWS，则需要使用AWS的托管ElasticSearch服务。 节省成本并确保更好的网络性能。

定价：使用托管服务的成本要高于单独运行托管服务所需的基础结构。 在专家和DBA的支持下，您获得的好处是可以腾出时间来管理ElasticSearch部署。

• Found.no （AWS）
• QBox.io （AWS，Rackspace，SoftLayer，Azure）

这两个可能是当前可用的最受欢迎的解决方案。 Found是最近由Elastic收购的，从长远来看，这将如何影响他们的产品将很有趣。 就定价而言，这两种服务均按小时计费，具体取决于磁盘大小（和类型），内存和数据保留等参数。 定价还受您选择在其上托管ElasticSearch服务器的区域的影响，并且如果您需要更长的数据保留时间，那么假设您的账单每月将超过1000美元就不会太过分。

有这么多的活动部件，最好尝试一些解决方案，获得最能反映您需求的定制报价。 安装和设置有望很快实现，而价格成为此处决策过程的主要因素。 就实验而言，Found拥有14天的试用期（在2个AWS区域上具有1GB内存，8GB存储空间），并且QBox为新账户提供60美元的信用额度。 这足以使人感觉到该产品，但可能不足以进行全面的测试运行，而这可能需要进行一些协商或付费的POC。 切换服务的成本非常低，只需进行一些配置更改即可，因此您有机会在这里尝试一些失去历史的缺点。

但是， 如何确定您的要求呢？ QBox和Found有一些不错的教程，请在此处和此处查看这两篇文章。

Found.no：它将为您获取数据

• Logz.io （AWS）
• Bonzai （AWS）
• 撰写 （AWS，DigitalOcean，SoftLayer）
• FacetFlow （Azure）
• Sematext Logsense

当前，在Takipi，我们正在使用Logz.io测试水域，该公司还支持将日志运送到ElasticSearch，而不必使用Logstash。 除了这个领域中的两个更大的参与者之外，我们还看到了更多服务，例如Bonzai.io，Compose.io，FacetFlow等。 每个提供自己的管理仪表板，将Kibana扩展为ElasticSearch的可视化引擎。

Logz.io Kibana仪表板

结论

ELK堆栈是一个了不起的开源平台，为日志管理提供了一个完整的解决方案，易于上手，而且令人眼花candy乱，但是从长远来看，要进行管理–事情会有些尴尬。 尽管ElasticSearch可以很好地进行扩展，但是您需要付出的努力往往可能超过使用免费开放式解决方案的好处。 那是您需要研究获得专业服务，吞服药丸并让托管的ElasticSearch即服务解决方案减轻痛苦的地方，从而继续享受集中式日志管理和可视化的好处。

翻译自: https://www.javacodegeeks.com/2015/08/5-reasons-you-should-stop-hosting-your-elk-stack-locally.html

elk加载本地日志