不管我们使用何种编程语言，都不可避免的面临如何处理错误日志的问题。许多程序员对错误日志放任不管，直到出现BUG故障了才手忙脚乱。其实bug总是免不了会存在的，有些bug不是每次都会出现，测试时运行好好的代码可能在某个用户使用时就歇菜了，可是当程序在用户面前崩溃时，你是看不到错误的，当然你会说:“Hey,我有记日志呢？”如果问小编怎么办，我会给你推荐无论测试如何完善的程序
日志聚合软件可以帮助我们进行故障排除和其它任务。以下是三个主要工具介绍。
指标聚合metrics aggregation与日志聚合log aggregation有何不同？日志不能包括指标吗？日志聚合系统不能做与指标聚合系统相同的事情吗？
这些是我经常听到的问题。我还看到供应商推销他们的日志聚合系统作为所有可观察问题的解决方案。日志聚合是一个有价值的工具，但它通常对时间序列数据的支持不够好。
时间序列的指标聚合系统中几个有价值的功能是专门为时间序列数据定制的固定间隔regular interval和存储系统。固定间隔允许用户不断地收集实时的数据结果。如果要求日志聚合系统以固定间隔收集指标数据，它也可以。但是，它的存储系统没有针对指标聚合系统中典型的查询类型进行优化。使用日志聚合工具中的存储系统处理这些查询将花费更多的资源和时间。
所以，我们知道日志聚合系统可能不适合时间序列数据，但是它有什么好处呢？日志聚合系统是收集事件数据的好地方。这些无规律的活动是非常重要的。最好的例子为 web 服务的访问日志，这些很重要，因为我们想知道什么正在访问我们的系统，什么时候访问的。另一个例子是应用程序错误记录 —— 因为它不是正常的操作记录，所以在故障排除过程中可能很有价值的。
日志记录的一些规则：
须包含时间戳
须格式化为 JSON
不记录无关紧要的事件
须记录所有应用程序的错误
可记录警告错误
可开关的日志记录
须以可读的形式记录信息
不在生产环境中记录信息
不记录任何无法阅读或反馈的内容
云存储的成本
当研究日志聚合工具时，云服务可能看起来是一个有吸引力的选择。然而，这可能会带来巨大的成本。当跨数百或数千台主机和应用程序聚合时，日志数据是大量的。在基于云的系统中，数据的接收、存储和检索是昂贵的。
以一个真实的系统来参考，大约 500 个节点和几百个应用程序的集合每天产生 200GB 的日志数据。这个系统可能还有改进的空间，但是在许多 SaaS 产品中，即使将它减少一半，每月也要花费将近 10000 美元。而这通常仅保留 30 天，如果你想查看一年一年的趋势数据，就不可能了。
并不是要不使用这些基于云的系统，尤其是对于较小的组织它们可能非常有价值的。这里的目的是指出可能会有很大的成本，当这些成本很高时，就可能令人非常的沮丧。本文的其余部分将集中讨论自托管的开源和商业解决方案。
三种工具选择
1.ELK
ELK，即 Elasticsearch、Logstash 和 Kibana 简称，是最流行的开源日志聚合工具。它被 Netflix、Facebook、微软、LinkedIn 和思科使用。这三个组件都是由 Elastic 开发和维护的。Elasticsearch 本质上是一个 NoSQL 数据库，以 Lucene 搜索引擎实现的。Logstash 是一个日志管道系统，可以接收数据，转换数据，并将其加载到像 Elasticsearch 这样的应用中。Kibana 是 Elasticsearch 之上的可视化层。
几年前，引入了 Beats 。Beats 是数据采集器。它们简化了将数据运送到 Logstash 的过程。用户不需要了解每种日志的正确语法，而是可以安装一个 Beats 来正确导出 NGINX 日志或 Envoy 代理日志，以便在 Elasticsearch 中有效地使用它们。
安装生产环境级 ELK 套件时，可能会包括其他几个部分，如 Kafka、Redis 和 NGINX。此外，用 Fluentd 替换 Logstash 也很常见，我们将在后面讨论。这个系统操作起来很复杂，这在早期导致了很多问题和抱怨。目前，这些问题基本上已经被修复，不过它仍然是一个复杂的系统，如果你使用少部分的功能，建议不要使用它了。
也就是说，有其它可用的服务，所以你不必苦恼于此。可以使用 Logz.io，但是如果你有很多数据，它的标价有点高。当然，你可能规模比较小，没有很多数据。如果你买不起 Logz.io，你可以看看 AWS Elasticsearch Service (ES) 。ES 是 Amazon Web Services (AWS) 提供的一项服务，它很容易就可以让 Elasticsearch 马上工作起来。它还拥有使用 Lambda 和 S3 将所有AWS 日志记录到 ES 的工具。这是一个更便宜的选择，但是需要一些管理操作，并有一些功能限制。
ELK 套件的母公司 Elastic 提供 一款更强大的产品，它使用开源核心open core模式，为分析工具和报告提供了额外的选项。它也可以在谷歌云平台或 AWS 上托管。由于这种工具和托管平台的组合提供了比大多数 SaaS 选项更加便宜，这也许是最好的选择，并且很有用。该系统可以有效地取代或提供 安全信息和事件管理（SIEM）系统的功能。
ELK 套件通过 Kibana 提供了很好的可视化工具，但是它缺少警报功能。Elastic 在付费的 X-Pack 插件中提供了警报功能，但是在开源系统没有内置任何功能。Yelp 已经开发了一种解决这个问题的方法，ElastAlert，不过还有其他方式。这个额外的软件相当健壮，但是它增加了已经复杂的系统的复杂性。
2.Graylog
Graylog 最近越来越受欢迎，但它是在 2010 年由 Lennart Koopmann 创建并开发的。两年后，一家公司以同样的名字诞生了。尽管它的使用者越来越多，但仍然远远落后于 ELK 套件。这也意味着它具有较少的社区开发特征，但是它可以使用与 ELK 套件相同的 Beats 。由于 Graylog Collector Sidecar 使用 Go 编写，所以 Graylog 在 Go 社区赢得了赞誉。
Graylog 使用 Elasticsearch、MongoDB 和底层的 Graylog Server 。这使得它像 ELK 套件一样复杂，也许还要复杂一些。然而，Graylog 附带了内置于开源版本中的报警功能，以及其他一些值得注意的功能，如流、消息重写和地理定位。
流功能可以允许数据在被处理时被实时路由到特定的 Stream。使用此功能，用户可以在单个 Stream 中看到所有数据库错误，在另外的 Stream 中看到 web 服务器错误。当添加新项目或超过阈值时，甚至可以基于这些 Stream 提供警报。延迟可能是日志聚合系统中最大的问题之一，Stream 消除了 Graylog 中的这一问题。一旦日志进入，它就可以通过 Stream 路由到其他系统，而无需完全处理好。
消息重写功能使用开源规则引擎 Drools 。允许根据用户定义的规则文件评估所有传入的消息，从而可以删除消息（称为黑名单）、添加或删除字段或修改消息。
Graylog 最酷的功能或许是它的地理定位功能，它支持在地图上绘制 IP 地址。这是一个相当常见的功能，在 Kibana 也可以这样使用，但是它增加了很多价值 —— 特别是如果你想将它用作 SIEM 系统。地理定位功能在系统的开源版本中提供。
如果你需要的话，Graylog 公司会提供对开源版本的收费支持。它还为其企业版提供了一个开源核心模式，提供存档、审计日志记录和其他支持。其它提供支持或托管服务的不太多，如果你不需要 Graylog 公司的，你可以托管。
3.Fluentd
Fluentd 是 Treasure Data 开发的，CNCF 已经将它作为一个孵化项目。它是用 C 和 Ruby 编写的，并被 AWS 和 Google Cloud 所推荐。Fluentd 已经成为许多系统中 logstach 的常用替代品。它可以作为一个本地聚合器，收集所有节点日志并将其发送到中央存储系统。它不是日志聚合系统。
它使用一个强大的插件系统，提供不同数据源和数据输出的快速和简单的集成功能。因为有超过 500 个插件可用，所以你的大多数用例都应该包括在内。如果没有，这听起来是一个为开源社区做出贡献的机会。
Fluentd 由于占用内存少（只有几十兆字节）和高吞吐量特性，是 Kubernetes 环境中的常见选择。在像 Kubernetes 这样的环境中，每个 pod 都有一个 Fluentd 附属件 ，内存消耗会随着每个新 pod 的创建而线性增加。在这种情况下，使用 Fluentd 将大大降低你的系统利用率。这对于 Java 开发的工具来说是一个常见的问题，这些工具旨在为每个节点运行一个工具，而内存开销并不是主要问题。
小结：
说实话，如果是一台服务器，其实产生的日志我们处理起来并不复杂，但如果程序每天每时都在产生太大量的日志，而且分布在各个服务器上，并且如果你又有多个服务在维护的话，日志的数量之多你是看不过来的吧。等到某天某个用户实在受不了了，打电话来咆哮的时候，你再去找日志你又会发现日志其实没什么用：缺少上下文，不知道用户什么操作导致的异常，异常太多（从不看日志的缘故），那么以上三个日志聚合软件还是能够帮到不少的忙。