保持卓越的商业表现
自动检测入侵
通过索引服务器活动,Elastic 可以检测间谍机器人和网络攻击,并自动触发对策。
在几分钟内解决 IT 事件
过去,每当发生事件时,都需要花费数小时在数十台服务器中进行搜索。现在,我们只需使用提供服务器日志摘要的仪表板即可。
技术团队的晋升
公司概览
作为法国第一大在线旅游网站,甚至是法国第一大电子商务网站,Oui.SNCF 是法国铁路的专业分销渠道。这家 SNCF 子公司在 2016 年实现了 410 万欧元的营业额,这得益于每年售出 8600 万张车票,高峰时段每秒售出 40 张车票。平均每月接待 1300 万独立访客,其中 63% 的访客通过移动设备访问该公司的服务。其 V. 应用程序已下载 1500 万次,三分之一的交易是通过该应用程序完成的。在 IT 方面,Oui.SNCF 的业务由 4000 台服务器支持,这些服务器分布在两个数据中心,由负责技术管理的 Oui.SNCF 分支机构管理。这些服务器充满了用于改进销售和业务服务的潜在指标。
可视化数据以提高子部门效率
Oui.SNCF 目前使用 400 个仪表板,其中一些仪表板永久显示在墙壁屏幕上,以便实时监控其业务活动。这一改进不仅得益于 Elastic Stack 对公司网站和移动应用程序数据的索引,还得益于 Kibana 的仪表板创建功能。这使子部门能够最大限度地提高其服务的性能。
Oui.SNCF 使用 Elastic 的经验
Dominique Debruyne 负责 Oui.SNCF-Technologies 的大数据技术部门。他目前的目标是构建一个技术平台,用于发送、存储、归档、处理和恢复最大数量的内部和外部数据源,以便更好地了解公司的客户、进行预测性分析并实时监控信息系统的性能。然而,这些都是相对较新的任务。Oui SNCF-Technologies 负责开发、托管和部署 IT 工具以响应子部门的需求,因此 Dominique Debruyne 最初的目标实际上是保证存储在关系数据库中的结构化数据的服务质量 (QoS) 和服务级别协议 (SLA)。
为了简化性能监控(由于信息系统和应用程序的数量不断增加,性能监控变得越来越复杂),我们将服务器的日志集中到一个数据湖中,然后我们可以从中得出特定的指标。该系统很快被证明对技术团队非常有价值,并且很明显,将其进一步扩展以满足子部门的需求并从中获得更多价值是有意义的。这就是大数据团队在两年半前诞生的原因。
Oui.sncf 与 Elastic 的旅程
挑战:在 IT 复杂性增加的情况下保持高质量的服务
在 Oui.sncf,从 2013 年开始服务器的增加对技术团队和子部门的效率都产生了负面影响。技术团队为了监控设备的正常运行,不得不花费时间在 Windows 桌面上下载日志。与此同时,子部门在尝试分析其庞大的 Oracle 数据库中的商业数据时,经常会遇到请求导致系统变慢的问题。
在很短的时间内,我们的服务器就从几十台增加到了几千台!在早期,一旦客户向我们提出异常,我们就需要在大量的日志中搜索他们的流程,以便准确地找出问题所在。这花费了我们时间,并对我们的服务水平质量构成了风险。
解决方案:收集数据、索引数据并通过仪表板可视化数据
我们参加了技术会议,以寻找一种能够实时恢复、分析和直观地可视化数据的解决方案。使用 Elasticsearch 的决定获得了一致同意。我们看到了它的一些优点:它是一个独特的平台,而不是多种不同的工具;它可以承受大多数不同的使用场景;它的可扩展性很强,只需将基础设施部署两次即可使其容量自行翻倍;并且它最终非常易于维护。
部署:允许每个子部门找到自己的兴趣点
Elastic 平台使子部门能够与当前发生的事件进行交互,将它们与前几天的事件进行比较,以跟踪它们的进展。同时,这些数据在 Hadoop 中存储三年,用于长期的商业智能目的。Hadoop 中的分析按批次进行,而 Elasticsearch 可以帮助我们实时完成分析。
自 2017 年以来,该架构已通过 Apache Kafka 进行了丰富,这有助于吸收峰值负载并防止 Oui.sncf 的活动出现任何减速。数据本身的摄取目前委托给 Flume,这是一个 Apache 基金会开源项目。由于其受欢迎程度下降,它应该很快被其 Apache 继任者 NiFi 取代。该架构旨在促进预测分析功能和异常检测,后者借助 X-Pack 中提供的 Elastic 机器学习功能实现。
关于仪表板,最大的努力不是发生在 Kibana 中,而是事先进行的。我们首先需要对数据进行标准化:换句话说,开发包含我们要跟踪的所有技术和部门信息的日志模板,以便我们的仪表板基于可以轻松交叉检查的连贯数据。为此,我们与一个专门的团队合作了一年,为我们的应用程序开发人员制作 Java、PHP 或 Python 库,这些库将根据十几个模板生成标准化的日志,然后再由 Elasticsearch 进行索引。我们很高兴采取了这种专业的处理方法。
结果:50 个项目由 400 个仪表板监控,安全系统可以自行运行
迄今为止,Kibana 已用于 50 多个项目,通过 400 个仪表板每天处理 20 亿个文档。其中,每天使用 200 个仪表板来监控服务保持在最高水平、寻找改进领域并尽可能清楚地了解活动。
Oui.sncf 在其每个服务部门内安装了墙式屏幕,用于显示 Kibana 仪表板,使员工能够持续跟踪他们感兴趣的事件进程。这是一个可视的、颜色编码的检查:如果所有指标都显示为绿色,则一切正常。如果我们看到曲线开始漂移,我们会前往我们的工作站,打开交互式表格,这将帮助我们检查问题。
例如,我们使用 Elasticsearch 索引的信息来识别任何扫描我们站点的机器人,以便在防火墙级别阻止它们。我们近一半的网络流量来自这些机器人的活动。因此,通过将访问次数减半,我们减轻了网络负载,最终,这有助于我们节省开支。同样,我们能够检测到负载均衡器中的异常,并可以自动触发预防措施,以防止我们遭受拒绝服务攻击。
Elastic Stack 给予我们的可见性构成了 Oui.sncf 商业成功的重要组成部分。
Oui.sncf 的集群
- 集群10
- 索引> 3,000
- 节点40
- 查询率400,000 次(按批次)
- 托管环境从组装到生产
- 副本1
- 文档800 亿
- 基于时间的索引每日、每周和每月
- 总数据大小80 TB
- 节点规格64 GB - 128 GB,本地存储
- 每日摄取率2 TB