关于 Gurunavi, Inc.
自 1996 年 6 月建立餐厅信息网站 Gurunavi 以来，Gurunavi Inc. 一直经营着侧重于提供餐厅信息和其他类似服务的各种业务。作为这一行业历史悠久的老牌领导者，Gurunavi 提供的信息覆盖约 500,000 家餐厅，拥有 58,951 家付费会员餐厅1、6,100 万月度独立用户2 和 1,796 万个会员3。除此之外，它还为餐厅提供端到端的支持服务，如信息通信技术 (ICT) 支持，从而为餐厅食客和餐厅本身带来附加价值。从 2018 年起，Gurunavi 开始提供新颖的服务来吸引客户，包括使用社交媒体、将会员 ID 与乐天 ID 关联，以及在餐厅推出无现金支付的 Gurunavi Pay 服务。
对普通用户来说，最广为人知的要属 Gurunavi 的餐厅信息，毕竟通过智能手机或电脑即可查看，但这只是该公司所提供服务的一小部分。Gurunavi 的服务包括帮助餐厅进行客户管理的账本服务和 Gurunavi Pay 多支付服务，以这些服务为支撑，全面支持餐厅 ICT 环境的建设。当然，这一切都离不开海量的日志数据。
1：截至 2019 年 9 月 30 日。2：截至 2018 年 12 月。3：截至 2019 年 10 月 1 日。
采用 Elastic 实现分析大量日志所需的高速搜索
Gurunavi 是日本提供餐厅和其他主题信息的在线服务领域的先驱，自创立之初就管理着一个大型 ICT 环境来为这些服务提供支持。显然，这些系统会输出大量的日志数据，以前分析这些数据需要花费大量的时间和人力。
Toshiaki Iwamoto 是 Gurunavi 开发部工程科副科长。他回忆当时的情况时如是说：
“2016 年前后，Gurunavi 已经拥有数千台服务器。当出现故障或需要进行维护时，我们需要直接登录受影响的服务器来查看日志，使用 grep 命令查找日志，使用 scp 命令将日志临时复制到本地环境，然后通过这种方式处理问题。这个调查过程需要一个多小时才能完成，这意味着我们无法实时响应，并且需要做大量的人工工作，这就为疏忽和其他粗心大意的错误埋下了隐患。随着系统和日志变得越来越大，我们迫切需要一些工具来帮助处理这么多的工作量。”
就在那时，Gurunavi 与 Elastic Stack 的两个产品不期而遇：Elasticsearch 和 Kibana。
有了 Elastic Stack 提供的各种产品组件，无需将目标数据下载到本地环境，即可跨多个数据源进行高速实时搜索。随着公司提供的服务成倍增加并且变得更加高级，应用程序之间的 API 调用也越来越多。考虑到 Gurunavi 需要分析大量日志，Elastic Stack 产品确实是能满足其需求的上佳解决方案。Gurunavi 的 Iwamoto 先生说：“当时，市场上绝对没有可与之匹敌的产品，我们决定选择 Elastic，因为它是唯一的选择。”Gurunavi 在 2016 年全面实施了 Elasticsearch 和 Kibana。
实施 Elastic Cloud，减少版本升级的工作量
2018 年底，在实施几年后，Gurunavi 开始使用 AWS。
Gurunavi 选择在这个时间点将部分 Elastic Stack 许可更换成云许可，因为它们需要同时续期，于是该公司开始使用 Elastic Cloud 的 Elasticsearch Service。这样做是为了在 AWS 环境中实现日志的收集和分析，以及减少 Elastic 升级的操作工作量。
Iwamoto 先生说：“一些用户表示，他们在 2018 年之前一直在用 Kibana，已经用习惯了，希望依然能够使用高质量的 Kibana 界面来查看 AWS Cloudwatch 日志。在日志数据收集和其他功能方面，我们将 Elastic Cloud 与竞争对手的产品进行了比较，结果 Elastic Cloud 在成本、性能和始终提供最新版本方面更胜一筹。在实施方面，我们选用了 Functionbeat 和 Elasticsearch 采集节点。”
Gurunavi 的另一个优先事项是减少升级和类似任务的操作工作量。当务之急是避免这些任务过于依赖单个人的技能，因为 Iwamoto 先生是唯一拥有必要技术专长的人员。“版本更新很频繁，但我是唯一一个能够处理这类任务的人，这意味着我一个人的工作量非常大。我认为我们也可以通过采用 Elastic Cloud 来解决这些问题。”
（Gurunavi 的 Toshiaki Iwamoto）
这样，无论是在本地部署还是在云中，Gurunavi 都能得到 Elastic 环境的全面支持。
高速搜索所有应用程序和网络设备中的日志
Gurunavi 目前的系统可处理从所有应用程序和网络设备获取的日志，其数据库类型多达 50 种，总数据量为 500 亿个文档。
对于数据提取，来自本地部署高容量集群的日志数据会通过 Logstash 发送到 Elasticsearch，而云环境（包括容器）中的 Cloudwatch Logs 数据则从 Functionbeat 发送到 Ingest（如下图所示）。[Amazon] S3 数据会通过 Logstash 发送到 Elasticsearch。因为可以从各个角度透明地监测所有日志，所以不仅可以对这些数据进行故障排查，而且还可以将其用于更具战略意义的用途。
Iwamoto 先生说：“Gurunavi 是一家服务提供商，这意味着我们可以处理多种语言。此外，获取的日志数据类型取决于所涉及的应用程序的性质，而且会涉及大量的索引。开发人员想要从各个角度全面了解所有内容，包括云。现在这个全面的 Elastic 环境已经建立起来，这一点自然就能实现了。”
快速故障排查，减少操作工作量，发现数据新用途
Iwamoto 先生最初基于两点评估了 Elastic Stack 的整体优势。
“首先，以前复制日志数据和手动检查需要一个多小时，现在完成这些任务只需几秒钟，极大地提高了我们的工作效率。这不仅加快了从问题出现到看到调查结论的整个过程，而且这一过程的精确度也得到了显著提高。使用提供的 API，系统会将日志告警发送到 Slack 或 Webhook，以便我们更快地采取应对措施。此外，Elastic Cloud 可以在不中断的情况下进行升级，切换到另一个版本时不会涉及主要工作负载，而且始终可以使用最新版本，这是另一个主要益处。过去，当我几乎完全靠自己处理升级和其他工作时，完成一次升级大约需要五到十天（包括调查）。现在，升级几乎不需要占用我任何时间。”（Gurunavi 的 Toshiaki Iwamoto）
另外，这一系统对公司新入境旅游战略方面的贡献也不容忽视。
例如，可以使用 Elastic Stack 提取地理位置数据并可视化站点访问者的位置。Iwamoto 先生说：“Amazon Cloud Front 是 AWS 中的一项 CDN 服务，可以使用其日志按国家或地区查看站点访问数据。比如，为什么来自这个地方的访问量这么多？为什么这个地方的这么少？我们可以使用这些数据提出类似的问题，然后通过深入研究数据找到答案，例如相关内容或服务提供商存在问题。基于这些信息，我们可以采取相应措施来提高内容交付速度，选择开展活动的时机，或实施其他类似决策，让这些信息在我们未来的入境旅游战略中发挥极大作用。”
促成这一直观决策的另一个因素是使用 Vega 对图形数据进行可视化。Kibana 6.2 发布了一项新功能，可以将 Elasticsearch 数据与 Vega 和 Vega-Lite 结合使用，从而创建丰富的可视化信息。借助这些可视化信息，用户可以大致了解从大量数据中提取的信息，进而得出直观的结论。这项功能对不是 IT 专家的人员也很有用，例如营销或管理部门的员工。
在总结实施 Elastic 的益处时，Iwamoto 先生表示：“在我们当前复杂的系统环境和关联的大量日志数据中，很难想象没有 Elastic Stack 会是什么境地。”
扩展数据在商业战略中的应用
利用云实现高速日志搜索并减少版本升级的工作量后，Gurunavi 已经开始考虑在更具战略意义的目标中使用 Elastic Stack。
Iwamoto 先生说：“有了 Elastic 环境和 Elastic Cloud 的助力，我们已经摆脱了依赖单个人的技能来处理运营事务的窘境，系统的用途也大大增加。例如，由应用程序端人员创建的仪表板显示了随着时间的推移潜在客户转化率与 KPI 的关系图。通过将日志数据的作用发挥到极致，我们相信有可能创造更高水平的价值，因为数据不仅可以用于故障排查和其他与系统管理相关的任务，而且还可以用于与此类业务战略相关的目的。”
Gurunavi 继续在致力于为客户和餐厅提供高附加值的服务。
Elastic Stack 在最大限度地利用海量日志数据（总计 500 亿个文档）方面发挥着至关重要的作用，让这些服务逐一成为可能。
