WP Engine利用InfluxDB在全球范围内推动可观察性

作者：Jason Myers / 产品，用例，开发者
2022年4月7日

WP Engine平台为品牌提供解决方案，帮助他们快速在WordPress上创建令人瞩目的网站和应用程序。它托管超过150万个网站，为全球150多个国家的17.5万名客户提供服务，每天处理52亿次请求。WP Engine的总足迹大约占整个网络的8%。

寻找可靠性

考虑到这些统计数据，您可以想象当公司出现故障并且其监控解决方案同时失效时发生了什么。WP Engine曾自豪地运行一个生产中的最大Zabbix监控实例，该实例监控了15,000个主机，由一个Zabbix数据库支持。这个单一的数据库服务器是他们在故障期间的监控关键故障点。

为了解决这个问题，WP Engine的开发者开始寻找替代方案。他们需要一种能够处理其在全球范围内数据需求规模的东西。这意味着一个至少支持每分钟5百万次查询，并且每六分钟触发一次警报的解决方案。他们考虑了Datadog作为一个现成的选项，但由于成本问题，这对他们的业务来说是不可行的。

构建自定义可观察性平台

WP Engine构建了一个多层度的指标平台。最外层，即Fleet层，是WP Engine的15,000个主机所在之处，分布在不同服务和云服务提供商上。WP Engine曾考虑使用Fluentd进行数据收集，但最终选择了Telegraf，因为它使用资源更少，并且拥有庞大的插件库。WP Engine收集了CPU和内存利用率、服务器和容器级别、服务器响应时间、磁盘利用率等指标。

收集到的数据随后进入聚合层，该层在Kubernetes上运行，对数据进行清洗和过滤。清洗后的数据进入警报层，Kapacitor和InfluxDB OSS组合处理警报。此层将警报发送到Slack、PagerDuty和Amazon SNS等多种终端。Kapacitor还配置为将信号发送回Fleet层，以执行无需人工干预的自动任务。

从聚合层，指标通过Google Pub/Sub移动到存储层，在WP Engine上运行六个InfluxDB Enterprise节点。此中央时间序列存储库的数据也馈送到可视化层。WP Engine使用Chronograf和Grafana为内部用户构建仪表板。

结果

使用这个新的系统，WP Engine创建了一个满足其当前需求并能够与公司一起增长的解决方案。公司消除了其旧解决方案中存在的单点故障问题。它还投资了InfluxDB Enterprise的互连和冗余。WP Engine的指标平台每分钟处理500万个点，是旧系统的二十倍，并将数据存储在多个位置。WP Engine精心迁移到其新的警报系统，并将人力认知负担减少了50%。

想了解更多关于WP Engine如何使用InfluxDB的信息，请查看完整案例研究。