问题描述
在使用Splunk警报时，有一个需求是希望能够验证复杂警报的质量。他们的代码已经通过单元测试、端到端测试、代码审查、分阶段测试和部署流程等质量保证流程，但是警报的质量验证流程却很简单，只是手动编写和偶尔修改。这对于简单的阈值检查是合理的，但是对于一些复杂的查询构建的警报来说，这样的流程是不够的。有时候，这些警报由大约20行的查询组成。如果我们意外地破坏了一个警报，那么我们就无法得知某些逻辑或组件是否出现问题，这可能会导致生产环境的不稳定。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1：将监控纳入DTAP流程
由于监控是生产环境的一部分，因此应该将其纳入DTAP（开发、测试、验收和生产）流程。这意味着在开发、测试、验收和生产环境中都要进行监控。如果有人在生产环境中修改了一个检查项，并且这个修改导致某些检查项被静默，如果团队没有收到报告，那么客户可能会受到影响，这可能是一个巨大的问题。简而言之，如果监控是生产环境的一部分，那么它也应该应用于DTAP的所有阶段。
方案2：进行测试
如果在Splunk中使用自定义脚本，并且这些脚本是用Python或其他语言编写的，那么你还应该进行单元测试和集成测试。在大多数监控系统中，会检查0、1、2和3的退出代码，因此这些也应该包含在测试中。如果监控是用bash编写的，可以使用BATS进行测试，而Powershell可以使用Pester进行测试。
为什么要测试这些脚本？原因与DTAP部分中描述的相同。想象一下，如果有人通过引入一个拼写错误来破坏某个监控脚本，而你却没有收到通知，那么这可能会对客户和团队产生巨大的影响。想象一下，如果你不得不花几天时间来调试某个脚本，因为它不正常工作，而这本可以事先预防。因此，我建议对这些“简单”的监控脚本进行单元测试、集成测试甚至持续集成。
总结
验证复杂警报的质量是非常重要的，可以通过将监控纳入DTAP流程和进行测试来实现。这样可以确保在生产环境中不会因为警报的问题而导致不稳定。