作为CockroachCloud团队的一名SRE，我们面临着独特的挑战，即监控和管理全球各地的CockroachDB集群。也许不用说，作为一个分布式数据库，安全对我们来说是最重要的。为了解决一些与安全和监控有关的需求（例如入侵检测审计记录），我们已经投资了下一代安全信息和事件管理（SIEM）基础设施。
在这篇文章中，我们将介绍我们如何为我们的SIEM需求汇总日志，以及同一系统如何帮助CockroachCloud团队的所有成员提高观察能力。
首先是一些背景。CockroachCloud将CockroachDB集群托管在两个云中。AWS和GCP。每个Cockroach集群都是由许多跨越一个或多个Kubernetes集群运行的pod组成的，一个Cockroach集群的所有Kubernetes集群都在一个云账户中。
在我们的集中日志项目之前，每个Cockroach集群的日志都是通过一系列的shell脚本和云供应商工具来拉动的。这些方法对于我们当时的规模来说是非常有效的，但是随着CockroachDB的使用量快速增长，我们知道这些方法是无法扩展的。
问题的范围：我们如何建立集中式的日志记录？
我们安全基础设施发展的一个主要瓶颈是没有把所有的日志放在一个地方。因此，我们专注于将所有的日志运送到一个中央安全地点进行分析的解决方案。关于我们的解决方案应该是什么样子的，我们做了大量的研究，首先是找出我们正在处理的数据量。这包括检查CockroachDB集群的平均工作负荷所产生的日志量，然后推断出目前的舰队规模。考虑到我们的增长速度，我们为未来的集群做了近似值，并做了大量的填充。一旦我们有了估计，我们就开始采购。
我们的主要选择是ELK（Elasticsearch、Logstash和Kibana）、Splunk或内部构建的东西。为更大的数据量进行规划有助于我们与供应商进行谈判，因为我们能够利用价格折扣。虽然最终，我们想设计成低维护。
一位智者曾经说过。
首先购买它，然后建造它，然后忘记它。
意思是说，在建造一个产品时，首先尝试购买你需要的东西来销售产品，然后再尝试建造它。而如果这两种选择都是可能的，你应该忘记它。
这句话源于这样一个事实：向市场交付产品所需的大部分东西都不在你的掌控之中。你花在维护该软件上的时间越多，你可以花在自己的竞争优势上的时间就越少。而维护产品所需的时间总是比预期的多。这些不那么隐蔽，但经常被遗忘的成本，可以迅速吞噬利润。因此，我们关注的是云计算产品，而不是需要我们自己托管和运行软件的企业产品。
这里面还有一个人的因素。人们想要什么？尽管我很想建立一个伟大的产品，但我不相信有一个单一的方法来实现这个目标。大多数情况下，有很多好的选择摆在你面前，有不同的权衡。这也是人类仍然有工作的原因之一。如果有一个明确的答案，我们就会把它自动化。
精简后的需求清单
-
技术要求
- 必须是安全的，符合我们的需求（例如，加密，SOC2等）。
- 必须能扩展到数万个集群。我们才刚刚起步，所以我们不可能已经把服务的能力发挥到极致。
- 必须能够在几个月内由一个开发人员执行（为我们的免费层推出做准备）。
- 如果将成本分摊到几年的使用中，必须比内部建造的东西更便宜。
-
可用性要求
- 我们的团队必须至少有一点兴奋。如果人们对学习和使用该产品不感到兴奋，那么几乎可以保证它的潜力不会被完全发挥出来。
- 人们能够迅速掌握它吗？它不能太棘手或有太多的旋钮来使它有效地工作。我们都有能力。我们都可以学习复杂的工具。但我们也都有更好的事情要做。
Elasticsearch是一个伟大的工具，我们在个人和专业项目中都很喜欢使用它。然而，最后我们还是选择了Splunk。
经过我们的测试和成本分析，从长远来看，Elasticsearch会让我们花费更多，增加的成本主要是由于Elasticsearch的运营和维护需求，而不是许可费。另外，Splunk的安全团队内部也有一股强大的动力，我们知道这将有助于顺利完成项目的进程。鉴于这是一个以安全为目的的项目，我们需要确认SplunkCloud能够给我们带来实现安全目标所需的灵活性。一旦确认了这一点，我的目光就锁定在Splunk上了。现在是建立的时候了。
我们如何建立集中式日志
目前，每个CockroachDB集群都生活在一个或多个地区的云端（AWS或GCP）。有两个主要的日志来源，都需要被运送到Splunk和数据湖（即谷歌云存储，S3）。这两个来源是。
- 在Kubernetes中运行的容器产生的应用日志。
- 云提供商的日志（例如，VPC流量日志，云审计日志，等等）。
向Splunk发送应用日志是相对容易的。只需在每个Kubernetes集群中添加一个额外的DaemonSet，我们就可以将CockroachDB和朋友们产生的日志运送到Splunk的HTTP事件收集器（HEC），这实际上是一个摄取端点。运送云供应商的日志则要复杂得多。
我们遇到的一个障碍是与旧版本的CockroachDB的兼容性，它没有通过TCP发送日志的选项。相反，日志是以几个文件的形式写到磁盘上的。为了解决这个兼容性问题，我们决定将FluentBit的第二个实例作为CockroachDB进程的一个边车运行。这个边车将负责从CockroachDB进程产生的文件中读取日志，并将它们转发给FluentBit DaemonSet。DaemonSet将负责将日志传送到Splunk。值得庆幸的是，新版本的CockroachDB支持通过TCP进行日志记录，我们可以逐步淘汰sidecar模式。
向Splunk发送应用日志最棘手的部分是更新我们的棕地（或先前存在的）集群。要告诉kubernetes用多一个容器来启动一个新的StatefulSet是很容易的。要告诉数百个kubernetes集群编辑当前运行的StatefulSets以包括一个新的容器，并且不产生停机时间，这又是几周的工作。也许另一篇博文就是为了这个话题而写的!
第二步：将云提供商的日志从云提供商运送到Splunk
对于两个云提供商（AWS和GCP），我们想运送VPC流量日志、云审计日志和kubernetes基础设施日志等日志。由于我们使用Pulumi来管理我们的基础设施，我们需要创建两个独立的云资源堆栈；每个云都有一个。
步骤2a:将日志从AWS运送到Splunk
日志从AWS到Splunk的一般流程是通过将日志从源头（VPC的VPC流量日志）发送到CloudWatch日志组。日志组作为一个Pub/Sub主题，一个订阅将这些日志转发到Kinesis Firehose流。Kinesis Firehose Stream负责用lambda函数转换日志行（考虑到Splunk摄取器所期望的日志格式，这是必要的）。然后Kineses将日志运送到Splunk和S3进行长期存储。
读者可能会问为什么我们创建了三个kinesis流而不是一个。每个流都有自己的转换功能，考虑到日志类型的多样性，这似乎是最可维护的解决方案。另外，考虑到所有的资源都是通过代码来管理的，一旦一个流工作正常，我们就能迅速创建第二个和第三个流。
第2b步：将日志从GCP运送到Splunk
GCP的日志工作方式与AWS类似。日志首先由所有来源（如VPC流量日志）发送到云日志。然后，云日志汇过滤主要的云日志流，并将过滤后的日志转储到一个特定的位置（例如，Pub/Sub主题，谷歌云存储）。对于那些发送到Pub/Sub主题的日志，一个云功能负责转换日志并将其转发到Splunk。
其结果是：将数以千计的日志运送到长期的、可搜索的存储器中
有了这两个解决方案，我们现在可以将成千上万的CockroachDB集群的日志运送到长期的、可搜索的存储中。虽然我们还在向所有集群推广这些变化，但我们计划的数字如下。
- 每天向SplunkCloud发送300多GB的数据
- 每天向SplunkCloud发送5000万以上的事件
- 每个月的工程师维护时间少于8小时
- 能够在几秒钟内查询整个机群（所有集群）的日志（之前是几个小时）。
最重要的是，我们现在可以对来自每个云提供商的无数新事件类型发出警报。这些事件包括AWS API认证尝试、基础设施变化和权限升级。通过对特定的认证尝试配置文件和网络流量发出警报，我们的安全团队可以持有一个呼叫器（而不是搜刮日志），产生可操作的警报。
虽然有许多路径可以证明足以满足我们的需求，但选择这条路径是因为其简单性、可维护性和可扩展性。对这个项目来说，最重要的是，有了Splunk，我们的安全团队可以更快、更有效地运作。我很高兴地说，我们为客户提供可扩展和安全的分布式SQL数据库的能力正在不断提高。
