存储服务提供商 Box 已发展成为非常具有品牌影响力的云端内容管理平台，帮助企业提高员工和客户的工作效率，同时还能保护客户最宝贵的数据：他们的文件和任务关键型工作流程。
当前云端内容管理领域竞争异常激烈，Box 必须持续不断地提高检测、识别并解决问题的速度，这一点至关重要。这是因为 Box 早已融入到其数百万客户的业务关键型工作流程中，必须在稳定性、性能和合规方面满足严苛的 SLA 要求。
Box 向客户承诺的 SLA 非常严格，对正确性要求十分之高。所有这些都意味着，Box 需要一个清晰的可观测性窗口来了解自身基础架构，以支持来自数百万用户的海量用例，这还不包括 Box 的逾 95,000 家企业客户。
“我们的客户和用户不仅将内容交给 Box，还将他们的业务关键型工作负载交给我们。所以，如果 Box 出现故障，这对他们绝对是一个巨大的收入损失。”Box 可观察性团队的工程经理 Deepak Wadhwani 说道。
Box 网站上列出了很多声名显赫的客户，例如 Allstate、阿斯利康、可口可乐、摩根士丹利、Oxfam、奥林巴斯、Pandora，以及很多人们不太熟悉的其他公司。
最近几年，Box 的工程团队越来越担心他们旧有的报告后端扩展性能不佳。随着 Box 的路线图越来越宏大，可观察性团队希望针对应用程序和运行日志，采用一种比 Splunk 更加可靠、更具成本效益的解决方案。
这些都是极其重要的任务关键型流程，考虑到 Box 正在逐步将大型整体基础架构转化为数百项微服务以实现增长、促进创新并打造面向客户的新功能，其重要性更加得以凸显。
由于 Box 旧有的日志解决方案是基于所采集的数据量计费，所以有时 Box 不得不削减日志项目以节约成本，或者 Box 工程师会决定不采集新部署微服务的事件日志。
当时情况就是这样，这与 Box 快速转型为领先云端内容管理平台的企业使命相违背。这一转型要求Box 将其大型整体基础架构分解为微服务，而要实现这一目标，他们需要更多的全面日志，而不是削减日志量。
不仅如此，Box 还使用 MySQL 完成企业报告，这一方法自身也存在问题。问题之一就是不能处理使用情况日志数据（例如打开文件的时间，将文件移到其他文件夹的时间，甚至分享文件的时间）以服务于大型企业，因为产生的事件数量过于庞大。
所以自 2015 年始，在从价格、可扩展性、支持以及安全性等方面对竞争格局进行调查之后，Box 最终选择了 Elastic。
通过部署 Elastic Stack，Box 采取了一种着眼于未来、可扩展的可观察性方法，其定价模式植根于所管理的内存量，而非所采集的数据量。改用 Elastic 的这一举措一方面强化了 Box 的报告能力并大幅降低了成本，同时还能从 Box 的微系统中采集日志以了解性能和行为。而且，这些日志瞬间便可获得。
报告用例开启了 Box 使用 Elastic 的历程。由于在报告用例中从 MySQL 改用 Elastic 取得了巨大成功，这赢得了 Box 对 Elastic 的信心和信任。这在很大程度上推动了 Box 开始在日志解决方案中改用 Elastic，每次专注于一项微服务。
尽管如此，新的报告和日志系统也必须赢得工程师的拥戴，否则仍可能会遭遇失败或进展缓慢。Box 选择 Elastic Stack 后，工程师在运行大型报告以及针对既有或新的微服务进行日志编程时，干劲比以前更足了，这进一步推动了 Box 取得更为巨大的成功。
Box 刚开始使用 Elastic 时，仅有几 TB 的存储量，而且存储团队中仅有几名开发人员负责开发和部署 Box 的崭新报告功能，当然 Elastic 现场顾问和 Elastic 培训课程也起到了很大帮助作用。今天，来自 Box 很多团队的大约 500 名工程师都在使用 Elastic Stack 完成报告和日志用例，而且每天都会使用数以百计的 Kibana 仪表板来对 TB 量级的数据进行可视化。
我们已经知道，Box 最初使用 Elastic 的目的将企业日志迁移至 Elasticsearch 以实现报告用例，并将 Elasticsearch 作为数据分析的后端。这一数据管道之后会进一步发展，从而支持 Box 公司由 Elastic 提供支持的崭新日志环境。
对于报告项目，公司充分利用了基础安全功能，例如基于角色的访问控制以及用户身份验证。这些功能以及其他功能，例如能够确定何人在何时何地访问了哪个 Box 文件，使得 Box 能够满足安全和隐私方面的合规性责任。
Elasticsearch 报告项目（公司内部称为“Newsroom”）启动伊始，便解决了围绕以下两方面的难题：筛选问题，以及企业日志与业务分析存在不一致。Box 在制作报告时再也没有遇到问题，所以能够满足客户的 SLA。问题举例：对大型企业而言，有时报告会完全不能加载；对中型企业而言，制作报告则耗时太长。
其他修复措施包括：
Box 之前的日志解决方案按照采集的数据量计费，公司当时的数据采集量是每天 7 TB。现在公司每天采集的数据量已增长至每天 20 TB，预计未来还会进一步增长。所以为了节省成本，对于在公司日益增长的微服务平台上的何处实施可观察性功能，Box 必须精心选择，然而改用 Elastic 后，这个难题迎刃而解了。
成本并不是唯一考虑因素。使用之前的日志平台时，索引工具有时候会出现故障。延迟也是一个问题，而且告警功能不太可靠。
由于存在这些问题，而且随着每天日志的数据量呈爆炸式增长，公司于 2017 年对日志基础设施进行了重新设计。
Box 通过一个管道（内部代码为 Almost-Real-Time-Analytics（近实时分析），又称“Arta”）将保留型、临时型和交互型日志分离开来，借助这种三叉式方法不断地将所有运行和应用程序日志安全地迁移至 Elasticsearch。
Box 表示，公司需要开发可保证实现 SLA 的高性能企业级系统并对其加以维护，这一点至关重要。所以 Box 的工程师必须深入了解系统以及这些系统所产生的日志。Ahmed 表示 Elastic 为 Box 的可观察性团队提供了一套日志系统，让他们能够以很低的索引开销完成复杂查询；而且即使 Box 规模越来越大，费用也一直十分合理。
通过这一由 Elastic 驱动的可观察性窗口，以及用来对数据进行可视化的数百个 Kibana 仪表板，Box 的工程师轻松便可收获洞察。他们可以看到客户打开 Box 文件时是否遇到了问题，是否向文件中添加了协作者，是否向文件夹中添加了文件，不胜枚举。日志同时也可帮助工程师快速解决问题（例如客户文件上传延时），让他们满足在正常运行时间方面的 SLA 要求。
此外，为了确保 Box 客户持续获得卓越的用户体验，日志是 Box 编码工作的核心，因为只有这样才能确保成功提交代码变更，Box 工程部门的高级总监 Dave Ward 表示。
“当变更代码来添加新功能或进行修复时，我所做的变更是否达到了预期结果？” Ward 问道，“推送代码时，我有没有看到错误？如果可观察性管道不能如期运行，我们则无法确保自身系统的健全。Arta 依赖于 Elasticsearch，在我们保持自身敏捷性并维持较高发布频率的过程中，Arta 发挥着至关重要的作用。”
今天，Box 正在逐步通过 Arta 来运行其大量以开发人员为核心的生产级日志流。公司在持续开发微服务的过程中不断添加新的和既有的日志流，Box 团队目前正在研究如何在稳定性、弹性和运行效率方面实现更大改善，并进一步降低成本。
说到未来，Box 正在考虑将更多的跟踪指标集中到由 Elastic 提供支持的单一平台中。Box 还在积极与 Elastic 工程师开展合作，逐步完善产品并分享产品反馈。
公司还对其他 Elastic 功能感兴趣，例如针对应用程序性能监测的 Elastic APM，可帮助检测问题并提供告警的 Machine Learning，以及 Elastic 的 geoIP 映射功能，这样 Box 便能从 IP 地址开始着手，对查询的来源地在 Kibana 中进行可视化。
Box 还正在探索使用 Elastic SIEM 来推动安全运行工作，而且还使用 Canvas 让 Kibana 中的仪表板更加美观，此外还在对很多其他 Elastic 功能进行调研。
在财务方面，通过采用 Elastic，Box 在数据负载方面的价格削减了一半。此外，使用 MySQL 时存在的报告问题和难题也得以解决。而且，之前的日志解决方案由于采用读时索引，部分程度上造成了延时，由于 Elastic 为写时索引，所以延时问题已经不复存在。
“费九牛二虎之力获得数据，还是不费吹灰之力获得数据。” Wadhwani 如此解释延时方面的巨大差异。“使用 Elasticsearch 后，在 Kibana 中进行查询的速度快多啦，”Wadhwani 说道。
至于较难量化层面上的 ROI，Box 正在积极鼓励工程师产生合适数量的日志以实现构建企业级产品必备的可观察性级别。
这些以及其他细微变更都正在帮助 Box 满足内部和外部的 SLA 协议，同时 Box 还鼓励开发人员随着 Box 规模的扩大不断进行创新。
