Lyft 运营日志：从 Splunk Cloud 迁移到 Amazon ES 再到自管型 Elasticsearch

这篇文章总结了在 Elastic{ON} 2018 上的用户发言。想了解到更多此类谈话内容？请查看会议档案，或了解 Elastic{ON} Tour 何时会在您附近的城市举办。

希望深入了解 Amazon Elasticsearch 服务和我们官方 Elasticsearch 服务之间的区别？请访问我们的 AWS Elasticsearch 对比页面。

Lyft 需要一种强大的技术基础架构来处理全球每年上亿次的乘车需求（仅 2017 年就超过 3.75 亿次），确保所有客户抵达他们的目的地。在 2017 年，这意味着要在超过 10,000 个 EC2 实例中运行 200 多个微服务；在乘车高峰期，这个数字还会增加，比如新年前夜（一天超过 200 万次乘坐）和万圣节（高峰期每分钟超过 2,000 次乘坐）。为保持这些系统和乘坐服务持续正常运行，Lyft 工程师必须能够访问所有运营日志。对于 Michael Goldsby 及其可观察性团队来说，这意味着要保持日志管道服务流畅通。

在 Lyft 的早期日志分析中，他们采用了 Splunk Cloud 作为服务提供商。但由于 Splunk Cloud 合同的保留期限制、繁忙期最多 30 分钟的备份采集限制，以及与扩展相关的成本，使得 Lyft 决定改用 Elasticsearch。

2016 年底，由两名工程师组成的团队在大约 1 个月内，就成功地将 Lyft 从 Splunk 迁移到 AWS 上的 Amazon Elasticsearch 服务。虽然切换到 Elasticsearch 很强大，但有部分 AWS 产品并不完美。一个例子是，Goldsby 团队希望升级到 Elasticsearch 5.x，但 AWS 那时只有版本 2.3。此外，新实例必须使用 Amazon EBS 进行存储，这在性能和可靠性方面，对于 Lyft 的规模都不是最佳选择。而且，并非所有 Elasticsearch API 都在 AWS 上公开。但这些 AWS 限制还不足以抵消从 Splunk Cloud 迁出所带来的好处。

随着采集限制的消除（或者至少显著增加），可观察性团队决定打开闸门，并采用一种新的理念：“将所有日志发送给我们。” 这样会使其采集速率从每分钟 10 万个事件快速增长到每分钟 150 万个事件。通过这一新方法，运营在约 4 个月内保持良好。当 Goldsby 团队遇到采集超时、保留期缩短或 Kibana 仪表板响应缓慢的问题时，他们需要做的就是扩展。当他们达到 AWS 节点限制 20 时，被特许增长到了 40 个节点。

但即使具有 40 个节点，也仍然有问题。这就是红色集群问题。

红色集群是 Goldsby 团队知道如何修复（重启、更换节点等）的问题。真正的问题是，他们无权直接访问集群，只能向 Amazon 开立票证，在高峰期间有时需要等数小时才能获得支持人员的答复。接下来，由于一线支持人员无法访问集群，因此还需要上报票证。最终 Lyft 了解到，要加速上报过程，他们可以直接联系技术客户经理 (TAM)，通过此角色来使集群恢复到绿色。

鉴于这种不可避免的支持干预、2.3 版本限制、EBS 要求和 AWS 施加的其他限制（轮循机制负载平衡、60 秒超时、API 混淆等），可观察性团队再次决定改换解决方案，这次的目标是部署自管型 Elasticsearch。“[在 AWS] 您不会获得所有功能。并非所有按钮都由您掌控。”Goldsby 说道，“我们认为，公司内部有足够的 Elasticsearch 运营经验，…[因此]能够实现自我管理。”

Lyft 建立了一个比从 Splunk 迁出时规模略大的团队，在短短两周内就从 Amazon Elasticsearch 服务迁移到了自管型 Elasticsearch。现在他们有自己的部署，以及之前 AWS 中提供的所有功能。这还意味着，他们负责 Elastic Stack 的所有运营方面，包括使集群保持绿色，以及让他们的用户（同事）开心。

通过观看 Elastic{ON} 2018 的 Lyft 野外乘坐服务从 Amazon ES 迁移到自管型 Elasticsearch 以进行运营日志分析的发言，了解 Lyft 如何实施自管型 Elasticsearch 部署。您将听到有关硬件选择、索引生命周期管理决定等的所有内容，包括为什么在服务质量方面，“记录所有内容 ≠ 记录任何内容”。