Graylog日志系统规划

日志收集：

设计日志管理解决方案时，必须考虑许多因素，即使在小型组织中，现代环境也会产生大量日志数据，您将需要一种策略来对其进行有效管理。有两种主要方法：

“做有需要的人”：

决定要收集哪些事件时，“极简策略”将从“默认否”位置开始。这意味着除非确定的业务用例需要日志，否则您不会收集任何日志。该策略具有一些优势，可通过减少收集的事件数量来降低许可和存储成本。它还最大程度地减少了外部事件产生的“噪音”，使分析人员可以将精力集中在具有最大价值的事件上。最后，它提高了系统和查询效率，整体上提高了性能。

“收集所有内容，让Graylog整理出来。”：

策略是收集任何来源产生的所有事件。人们认为，所有日志数据都具有潜在的价值，特别是对于取证而言。收集并永久保存它可以保证您在需要时拥有它。但是，由于预算或其他限制，此策略通常不切实际。由于必须将更多的技术和人力资源专门用于事件数据的收集，处理和存储，因此该策略的成本可能是高昂的。还必须考虑将超大数据集保持在线状态所带来的性能损失。

您想如何处理事件数据？：

用例应在计划阶段为大多数决策提供依据。其中一些决策包括确定必须从中收集事件的来源，如何从这些来源收集事件，要存储的每种事件类型的数量，应如何丰富事件以及将数据保留多长时间。

广义上来说，用例是指达到技术和/或业务结果所必需的技术步骤。考虑问题的一种更简单的方法是，用例是对一旦收集事件日志后您想如何处理的描述。用例通常被分类为类似活动的组。一些常见的用例类别是安全性，操作和DevOps。安全用例的一个示例可能是监视用户对关键资源的登录。操作用例可能会监视网络或硬件性能，而DevOps用例将重点放在实时应用程序层监视或故障排除上。

“您需要收集哪些日志？”：

在看似一切都会生成事件日志的环境中，可能很难知道要收集什么。在大多数情况下，事件源的选择应由您确定的用例决定。例如，如果用例是监视用户对关键资源的登录，则选定的事件源应仅是所讨论的关键资源的事件源。也许是LDAP目录服务器，本地服务器，防火墙，网络设备和关键应用程序。

收集方法：

确定事件源列表之后，下一步就是确定每个事件源的收集方法。尽管许多硬件和软件产品支持诸如通过syslog发送日志数据之类的通用方法，但许多都不支持。了解每个事件源使用哪种方法以及可能需要哪些资源至关重要。例如，如果要求日志传送器从所有服务器上的本地文件中读取日志，则必须在部署之前选择并测试日志传送器。在其他情况下，必须使用和集成专有的API或软件工具。

Graylog开箱即用地支持许多输入类型：

• Syslog (TCP, UDP, AMQP, Kafka)

• GELF (TCP, UDP, AMQP, Kafka, HTTP)

• AWS (AWS Logs, FlowLogs, CloudTrail)

• Beats/Logstash

• CEF (TCP, UDP, AMQP, Kafka)

• JSON Path from HTTP API

• Netflow (UDP)

• Plain/Raw Text (TCP, UDP, AMQP, Kafka)

“谁将使用该解决方案？”：

要考虑的与用户相关的最重要因素是用户数量。如果数量很大，或者如果许多用户将同时查询数据，则在设计体系结构时可能要考虑到这一点。

应该考虑用户的技能水平。较少技术的用户可能需要更多的预建内容，例如仪表板。他们可能还需要更多培训。

还应考虑每个用户组应有权访问哪些事件源。与所有访问控制问题一样，最低特权原则也应适用。

“您将数据保留多长时间？”：

规划日志管理系统时的一个关键问题是日志保留。事件日志数据可以通过两种方式保留，联机或存档。在线数据存储在Elasticsearch中，并且可以通过Graylog GUI搜索。存档的数据以压缩格式存储在Graylog服务器或网络文件共享上。例如，仍然可以通过GREP进行搜索，但是必须在Graylog中对其进行重构，以便再次通过GUI进行搜索。

一些法规框架要求将事件日志数据保留规定的时间。在没有明确要求的情况下，问题就变成了在保留（存储）成本与拥有历史数据的实用性之间取得平衡的问题。没有一个答案，因为每种情况都不同。

大多数Graylog客户保留30-90天在线（可在Elasticsearch中搜索）和6-13个月的存档。

计算存储需求：

与大多数数据存储区一样，Elasticsearch在消耗所有可用存储区时也会做出不良反应。为了防止这种情况发生，必须执行适当的计划和监视。

许多变量会影响存储要求，例如保留每个消息的数量，解析完成后是否保留原始消息以及在存储之前进行了多少充实。

规划存储的简单经验法则是，将您的平均每日摄取率乘以您需要在线保留数据的天数，然后将该数字乘以1.3以解决元数据开销。（GB /天x保留天数x 1.3 =存储要求）。

Elasticsearch在操作过程中大量使用了松弛的存储空间。强烈建议用户超出其计算的摄入率所需的最小存储量。在最大保留时，Elasticsearch存储不应超过总空间的75％。