生产环境服务监控是指定期对实时生产系统应用程序的一部分功能执行自动化测试。测试结果可以被推送到监控服务中，以便在出现故障时触发警报。这种技术是将自动化测试与系统监控两者相结合，以便及时发现生产环境中失败的业务功能。
在小型独立服务数量众多和频繁部署的时代，我们很难做到用与生产环境中完全相同的版本和数据来进行预生产环境（或测试环境）的测试。解决这一问题的其中一种方法是，将系统的可测试性从预生产环境扩展到生产环境，这是生产环境质量保证（QA）背后的重要理念。这样做是将思维模式从关注平均故障间隔时间（MTBF）转变为关注平均恢复时间（MTTR）。
对于大多数类型的故障（F），平均恢复时间（MTTR）要重要于平均故障间隔时间（MTBF）。
约翰·奥尔斯波（John Allspaw）
为此我们采用的一种技术是综合监控，我们曾经在一个数字汽车市场系统上使用过该技术，该系统在十几个国家拥有数百万级的用户。他们的生产环境中有近百个服务，每个服务每天需要部署多次。在将服务部署到生产环境之前，会在持续集成管道中运行测试脚本。集成测试的依赖服务不使用测试mock，而是直接调用生产环境中的组件运行测试脚本。
以下是这种测试的一个例子，它非常适合用于综合监控。它模拟了一个用户将他喜欢的分类添加到收藏列表中的过程。他采取的步骤如下：
- 打开主页，登录并删除所有收藏内容。此时，收藏计数器统计为0。
- 选择一些筛选条件并执行搜索。
- 通过点击星星将搜索结果中的两个条目添加到收藏夹中，星星从灰色变为黄色。
- 回到主页。此时，收藏计数器应该统计为2。
为了将来在后续的系统日志分析中排除测试人员的测试请求，我们可以在URL中添加了一个参数（如excluderequests=true）。该参数会连续性地传递给所有下游服务，当该参数设置为true时，被调用的每个服务都会将其当成测试请求数据。
我们可以使用excluderequests参数在后端数据存储时将数据标记为测试监控数据。但在我们上面的例子中，这并是必要的，因为我们使用了相同的用户账号，并在每次测试开始时清除其状态。这种方法的缺点是我们无法同时运行此测试。当然，我们可以为每个测试运行都创建一个新的用户账号。为了使测试用户易于识别，这些账号的电子邮件地址中将具有特定的前缀或后缀。另一种常见的方案是在每个请求中发送一个自定义的HTTP请求头，以将其标识为“测试请求”，这对于下游的API接口来说更加容易识别。
我们的测试使用Selenium webdriver和PhantomJS，每5分钟对生产环境中的服务执行一次。测试结果被输入到监控系统中，并在团队的仪表板上显示。根据被测功能的重要性，失败的结果还可能会触发系统警报，以便在第一时间通知相关人员处理。
在测试金字塔顶部的宽栈测试（Broad Stack Tests）中，有一部分非常适合用于系统监控测试。这些测试包括用于Web应用程序的用户界面测试、用户场景测试、用户验收测试或端到端测试，或者用于API的消费者驱动契约测试（CDCs）。相比于运行一组用户界面测试来说，更好的方案是将待监控事务输入系统，并断言其期望的最终状态，如数据库条目、队列中的消息或目录中的文件等等，从而来判断系统服务是否正常。
