2017年伐木生态系统概述-CSDN博客

正在记录。可以公平地说，这是现代计算的基本原则。它可以帮助开发人员调试应用程序，并帮助系统管理员和DevOps员工调试服务器中断。因此，日志对于提供解决问题所需的信息和上下文至关重要，既可以解决问题，也可以从历史上下文中了解它们。

但是，就像计算中的任何东西一样，日志记录的状态永远不会停止。现有的概念已经不合时宜，新的概念取而代之，而其他的概念却是永恒的-有时会持续数年。相同的模式适用于现场或异地托管的工具和服务，无论是商业的还是开源的。

那么我们现在在哪里？目前掌握哪些趋势，工具和哲学，为什么？好吧，今天，我将考虑伐木生态系统的三个领域，以了解该行业在2017年中期的状况。

具体来说，我将看一些更著名的：

哲理
最佳实践
服务和工具选项

在深入探讨之前，我先坦率地承认：我首先是一个开发人员，然后是系统管理员和DevOps人员。结果，我的观点和我在本文中所做的选择都相应地带有颜色。请记住这一点。

就是说，让我们开始吧。

伐木生态系统的哲学

我要讲的第一个领域是伐木哲学。在此，我想看两个概念：日志存储和日志文化。

日志应在何处以及如何存储？

是否应将日志保存在组织内部由您自己管理的服务中？还是应该使用Loggly之类的SaaS或我们稍后将介绍的其他工具之一，将日志数据存储在直接控制之外？

据我了解，主要区别从根本上讲是安全性和数据敏感性的问题。您是否拥有组织外部的人绝对无法看到的信息？

如果是这样，那么最好自己托管一个解决方案并登录该解决方案，例如Apache Kafka或Elastic（以前称为ELK）堆栈。如果您的数据不那么敏感，那么从商业供应商之一（例如Loggly ， Graylog ， SumoLogic和ElasticSearch）托管的解决方案可能是更好的选择。

似乎仍充斥讨论的另一个考虑因素，例如Hacker News上的讨论，是效率问题。更具体地说，对于作为组织的内部组织日志记录解决方案，例如基于Elastic Stack的内部日志记录解决方案，我们值得付出努力吗？还是与供应商托管我们的数据更好？

对于这样的问题，从来没有一个明确的，一刀切的答案。我继续看到的最一致的答案仍然是“取决于情况”。没有两个组织或应用程序是相同的。对一个人有用的不一定对另一个有用。一个人可能有更多资源和经验可用于分配任务。另一个可能不会。

因此，如果2017年伐木生态系统中存在一个重要的哲学常数，那么仍然应该将伐木数据存储在何处的问题。

边车应用

至少对我来说，新功能是一个名为sidecar应用程序的概念。如果您以前从未听说过它，那么它与使用容器部署应用程序主要相关，因为它与基于容器的部署紧密相关。

Loggly的Garland Kan将其最简洁地描述为：

…将应用程序容器和日志记录容器配对的概念。

当 Voxxed 这样描述时，它提供了更大的深度：

Sidecar应用程序与您开发并部署到服务器/主机实例的每个微服务一起部署。它在概念上被附加到“父”服务上，就像将摩托车边车连接到摩托车上一样，因此也被称为“父”服务。边车作为第二个过程与您的服务同时运行，并提供通过同类接口（例如，基于HTTP的类似REST的API）公开的“平台基础结构功能”。

在日志记录的上下文中，将向部署的堆栈中添加一个额外的容器，在该堆栈中将存储应用程序的日志，该容器还可以将这些日志转发到外部服务，例如LogEntries或Splunk。据我了解，该概念可以在较小的应用程序中很好地工作，但可能难以有效地扩展。也就是说，这是一个有趣的概念。

伐木文化

现在让我们看一下文化-任何计划的一个非常重要的方面。明确地说，最近让我印象深刻的是Stackify的一句话，当时他们说：

…我们建立了“伐木文化”…

我发现这是近年来最好的改进之一，因为如果没有支持的文化，想法和概念很可能只是暂时的。我相信我们大多数人都可以与测试进行中的岁月有关。一开始它总是很棒。但是，如果没有一种支持的文化，当截止日期和其他压力开始累积时，文化很快就会被淘汰。

