eBay 使用 Beats 每天监测 PB 量级的日志

eBay 每天会产生 1.2 PB 的日志，每秒会收到来自 500 万个指标数据点的数据，所以说 eBay 需要跟踪的数据量十分惊人。每天，这家电子商务公司的日志和监测团队都需要完成所有这些日志和指标的采集和可视化工作，工作量特别大。而且，与大部分公司一样，eBay 也通过各种应用程序（例如 Hadoop 和 MySQL）来驱动各个团队的不同用例。

当业内出现使用容器来作为部署应用程序的新方法时，团队开始使用 Docker 进行容器化并通过 Kubernetes 进行部署，在这一过程中会使用 Kubernetes 管理生命周期。然而，他们遇到的最大难题之一便是应用和环境一直在不断发展，很难跟上发展步伐。Beats 出现啦！很显然，Filebeat 和 Metricbeat 是从 Docker 和 Kubernetes 收集和传输日志和指标的最佳选择。

他们还希望在创建工作负载的同时便能够发现这些工作负载。在 Beats 中推出 autodiscover 功能（6.2 中的新推功能）之前，他们自行开发了一款产品：Collectbeat。他们的 Beat 在 libbeat 的基础上开发而成，能够发现 Kubernetes 集群中的新 Pod。Collectbeat 会使用 Kubernetes API 来发现工作负载、收集并丰富数据，然后将数据发送到团队的内部监测系统。此系统名为 Sherlock.io，十分灵活，在采用新技术时能够自行适应。

尽管数据收集环节现已解决，但是仍然需要关注分析和可视化部分。除非 eBay 用户能够使用熟悉的标签对数据进行分析，否则收集所有这些数据便没有任何意义。下一个合情合理的步骤是确定一种方法来在传输数据之前使用元数据为数据添加标签。所以 Vijay Samuel 和他在 eBay 的团队共同开发了一个名为 “add_kubernetes_metadata” 的处理器，该处理器能够处理日志消息和指标负载，并添加诸如名称和 Pod 空间等元数据。此处理器现已在 GitHub 上推出。此工具的问世很好地阐释了为何社区驱动的开源项目具有如此强大的功能。

当然喽，eBay 还在继续发展。随着新技术的采用，也产生了更多的应用程序、日志和指标。实际上，他们的有机日志年增长率高达 50%。 那么，在资源有限的前提下，他们是如何处理日益增长的数据量的呢？策略之一便是通过创建基于级别的配额和保留限值来在主机/池层面测量应用程序。另一策略是优先处理特定类型的数据。事件的优先级最高，可显示运行可见性的指标次之，然后才是日志。为了确保优先级正确无误，他们添加了事件调度程序，并允许 autodiscover 向配置中添加权重。

十分迫切地希望深入了解他们团队的工具和战略吗？请观看 Elastic{ON} 2018 大会上 Vijay 所作的演示，详细了解 Sherlock.io 的信息，以及他们如何使用 Beats 监测 Kubernetes 集群中的全部数据。如果您希望深入了解如何使用 Elastic Stack 来监测 Kubernetes 和 Docker，请查看我们的 Elastic Stack：使用 Beats 监测 Kubernetes 应用程序网络研讨会。