市场上有大量的测井系统-开放式和专有的。 它们每个都有自己的功能，各自的优点和缺点。
今天，我们决定分享我们在选择日志记录系统方面的经验，并告诉我们为什么我们停在
1cloud的 ELK。
/ PNG / picupyourphoto / PD分钟理论
当转向生产时，应用程序变成了一种“黑匣子”。 他们的工作需要受到持续监控，以预防和应对潜在的紧急情况，以发现瓶颈。
日志记录系统是必不可少的工具，在此过程中无法避免。 通过对收集到的数据进行详细分析，可以识别网络中的“入侵”，识别配置不当的设备，并立即采取措施。 另外，通过各种认证（例如PCI DSS）时，日志记录也是强制性要求。
有一些用于自动化日志记录过程的特殊框架：log4j，log4net，Retrace，Logback，Logstash等-其中有很多。 他们的日志记录工具具有单独的开发工具，例如JDK-
有java.util.logging 。 当然，各种日志记录工具的功能是不同的，并且必须根据业务需求选择必要的功能集。 但是，在选择用于分析日志的系统时，应注意许多一般要点。
易于使用和社区规模
选择日志系统时，简单性是关键要素之一。 团队中的所有开发人员都使用日志框架，因此，使用此工具的经验应该是积极的，而不会将日志分析变成噩梦。 框架API应该直观，这样，以前从未使用过系统的每个人都可以快速了解系统的组织和配置方式。
如果考虑开放源码日志记录系统，那么评估围绕它形成的社区是有意义的。 为此，您可以研究在专用平台（
Stack Overflow ）以及专用线程（
例如Reddit ）上提到它的频率。 作为一种选择，请查看该项目在GitHub上的受欢迎程度（星数），并查看将其输入网络中各种工具集合的频率（如此
类 ）。 显然，社区越大，在遇到不可预见的困难时帮助您的可能性就越大。
至于专有日志记录系统的选择，首先值得考虑的是答案的速度，所选解决方案的支持服务是否足够以及价格。
收集“杂项”日志的能力
并非所有的日志记录平台都能够处理大量数据并提供有关所用系统的完整信息。
在选择解决方案之前，您应该决定计划收集哪些日志：HTTP日志（将有助于了解站点上用户的行为），API日志（将使评估API最经常请求的服务成为可能），错误日志并仅记录对系统（指示瓶颈，如果有的话）。
可扩展性
日志记录工具应该从每个系统组件收集日志，并在一个地方提供对它们的访问。 如果系统不适合扩展，则日志分析的质量将下降。
我们在1cloud中最初使用MS SQL进行日志记录。 但是，随着客户端和服务数量的增加（例如，最近，
我们在明斯克数据中心部署了设备，并
增加了对IPv6的支持 ），我们开发了无法访问数据库的地理分布的基础架构组件。 我们的主要任务之一是保持从一个地方分析日志的能力。
1cloud记录系统
正如我们已经提到的，MS SQL用于将日志存储在1cloud中，而log4net用于记录日志。 这开始给我们带来一些困难。 由于组件在地理上分散，因此无法维持与数据库的网络连接并提供单点分析。
同时，大量的日志以及无法在需要搜索的所有字段上建立索引的情况导致了日志分析的过度简化-为了性能，我们不得不放弃功能。
为了解决此问题并提供可伸缩性，我们引入了新的日志记录系统。 总共，我们研究了五十多个不同的解决方案，并确定了四个完全满足我们要求的解决方案：
- 一个地方存储日志；
- 必要时对系统进行水平缩放；
- 处理大量数据；
- 强大的日志分析系统。
这四个解决方案是：Fluentd，Graylog，Logalyse和Logstash。
该解决方案在
GitHub上有9.2万颗星。 Logstash已获得Apache 2.0许可证的许可，并且是ELK堆栈的一部分。 它有大量的插件（在GitHub上
有大约250个 ）。 它可以在Windows和Linux下运行，并具有高性能，实际上与数据量无关。
该系统
使您可以快速查看和分析来自工作站，防火墙，路由器和交换机的事件。 这是由于不需要事件的“规范化”这一事实。
但是，应该理解，这是一个“裸机”引擎，因为它不提供现成的可视化效果。 除其他缺点外，我们注意到需要在所有服务器上安装Java，因为Logstash是用Ruby（JRuby）编写的。
该解决方案有一个相当大的社区：有一个
IRC频道和一个单独的
论坛 。 网络上有一些示例，用于
配置整个系统和
API 。 以下组织
使用 Logstash：CERN控制中心，GitHub，SoundCloud。
GitHub上有 6.6千颗星。 它由
CNCF （云原生计算基金会）在Apache 2.0许可下分发-它是由Google和Linux基金会共同
创立的 ，旨在推广容器技术。
Fluentd在Linux，Windows和Mac上运行，并以Ruby（CRuby）编写。 Fluentd具有
灵活的插件系统 ，可扩展其功能。
该解决方案具有统一的日志记录格式：Fluentd尝试将接收到的数据转换为JSON格式。 为了确保可靠的操作，不需要第三方解决方案，但是为此，必须执行其他配置。 也建议不要将其安装在生成日志的服务器上。
社区很大：
Slack中有一个
渠道 ，Google Groups中有一个
线程 。 在该项目的官方网站上，
有一些配置和
API的 示例 。 像Microsoft，Amazon，change.org和Nintendo这样的公司都使用Fluentd。
GitHub上有 4.3千颗星。 根据GNU GPL v3许可证分发。 它仅在Linux下工作。
插件和自定义缓冲系统的集中式
生态系统。 为了方便起见，它允许关键字将传入的消息组合成流，并将来自不同主机的这些流分组。
该系统使用Elasticsearch功能，但是尽管Graylog和开发社区经常更新（有一个
论坛 ，一个
IRC频道 ，官方项目网站上
有配置和
API的 示例 ），但将Elasticsearch当前版本集成到该项目中仍需要很长时间。 例如，去年出现了一种情况，Graylog 2.2.1（当时的最后一个版本）
仅适用于过时的Elasticsearch 2.4.4版本。
Graylog在其工作中
使用了欧洲环境署，一次拨号，Stockopedia等。
它可以在Linux和Windows下运行。 该系统具有高性能，并且可以生成有关关键字的详细报告。 有一个严重的缺点-LOGalyze将日志收集到其文件数据库中，然后对其进行索引，从而占用了大量的磁盘空间。
LOGalyze开发人员
拥有自己的博客 ，并且该解决方案的讨论在
Google小组中进行 。 有
关于系统
配置和数据
迁移以及
CLI的指南 。
在评估了这四个选项之后，我们选择了Logstash并决定组织一个ELK堆栈（ElasticSearch，Logstash，Kibana）。 其中，Elasticsearch是搜索引擎，Logstash是用于收集和分析日志的机制，而Kibana从事分析和数据可视化。
我们之所以选择ELK，是因为这三个组件都是由一个“制造商”开发的，因此它们可以很好地集成在一起。 如有必要，我们可以单独使用每个工具来解决其他问题。
这种方法使产品具有灵活性和多功能性。 所有这些将使现有数据量的处理效率更高，新服务的实施速度更快-连接起来将更加容易。
现在测试环境已经准备就绪。 它“覆盖”我们将分析其日志的所有服务。 我们正在完成最后的调试过程，并计划在不久的将来全面启动该解决方案。
顺便说一句，尽管我们详细分析了各种选择并选择了最佳选择来满足我们的需求，但最后，美中不足的是。 在测试解决方案时，我们面临一种情况，即Kibana应要求放弃了Elasticsearch-这被认为是极为罕见且简陋的案例。 同样在系统的“组装”期间，出现了许多问题，主要涉及安全性。 在基本版本中，Elasticsearch不受任何保护-为此，有必要对第三方软件进行调整。
启动后，我们将设置监视系统，以对日志服务中的故障尽快做出响应。 我们希望新技术栈能够改善客户的用户体验，并更快地进一步发展我们的服务。
我们公司博客中的资料：