洛克希德·马丁的企业运营选择 OTel 以实现更好的可观测性
挑战
洛克希德·马丁的企业运营位于马里兰州贝塞斯达，为全球约 114,000 名员工提供业务服务和信息技术支持。作为一家受严格监管的安全和航空航天公司，企业运营团队需要将安全日志和审计日志与主系统分开存储。然而，现有的解决方案无法扩展以支持他们的 Kubernetes 集群规模。
解决方案
洛克希德·马丁决定在 OTel 仍处于 alpha 版本时进行尝试，迅速获得了集群及其上运行的所有应用的审计日志、安全日志和性能指标。数据没有丢失，一切都可见。
影响
OTel 使洛克希德·马丁能够实现以前无法做到的事情：对所有环境的可见性，并根据需要进行扩展。团队负责维护和操作大约 70 个 Kubernetes 集群，现在他们能够对所有集群进行深入了解。无需登录到集群中查看问题，尽管运行着不同版本的 Kubernetes，他们也拥有统一的数据。由于集群在多个云平台和本地运行，从每个集群获取一致的数据至关重要。
在几分钟内获取 Otel 指标（确实如此）
三年前，洛克希德·马丁的企业运营团队意识到必须有所改变。为了将安全和审计日志与主系统分开，他们需要可扩展性，但当时所有选项要么无法扩展，要么不符合云原生最佳实践，洛克希德·马丁全栈工程师 James Sevener 解释道。
“当时的 OpenShift 日志项目——自那以后有了迭代——无法扩展到我们集群的规模，”Sevener 说道。“它的事件处理能力大约在每秒 3000 个事件时开始丢失数据。我们需要所有 pod 的数据，但只从部分 pod 或节点收集数据。当时的所有解决方案都无法扩展到我们的集群规模。”
OpenTelemetry 刚刚推出 alpha 版本，团队访问了 GitHub 仓库，进行了部署和配置，但并未成功。Sevener 和团队没有接收到任何数据，于是联系了他们的 Splunk 客户代表，后者将他们与 OTel 项目的开发者联系起来。后来发现，洛克希德·马丁使用的是错误的仓库——一个不该公开的测试仓库。
“在通话的 5 分钟内，我们成功切换到当前版本并完成配置，”Sevener 表示。“由于基础安装只需少量选项，我们从一个测试集群中获得了日志和指标。我们在几分钟内就实现了数据流动。这真是太惊人了。默认收集器所需的选项不多，它就能正常工作。就是这样。”
之后，一切都很顺利。团队深入挖掘，增加了一些自定义需求，比如限制某些命名空间的日志。这一过程相当简单，仅需在部署中进行小改动。然后，洛克希德·马丁开始部署其他发行版本的 Kubernetes。
“现在我们在三种不同的 Kubernetes 发行版本上基本使用相同的部署，”他说。
将遥测数据发送到两个不同平台
洛克希德·马丁的起点是将所有安全和审计日志数据发送到 Splunk，包括虚拟机和 Windows 服务器，以及所有 Kubernetes 集群的指标。但组织内的另一个团队希望在 Dynatrace 中查看这些数据。Dynatrace 在 Kubernetes 上部署了自己的代理，也有自己的 OTel 收集器，因此团队扩展了 Splunk OTel 以包含 Dynatrace 导出器。
“我们做到了，并且有效，”Sevener 说。“从同一个收集器将数据发送到两个完全不同的平台非常不错，因为我们的环境中有合规性软件堆积。对每个目标使用多个代理，导致我们集群资源的一半用于合规任务，如日志记录，这真让人遗憾。”
点击【阅读原文】阅读网站原文。
CNCF概况（幻灯片）
扫描二维码联系我们！
CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。请关注CNCF微信公众号。
