日志是系统的重要组成部分，让您了解系统是否按预期工作（或未工作）。 在微服务架构中，处理日志成为特殊奥林匹克运动会的一门独立学科。 一系列问题需要立即解决：
- 如何从应用程序写入日志；
- 日志写在哪里；
- 如何传递日志进行存储和处理；
- 如何处理和存储日志。
当前流行的集装箱化技术的使用为解决该问题提供了更多选择。
这正是尤里·布什梅列夫（Yuri Bushmelev）报告“收集和运送原木领域的耙子地图”的内容。
谁在乎，请在猫下。
我的名字是尤里·布什梅列夫。 我在 Lazada 工作。 今天我将讨论我们如何制作日志、如何收集日志以及我们在那里写什么。
我们来自哪里？ 我们是谁？ Lazada 是东南亚六个国家第一大在线零售商。 所有这些国家都分布在我们的数据中心中。 目前共有 1 个数据中心，为什么这很重要？ 因为有些决定是由于中心之间的联系非常薄弱这一事实造成的。 我们有一个微服务架构。 我惊讶地发现我们已经有 4 个微服务。 当我开始处理日志的任务时，只有 80 条日志，而且还有相当大的 PHP 遗留问题，我也必须忍受和忍受。 目前，整个系统每分钟生成超过 20 万条消息。 接下来我将展示我们如何尝试忍受这一点，以及为什么会这样。
你必须以某种方式忍受这 6 万条消息。 我们应该对它们做什么？ 您需要 6 万条消息：
- 从应用程序发送
- 接受交货
- 交付用于分析和存储。
- 分析
- 以某种方式存储它。
当三百万条消息出现时，我看起来也差不多。 因为我们一开始只有几分钱。 很明显，应用程序日志写在那里。 例如，我无法连接到数据库，我能够连接到数据库，但我无法读取任何内容。 但除此之外，我们的每个微服务还会写入访问日志。 每个到达微服务的请求都会记录在日志中。 我们为什么要这样做呢？ 开发人员希望能够追踪。 每个访问日志都包含一个 Traceid 字段，然后使用一个特殊的接口展开整个链并精美地显示跟踪。 跟踪显示了请求的进行情况，这有助于我们的开发人员快速处理任何无法识别的垃圾。
如何忍受这个？ 现在我将简要描述选项领域——这个问题一般是如何解决的。 如何解决日志的采集、传输和存储问题。
如何从应用程序编写？ 显然有不同的方法。 特别是，正如我们的时尚同志告诉我们的那样，有最佳实践。 正如我们的祖父告诉我们的那样，传统学校有两种类型。 还有其他方法。
收集日志的情况大致相同。 解决这个特定部分的选项并不多。 已经有更多了，但还没有那么多。
但随着交付和随后的分析，变化的数量开始激增。 我现在不会描述每个选项。 我认为主要选项对于每个对该主题感兴趣的人来说都是众所周知的。
我将向您展示 Lazada 是如何做到这一点的，以及这一切实际上是如何开始的。
一年前我来到Lazada，被派往一个关于日志的项目。 事情是这样的。 应用程序日志已写入 stdout 和 stderr。 一切都以时尚的方式完成。 但随后开发人员将其从标准流程中剔除，然后基础设施专家就会以某种方式解决它。 在基础设施专家和开发人员之间，也有发布者说：“呃……好吧，我们就用 shell 将它们包装在一个文件中，就这样了。” 由于所有这些都在一个容器中，因此他们将其直接包装在容器本身中，将目录映射到其中并将其放在那里。 我想每个人都很清楚它的结果。
现在让我们进一步看一下。 我们如何交付这些日志？ 有人选择了td-agent，其实是fluidd，但不是完全fluidd。 我仍然不明白这两个项目之间的关系，但它们似乎是同一件事。 这个 fluidd 用 Ruby 编写，读取日志文件，使用某种规律将它们解析为 JSON。 然后我把它们发送给卡夫卡。 此外，在 Kafka 中，我们为每个 API 有 4 个单独的主题。 为什么是4？ 因为有 live，所以有 staging，也因为有 stdout 和 stderr。 开发人员创建它们，基础设施开发人员必须在 Kafka 中创建它们。 而且，Kafka是由另一个部门控制的。 因此，有必要创建一个票证，以便他们为每个 api 创建 4 个主题。 大家都忘记了。 总的来说，有垃圾和大惊小怪。
接下来我们做了什么？ 我们把它发送给卡夫卡。 然后一半来自 Kafka 的日志飞到 Logstash。 另一半原木被分开。 有些飞向一架灰木，有些飞向另一架灰木。 结果，所有这些都进入了一个 Elasticsearch 集群。 也就是说，所有这些混乱都结束了。 不要那样做！
从上面看的话就是这个样子。 不要那样做！ 这里，问题区域立即用数字标记。 实际上还有更多，但有 6 个确实是有问题的，需要采取措施。 我现在就分别给大家介绍一下。
这里（1,2,3）我们写入文件，因此，这里同时有三个耙子。
第一个（1）是我们需要将它们写在某个地方。 赋予 API 直接写入文件的能力并不总是可取的。 最好将 API 隔离在容器中，或者最好将其设置为只读。 我是一名系统管理员，所以我对这些事情有稍微不同的看法。
第二点 (2,3) 是我们有很多请求发送到 API。 API 将大量数据写入文件。 文件正在增长。 我们需要轮换它们。 因为否则你将无法在那里储存任何磁盘。 轮换它们是不好的，因为它们是通过 shell 重定向到目录而生成的。 我们没有办法修改它。 您无法告诉应用程序重新打开句柄。 因为开发人员会像看傻子一样看着你：“什么描述符？ 我们通常写入标准输出。” 基础设施开发人员将 copytruncate 改为 logrotate，它只是复制文件并转录原始文件。 因此，在这些复制过程之间，磁盘空间通常会耗尽。
(4) 我们在不同的 API 中有不同的格式。 它们略有不同，但正则表达式必须以不同的方式编写。 由于这一切都是由 Puppet 控制的，所以有一大堆有自己蟑螂的类。 另外，大多数时候 td-agent 会消耗内存，变得愚蠢，它可以假装它正在工作而不执行任何操作。 从外人看来，不可能理解他什么也没做。 最好的情况是，他会摔倒，稍后会有人把他扶起来。 更准确地说，警报到来，有人会用手举起警报。
(6) 而垃圾和浪费最多的是elasticsearch。 因为它是旧版本。 因为我们当时没有专门的师傅。 我们有异构日志，其字段可能重叠。 来自不同应用程序的不同日志可以使用相同的字段名称写入，但里面可能有不同的数据。 即一条日志字段中带有Integer，例如level。 另一个日志在级别字段中带有字符串。 在没有静态映射的情况下，这是一件多么美妙的事情。 如果在elasticsearch中旋转索引后，带有字符串的消息首先到达，那么我们就可以正常生活。 但如果第一个消息来自 Integer，则所有后续来自 String 的消息都会被丢弃。 因为字段类型不匹配。
我们开始问这些问题。 我们决定不去追究那些罪魁祸首。
但需要做点什么！ 显而易见的是，我们需要建立标准。 我们已经有了一些标准。 我们稍后开始一些。 幸运的是，当时已经批准了适用于所有 API 的单一日志格式。 它直接写入服务之间交互的标准中。 因此，那些想要接收日志的人必须以这种格式写入日志。 如果有人不以这种格式写入日志，那么我们不提供任何保证。
接下来，我想为日志的记录、传递和收集的方法创建一个统一的标准。 实际上，在哪里写它们以及如何传递它们。 理想的情况是项目使用同一个库。 Go 有一个单独的日志库，PHP 有一个单独的库。 我们每个人都应该使用它们。 目前，我想说我们在这方面已经成功了 80%。 但有些人仍然继续吃仙人掌。
那里（在幻灯片上）几乎没有开始出现“用于日志交付的 SLA”。 它还不存在，但我们正在努力。 因为很方便的时候基础设施说，如果你用这样那样的格式写到某某地方，并且每秒不超过N条消息，那么我们很有可能会投递到某某地方。 这可以缓解很多头痛。 如果有 SLA，那就太棒了！
我们是如何开始解决问题的？ 主要问题是 td-agent。 目前尚不清楚我们的日志去了哪里。 他们交付了吗？ 他们要去吗？ 他们到底在哪里？ 因此，第一点决定替换td-agent。 我在这里简要概述了替换它的选项。
流利。 首先，我在之前的工作中遇到过他，他也时不时地摔倒在那里。 其次，这是同一件事，只是侧面而已。
文件节拍。 这对我们有什么好处？ 因为它是用 Go 语言编写的，而且我们在 Go 方面拥有很多专业知识。 因此，如果发生任何事情，我们可以以某种方式为自己添加。 这就是为什么我们没有接受它。 这样就没有任何诱惑去开始为自己重写它。
对于系统管理员来说，显而易见的解决方案是这种数量的各种系统日志（syslog-ng/rsyslog/nxlog）。
或者自己写一些东西，但我们抛弃了这个，还有 filebeat。 如果你写东西，最好是写对商业有用的东西。 交付日志，最好还是拿现成的东西。
因此，选择实际上归结为 syslog-ng 和 rsyslog 之间的选择。 我倾向于 rsyslog 只是因为我们已经在 Puppet 中提供了 rsyslog 类，并且我没有发现它们之间有明显的区别。 什么是系统日志，什么是系统日志。 是的，有些的文档更差，有些的文档更好。 这个可以这样做，另一个可以用不同的方法。
还有一些关于 rsyslog 的内容。 首先，它很酷，因为它有很多模块。 它具有人类可读的 RainerScript（一种现代配置语言）。 这是一个很棒的好处，我们可以使用标准工具模拟 td-agent 的行为，并且应用程序不会发生任何变化。 也就是说，我们将 td-agent 更改为 rsyslog，暂时保留其他所有内容。 我们立即收到工作交付。 接下来，mmnormalize 在 rsyslog 中是一个很棒的东西。 它允许您解析日志，但不能使用 Grok 和 regexp。 它创建了一个抽象语法树。 它解析日志的方式与编译器解析源代码的方式非常相似。 这使您可以非常快速地工作，消耗很少的 CPU，而且总的来说，这是一件非常酷的事情。 还有很多其他奖金。 我不会详述它们。
rsyslog 还有很多其他缺点。 它们与奖金大致相同。 主要问题是你需要知道如何烹饪它，并且需要选择版本。
我们决定将日志写入 unix 套接字。 而不是在 /dev/log 中，因为那里有一堆混乱的系统日志，journald 就在这个管道中。 因此，让我们写入自定义套接字。 我们将把它附加到一个单独的规则集中。 我们不要干涉任何事情。 一切都将变得透明且易于理解。 这正是我们所做的。 具有这些套接字的目录被标准化并转发到所有容器。 容器可以看到它们需要的套接字，打开并写入它。
为什么不是文件？ 因为大家都读过 ，它尝试转发一个文件到docker，发现重启rsyslog后，文件描述符发生了变化，docker丢失了这个文件。 它保持其他东西打开，但不保持他们正在写入的套接字。 我们决定解决这个问题，同时解决阻塞问题。
Rsyslog 执行幻灯片上指示的操作并将日志发送到中继或 Kafka。 卡夫卡遵循旧的方式。 中继 - 我尝试使用纯 rsyslog 来传递日志。 没有消息队列，使用标准 rsyslog 工具。 基本上，它有效。
但是如何将它们推入这一部分（Logstash/Graylog/ES）存在细微差别。 这部分（rsyslog-rsyslog）用于数据中心之间。 这是一个压缩的 TCP 链接，它允许我们节省带宽，并相应地以某种方式增加我们在通道堵塞时从另一个数据中心接收一些日志的可能性。 因为我们有印度尼西亚，那里一切都很糟糕。 这就是始终存在的问题所在。
我们思考如何才能真正监控我们从应用程序记录的日志到达末尾的可能性有多大？ 我们决定创建指标。 rsyslog 有自己的统计收集模块，其中包含某种计数器。 例如，它可以向您显示队列的大小，或者在这样那样的操作中到达了多少消息。 你已经可以从他们那里拿走一些东西了。 另外，它还具有可配置的自定义计数器，例如，它会向您显示某些 API 记录的消息数量。 接下来，我用 Python 编写了 rsyslog_exporter，并将其全部发送到 Prometheus 并构建了图表。 我们确实想要 Graylog 指标，但我们还没有时间设置它们。
存在哪些问题？ 当我们（突然！）我们的 Live API 每秒写入 50k 消息时，问题就出现了。 这只是没有暂存的 Live API。 Graylog 每秒仅向我们显示 12 条消息。 一个合理的问题出现了：遗骸在哪里？ 由此我们得出结论，Graylog 根本无法应对。 我们查看了一下，确实，Graylog 和 Elasticsearch 无法处理此流程。
接下来是我们一路上的其他发现。
对套接字的写入被阻止。 它是怎么发生的？ 当我使用 rsyslog 进行交付时，在某个时刻数据中心之间的通道发生了故障。 交货在一个地方停止，交货在另一个地方停止。 所有这些都已通过写入 rsyslog 套接字的 API 到达了机器。 那里有一个队列。 然后，用于写入 unix 套接字的队列（默认情况下为 128 个数据包）已满。 并且应用程序中的下一个 write() 被阻止。 当我们查看在 Go 应用程序中使用的库时，其中写道写入套接字以非阻塞模式进行。 我们确信没有任何东西被阻止。 因为我们读 谁写的。 但有一个时刻。 该调用还存在一个无限循环，其中不断尝试将消息推送到套接字中。 我们没有注意到他。 我不得不重写这个库。 从那时起它已经改变了几次，但现在我们已经摆脱了所有子系统中的阻塞。 因此，您可以停止 rsyslog，并且不会发生任何崩溃。
有必要监视队列的大小，这有助于避免踩到这个耙子。 首先，我们可以监控何时开始丢失消息。 其次，我们可以监控我们的交付是否存在问题。
还有另一个不愉快的时刻——在微服务架构中放大 10 倍是非常容易的。 我们没有很多传入请求，但由于这些消息沿着图进一步传播，由于访问日志，我们实际上将日志负载增加了大约十倍。 不幸的是，我没有时间计算确切的数字，但微服务就是这样。 必须牢记这一点。 事实证明，目前日志收集子系统是 Lazada 中负载最大的。
如何解决elasticsearch问题？ 如果您需要快速将日志收集到一个地方，以免跑遍所有机器并在那里收集日志，请使用文件存储。 这是有保证的。 它可以从任何服务器完成。 您只需将磁盘粘贴在那里并安装系统日志即可。 此后，您保证将所有日志集中在一处。 然后就可以慢慢配置elasticsearch、graylog之类的了。 但您已经拥有了所有日志，而且只要有足够的磁盘阵列，您就可以将它们存储起来。
在我撰写报告时，该计划开始看起来像这样。 我们几乎停止写入文件。 现在，我们很可能会关闭其余部分。 在运行 API 的本地计算机上，我们将停止写入文件。 首先是文件存储，效果非常好。 其次，这些机器的空间不断耗尽；需要不断地对其进行监控。
这部分与 Logstash 和 Graylog 一起，确实取得了成功。 因此，我们需要摆脱它。 你必须选择一件事。
我们决定抛弃 Logstash 和 Kibana。 因为我们有一个安全部门。 什么联系？ 连接是，没有 X-Pack 和没有 Shield 的 Kibana 不允许您区分日志的访问权限。 这就是我们选择 Graylog 的原因。 它拥有一切。 我不喜欢它，但它有效。 我们购买了新硬件，在那里安装了新的 Graylog，并将所有具有严格格式的日志传输到单独的 Graylog。 我们有组织地解决了不同类型相同字段的问题。
新的 Graylog 中到底包含哪些内容。 我们只是将所有内容写入 docker 中。 我们使用了一堆服务器，推出了 7 个 Kafka 实例、2.3 个 Graylog 服务器版本 5（因为我们想要 Elasticsearch 版本 100）。 所有这些都是在 HDD 突袭期间拾取的。 我们看到索引率高达每秒 140 万条消息。 我们看到的数字是每周 XNUMX TB 的数据。
又是耙子！ 我们即将举办两场促销活动。 我们的消息数量已超过 6 万条。 格雷洛格没有时间咀嚼。 无论如何，我们必须再次生存。
这就是我们生存的方式。 我们添加了更多服务器和 SSD。 目前我们就是这样生活的。 现在我们已经每秒处理 160k 条消息。 我们还没有达到极限，所以还不清楚我们实际上能从中得到多少。
这些是我们对未来的计划。 其中，最重要的可能是高可用性。 我们还没有。 几辆车以相同的方式配置，但到目前为止，一切都通过一辆车进行。 在它们之间设置故障转移需要时间。
从 Graylog 收集指标。
制定一个速率限制，这样我们就有一个疯狂的 API，不会耗尽我们的带宽和其他一切。
最后，与开发人员签署某种 SLA，以便我们可以提供这么多服务。 如果你写多了，那就对不起了。
并编写文档。
简而言之，我们所经历的一切的结果。 第一，标准。 其次，系统日志很简单。 第三，rsyslog 的工作方式与幻灯片上所写的完全一样。 让我们继续讨论问题。
问题.
问题：为什么你决定不采取...（filebeat？）
回答：我们需要写入文件。 我真的不想。 当您的 API 每秒写入数千条消息时，即使您每小时轮换一次，这仍然不是一个选择。 您可以在管道中写入。 开发人员问我：“如果我们正在编写的进程崩溃了，会发生什么？” 我只是不知道如何回答他们，就说：“好吧，我们不这样做了。”
问题：为什么不直接将日志写入HDFS？
回答: 这是下一阶段。 我们一开始就考虑过这个问题，但由于目前没有资源来做这件事，所以它悬在我们的长期解决方案中。
问题：列格式会更合适。
回答： 我明白。 我们用双手支持它。
问题：您正在写入 rsyslog。 在那里您可以使用 TCP 和 UDP。 但如果是UDP，那么如何保证交付呢？
回答答：有两点。 首先我先告诉大家，我们不保证日志的交付。 因为当开发人员过来说：“让我们开始在那里编写财务数据，你会为我们把它放在某个地方，以防万一发生问题，”我们回答他们，“太棒了！ 让我们开始阻止写入套接字，并在事务中执行此操作，这样就可以保证将其放入套接字上，并确保我们从另一端收到它。” 而这一刻，大家立刻就不再需要了。 如果没有必要，那么我们应该问什么问题呢？ 如果您不想保证写入套接字，那么为什么我们需要保证交付呢？ 我们正在尽最大努力。 我们确实尽力以最好的方式提供尽可能多的服务，但我们不提供 100% 的保证。 因此，没有必要在那里写入财务数据。 有一些数据库有这方面的事务。
问题：当API在日志中生成一些消息并将控制权转移给微服务时，您是否遇到过来自不同微服务的消息到达顺序错误的问题？ 这会导致混乱。
回答: 它们的顺序不同是正常的。 你需要为此做好准备。 因为任何网络配送都不能保证订单，或者你必须为此花费特殊的资源。 如果我们采用文件存储，那么每个 API 都会将日志保存到自己的文件中。 或者更确切地说，rsyslog 将它们分类到目录中。 每个API都有自己的日志，您可以去那里查看，然后可以使用该日志中的时间戳进行比较。 如果他们去 Graylog 查找，那么它们会按时间戳排序。 那里一切都会好起来的。
问题：时间戳可能会以毫秒为单位变化。
回答：时间戳由API本身生成。 事实上，这就是重点。 我们有 NTP。 API 在消息本身中生成时间戳。 rsyslog 没有添加它。
问题：数据中心之间的交互不是很清晰。 在数据中心内，日志的收集和处理方式一目了然。 数据中心之间的交互是如何进行的？ 或者每个数据中心都有自己的生活？
回答： 几乎。 在我们国家，每个国家都位于一个数据中心。 目前，我们还没有分散到一个国家/地区位于不同的数据中心。 因此，没有必要将它们组合起来。 每个中心内部都有一个日志中继器。 这是一个 Rsyslog 服务器。 实际上是两台管理机。 他们的态度是一样的。 但目前，交通只经过其中之一。 它聚合所有日志。 她有一个磁盘队列以防万一。 它下载日志并将其发送到中央数据中心（新加坡），然后再发送到 Graylog。 每个数据中心都有自己的文件存储。 如果我们的连接丢失，我们可以保存所有日志。 他们将留在那里。 它们将被存储在那里。
问题: 如果出现异常情况，你们会从那里收到日志吗？
回答：你可以去那里（到文件存储）看看。
问题：如何监控日志是否丢失？
回答：我们实际上正在失去它们，我们正在监控它。 一个月前启动了监测。 Go API 使用的库具有指标。 她可以计算出有多少次无法写入套接字。 目前有一个聪明的启发式方法。 那里有一个缓冲区。 它尝试将消息写入套接字。 如果缓冲区溢出，它就会开始丢弃它们。 他数着自己丢掉了多少个。 如果那里的水表开始溢出，我们就会知道。 他们现在也来到了prometheus，你可以在Grafana中看到图表。 您可以设置警报。 但目前尚不清楚将它们发送给谁。
问题：在elasticsearch中，您以冗余方式存储日志。 你有多少个副本？
回答： 一条线。
问题: 就只有一行吗？
回答：这是主版和副本版。 数据存储在两个副本中。
问题：您是否以某种方式调整了 rsyslog 缓冲区大小？
回答：我们将数据报写入自定义 unix 套接字。 这立即对我们施加了 128 KB 的限制。 我们不能再写更多了。 我们已将其写入标准。 那些想要进入存储的人写入 128 KB。 此外，图书馆被切断，并放置了消息被切断的标志。 我们的消息本身标准有一个特殊字段，用于显示消息在录制过程中是否被切断。 所以我们也有机会追踪这一刻。
问题：你写的 JSON 是否损坏？
回答：在中继过程中，损坏的 JSON 将被丢弃，因为数据包太大。 否则 Graylog 将被丢弃，因为它无法解析 JSON。 但有一些细微差别需要修复，而且它们大多与 rsyslog 相关。 我已经在那里填写了几个问题，但仍需要解决。
问题：为什么是卡夫卡？ 你尝试过RabbitMQ吗？ Graylog 在这样的负载下会失败吗？
回答：对于我们来说，Graylog 的效果并不好。 Graylog 正在为我们成形。 他确实有问题。 他是个奇特的东西。 事实上，这是不需要的。 我更愿意从 rsyslog 直接写入到 elasticsearch，然后查看 Kibana。 但我们需要和保安人员解决这个问题。 当我们抛弃 Graylog 并使用 Kibana 时，这是我们开发的一个可能的选择。 使用 Logstash 没有任何意义。 因为我可以用 rsyslog 做同样的事情。 它有一个用于写入elasticsearch的模块。 我们正在尝试以某种方式与 Graylog 一起生活。 我们甚至对其进行了一些调整。 但仍有改进的空间。
关于卡夫卡。 历史上就是这样发生的。 当我到达时，它已经在那里，并且日志已经被写入其中。 我们只是简单地提升集群并将日志移入其中。 我们是他的管理层，我们知道他的感受。 至于 RabbitMQ...它对我们来说用 RabbitMQ 不起作用。 RabbitMQ 正在为我们成形。 我们已经投入生产，但出现了问题。 现在，在出售之前，他们会吸引他，他就会开始正常工作。 但在此之前我还没有准备好将其投入生产。 还有一点。 Graylog可以读取AMQP 0.9版本，rsyslog可以写入AMQP 1.0版本。 中间没有一个解决方案可以同时完成这两个任务。 要么是其中之一，要么是另一个。 因此，目前只有Kafka。 但它也有自己的细微差别。 因为我们使用的 rsyslog 版本的 omkafka 可能会丢失从 rsyslog 中取出的整个消息缓冲区。 现在我们忍受了。
问题：你使用 Kafka 是因为你已经有了它吗？ 不再用于任何目的？
回答：数据科学团队使用 Kafka。 这是一个完全独立的项目，不幸的是，我对此无话可说。 我不知道。 它由数据科学团队运营。 创建日志后，我们决定使用它，而不是安装我们自己的日志。 现在我们更新了 Graylog，我们失去了兼容性，因为它有旧版本的 Kafka。 我们必须自己开始。 同时，我们为每个 API 去掉了这四个主题。 我们为所有现场制作了一个广泛的主题，为所有舞台制作了一个广泛的主题，然后将所有内容都放在那里。 Graylog 并行地把所有这些都刮掉了。
问题：为什么我们需要带有套接字的萨满教？ 您是否尝试过使用容器的 syslog 日志驱动程序？
回答：当我们问这个问题的时候，我们和docker的关系很紧张。 是 docker 1.0 或 0.9。 Docker 本身很奇怪。 其次，如果您也将日志推送到其中...我有一个未经证实的怀疑，它通过自身、通过 docker 守护进程传递所有日志。 如果一个 API 变得疯狂，那么其余 API 就会陷入无法发送 stdout 和 stderr 的困境。 我不知道这会导致什么结果。 我有一种感觉，感觉这个地方没有必要使用Docker syslog驱动程序。 我们的功能测试部门拥有自己的包含日志的 Graylog 集群。 他们使用 Docker 日志驱动程序，一切似乎都很好。 但他们立即将 GELF 写入 Graylog。 当我们开始这一切时，我们只是需要它发挥作用。 也许以后有人过来说一百年了，我们就试试。
问题：您使用 rsyslog 在数据中心之间进行传输。 为什么不在卡夫卡上呢？
回答: 事实上我们两者都做。 有两个原因。 如果通道完全死了，那么我们的所有日志，即使是压缩形式，也不会通过它爬行。 而卡夫卡让你在这个过程中简单地失去它们。 这就是我们摆脱这些日志卡住的方法。 在本例中我们直接使用 Kafka。 如果我们有一个好的通道并且想要释放它，那么我们可以使用他们的 rsyslog。 但事实上，您可以对其进行配置，使其本身丢弃不适合的内容。 目前，我们只是在某个地方直接使用 rsyslog 传递，在某个地方使用 Kafka。
来源： habr.com