实践中的可观察性:使用New Relic One和Gremlin运行游戏日

在软件开发中有一个古老的真理:你的备份和上次的恢复一样好。对于您的可观察性平台，也可以说类似的情况:您不需要真的知道系统遇到问题之前它有多好，并且可以将仪表板上的峰值与实际的系统活动关联起来。

New Relic解决方案架构师与客户合作，构建使用我们平台的最佳实践。当我们与这些客户打交道时，我们不能等待中断，向他们展示New Relic的实际应用。但最近，我们有机会用一些混沌工程制造了一个受控中断。在我们的朋友的帮助下小鬼，我们能够向客户展示New Relic的可观察平台在混乱情况下的价值。

格莱姆林的混沌工程

混乱的工程是一种促进受控实验的实践，以发现系统中的弱点。这些实验暂时给你的系统施加压力，以模拟它在不同条件下的反应。目标是在问题成为用户的问题之前识别它们。理想情况下，在Gremlin，你可以通过以下四个步骤实现:

1. 通过良好的站点可靠性实践和可观察性为灾难做好准备
2. 在生产环境中运行自动化测试
3. 给无生产系统注入混乱
4. 到处注入自动混沌

Gremlin是领先的混沌工程平台。使用Gremlin，您可以安全地在平台和应用程序基础设施的每一层上运行混沌实验。您可以运行一些实验，增加延迟、使用黑洞降低网络流量、关闭主机、提高CPU使用率、攻击DNS等等。

换句话说，您可以以一种安全、可控的方式对系统的不同部分施加压力。但是当你将Gremlin与New Relic配对时，你便能够清楚地看到系统受到攻击时的行为。

Gremlin和New Relic:解决真正的客户问题

最近，我们有机会与Gremlin合作，帮助一位客户解决导致用户无法登录公司网络或应用程序的随机问题。为了帮助他们解决这些问题，并建立正确的警报、事件管理流程和运行手册，我们运行了一个游戏的一天与客户。

不要错过:如何举办一个对抗式游戏日

游戏日实质上就是消防演习。这是一个在安全的环境中实践常见的真实场景的机会。你破坏了一些东西，然后观察你的团队对这些问题的反应。对的人会得到提醒吗?你的仪表盘提供了正确的信息吗?你的团队对此有何反应?他们能多快解决这个事件?

在这个游戏日，我们想看看如果我们添加一些延迟会对客户的Cassandra数据库产生什么影响。我们在游戏日开始时使用Gremlin添加了额外的10毫秒延迟。

New Relic立即识别出延迟并发出适当的警报。在这张截图中，你可以看到与一次攻击相关的多个指标:

New Relic很容易识别10毫秒延迟的影响，但在现实世界中，这对我们客户的用户来说是最小的。所以我们把延迟提高到100毫秒。

那么混乱。

一开始是一些意想不到的警报New Relic的人工合成物:由于响应时间增加而触发多个警报:

随着延迟的持续，我们发现客户的Kubernetes集群中出现了一些关键的警报。

延迟增加了集群中几个pod的内存使用，这些pod有硬内存限制。

我们引入的Cassandra延迟影响了整个应用程序，从网络的响应时间到承载应用程序的集群，并对最终用户体验产生了重大影响。但是有了New Relic，我们的客户就可以看到完全这些故障是如何直接追溯到他们的数据库的。

比赛日是团队合作的日子

在最初的实验之后，客户在他们的Kafka集群和Amazon EC2实例中进行了延迟实验。在每一种情况下，New Relic都发现了攻击，并通知了正确的待命团队。响应团队能够模拟在每一种情况下寻找根本原因，并改进了他们的事件响应协议。我们在7个小时的回顾后结束了游戏，客户非常高兴。

Gremlin和New Relic一起利用这个游戏日为用户识别关键问题，以免影响用户。通过使用Gremlin安全地模拟真实世界的故障场景，客户的工程和SRE团队对New Relic的监控和警报有了信心，并完善了他们的事故响应协议，降低了他们识别和解决问题的时间。

事实上，在New Relic，我们使用Gremlin来完善我们的系统，并在用户发现问题之前主动发现软件中的问题。它是任何可观察性实践的基本工具。

学习如何改进事件响应过程一个强有力的事件管理行动计划正确减少MTTR．