在帖子中，Stackify继续说：

[伐木文化]着手实现以下目标：
记录所有事情。尽可能多地记录日志，以始终拥有不增加开销的相关上下文日志。更聪明地工作，而不是更努力。将我们的所有日志整合并汇总到一个中央位置，所有开发人员都可以使用，并且易于分发。另外，找到用于记录日志和异常数据的新方法，以帮助我们主动改进产品。

这里有一些优点，尤其值得一提。

尽我们所能记录

与我前几年所见和所经历的相反，这表示记录更多而不是更少记录的重要性，只要该信息是上下文相关的即可。这与Sumologic于 2017 年4月写的内容相吻合：

您的日志应该讲一个故事。

对我而言，这是完全合理的，并且是取得成果的绝佳发展。

虽然我不认为应该为此而记录日志，但是我们拥有的（上下文）信息越多，我们越有能力解决不断发生的问题。

登录到中心位置，所有开发人员均可使用

所有人都可以集中访问信息是另一个令人振奋的发展，看到它变得越来越强大。

当信息保存在中央位置时，使用起来会容易得多。当每个人都可以访问它（ 并看到它）时 ，它增加了确定日志内容的责任，并且需要更快地解决问题。如果可以隐藏信息，那么掩盖或掩盖问题就变得容易了。

我想相信，随着这两种理念的发展（尽可能多地记录并记录到中心位置），我们的应用程序质量将提高，停机时间将减少，从而使用户和开发人员更加满意。

注册免费的Codeship帐户

最佳实践

现在，我想看一看我在一年中获得的最佳实践的中心主题之一：我们创建的日志是人类可读的还是有效解析的日志？

似乎已经达成共识，即人类更擅长处理不合逻辑，不一致或不具有标准模式的数据，而计算机则不然。相反，人类并不擅长处理大量数据，而计算机却擅长处理。鉴于此，我们面临着一个挑战：我们是否要创建可以个人操作的日志，还是可以使它们高效地用于计算机处理，并使其在以后可读？

我发现，除非您仅记录少量信息，否则，共识是最好着重于处理效率，尽可能多的上下文而不是人类可读性。

但是高效，内容丰富的日志条目是什么样的呢？例如，Dan Reichart（来自SumoLogic）通过虚拟的航班预订服务提供以下服务：

2017-04-10 09:50:32 -0700 - dan12345 - 10.0.24.123 - GET - /checkout/flights/ - credit.payments.io - Success - 2 - 241.98

总而言之，条目中的每个元素都由-序列分隔。元素依次是：

日志时间戳
购买者的用户名
用户的IP地址
请求方法
请求的资源
请求网关或路径
要求的状态
购买的航班数
组合飞行值

如果我们仅获得一些此类信息，那么我们将只能知道故事的一部分，如果有的话。但是，通过存储所有这些信息，这些信息可以很好地压缩，我们可以知道解决问题所需的所有知识。日志简洁明了，但可读性强，讲述了一个故事，并遵循标准的可预测模式。还有其他表达方式，但这只是其中一种。

服务和工具选项

现在，让我们看一下伐木市场中当前的一些参与者。这些是托管的SaaS和自托管解决方案的组合。一些仍然很强壮的人已经存在了一段时间。它们包括Loggly ， Graylog ， Splunk ， ElasticSearch ， LogEntries ， Logz.io ， LogStash ， SumoLogic和Retrace等公司 。

尽管这些功能均具有搜索和分析，主动监视，创建结构化和非结构化数据，自定义解析规则以及实时仪表板等功能，但它们仍在继续建立其核心功能并扩展其产品范围和功能集。

他们的定价模式也有很大的不同，包括免费期权，标准计划起价为90美元左右，企业计划起价为2,000美元。

但是，在2017年，商业供应商并不是唯一的选择。一些开源工具也日趋成熟。事实上，两个人单挑了Linux基金会的第三次年度注意力引导到开放式云计算报告： Fluentd ，统一日志记录层的数据采集器，以及LogStash ，服务器端的数据处理管道。其他值得考虑的开源工具是syslog-ng ， LOGalyze和Apache Flume 。

有鉴于此，根据您的经验，需求和预算，今年您将不缺选择。您将有多种选择，可以从中找到最适合您需求的一种。