在从旧监控堆栈过渡期间，我们使用了这两个系统。现在，我们只依赖 Prometheus。
新的设置将解决时间从 5 分钟缩短至 15 秒，使我们能够进行细粒度的深度分析。甚至 MTTD（平均检测时间）也缩短了 4 倍。
我们有大约 25 个社区指标导出器以及一些自定义导出器（如_lxc_exporter_）。我们主要使用文本文件收集器来公开自定义业务相关指标。
我们还评估了堆栈。我们对它并不满意，因为当时它的功能有限——Prometheus 在很多方面看起来更简单，实施起来也更成熟。
2017 年下半年
我们开始使用PagerDuty进行寻呼。我们每周 24 小时轮班值班。我们的情况是每五周或六周轮班一次，这很舒服。但我们期待彻底取消这项职责。相反，我们将照顾好我们拥有的服务，因为所有者最了解问题所在。
去年，我们的基础设施自 2015 年以来增长了N倍，主要瓶颈变成了 Prometheus 和 Alertmanager。我们的 Prometheus 占用了大约 2TB 的磁盘空间。如果我们使用Knife重新启动或推送节点，我们会暂时错过监控数据。Prometheus 重新启动大约需要 10-15 分钟——这是不可接受的。
另一个问题是，如果一。因此，我们决定实施一个高可用性监 土耳其电话 基础设施：两个 Prometheus 节点和两个位于不同大陆的 Alertmanager。
新的 Hostinger 监控基础设施
Hostinger 监控基础设施
我们的主要可视化工具是 Grafana。如果主节点发生故障，Grafana 能够查询备用 Prometheus 节点至关重要。这很容易 – 只需在前面放置一个 HAProxy 并在本地接受连接即可。
另个问题是弄清楚如何防止用户
（开发人员和其他内部员工）滥用仪表板，导致 Prometheus 节点过载。或者，如果主节点发生故障，则导致备份节点过载——惊群问题。
为了达到预期状态，我们给了Trickster一个机会。它极大地加快了仪表板的加载时间。它缓存时间序列。在我们的例子中，缓存位于内存中，但有更多选项可以将其存储在何处。即使主节点发生故障并且您刷新仪表板，Trickster 也不会向第二个节点查询其已缓存在内存中的时间序列。Trickster 位于 Grafana 和 Prometheus 之间。它只与 Prometheus API 对话。
Prometheus 节点是独立的，而 Alertmanager 节点则组成一个集群。如果两个 Alertmanager 都看到 我获取了实际流量的数据集 相同的警报，它们将进行重复数据删除并触发一次，而不是多次。
我们计划运行大量的_blackbox_exporters_并监控每个Hostinger客户的网站，因为任何无法监控的东西都无法访问。全球有超过 100 万人选择 Hostinger 作为他们的网络托管服务提供商。掌控某人的在线成 沙特阿拉伯电话号码 是一项巨大的责任，因此我们创建了一个复杂的招聘流程，以确保我们只聘用最优秀的人才。我们利用我们所有的知识创建了一个庞大的内部 Hostinger 学院，以培训能够应个位置出现故障我 对挑战的新客户成功专家。然而，这还不够。