我们不应该将监控系统中的所有指标都定义为 SLI;只有理解用户对系统的真实需求才能真正决定哪些指标是否有用。指标过多会影响对那些真正重要的指标的关注，而选择指标过少则会导致某些重要的系统行为被忽略。一般来说，四五个具有代表性的指标对系统健康程度的评估和关注就足够了。

常见的服务，根据它们的相关 SLI通常会归类为以下几个大类。

• 用户可见的服务系统，例如莎士比亚搜索服务的前端服务器通常关心可用性、延迟，以及吞吐量。换句话说∶是否能正常处理请求?每个请求花费的时间是多少?多少请求可以被处理?
• 存储系统通常强调∶延迟、可用性和数据持久性。换句话说∶读写数据需要多少时间?我们是否可以随时访问数据?数据是否一段时间内还能被读取 ? 扩展讨论参见第 26 章。
• 大数据系统，例如数据处理流水线系统，一般来说关心吞吐量和端到端延迟。换句话说∶处理了多少数据?数据从输入到产出需要多少时间?（某些流水线任务还会关注某个单独处理阶段的延迟。）
• 所有的系统都应该关注∶正确性。是否返回了正确的回复，是否读取了正确的数据，或者进行了正确的数据分析操作。正确性是系统健康程度的一个重要指标，但是它更关注系统内部的数据，而不是系统本身，所以这通常不是SRE 直接负责的。
  

利用某种监控系统，大部分指标数据都在服务器端被收集，例如Borgmon（具体参见第10章）或者Prometheus。或者利用某种日志分析系统，例如分析日志中HTTP500回复所占的比例。然而，某些系统可以加入对客户端数据的收集，否则可能会错失一些不影响服务器端指标，但是对用户产生影响的问题。例如、只关注莎士比亚服务器搜索后端的延迟可能会错失由页面JavaScript脚本导致的用户可见的延迟问题。在这个例子中，度量页面在浏览器中可用的延迟是度量用户体验的一个更好的指标。

我们不应该将监控系统中的所有指标都定义为 SLI;只有理解用户对系统的真实需求才能真正决定哪些指标是否有用。指标过多会影响对那些真正重要的指标的关注，而选择指标过少则会导致某些重要的系统行为被忽略。一般来说，四五个具有代表性的指标对系统健康程度的评估和关注就足够了。

常见的服务，根据它们的相关 SLI通常会归类为以下几个大类。

• 用户可见的服务系统，例如莎士比亚搜索服务的前端服务器通常关心可用性、延迟，以及吞吐量。换句话说∶是否能正常处理请求?每个请求花费的时间是多少?多少请求可以被处理?
• 存储系统通常强调∶延迟、可用性和数据持久性。换句话说∶读写数据需要多少时间?我们是否可以随时访问数据?数据是否一段时间内还能被读取 ? 扩展讨论参见第 26 章。
• 大数据系统，例如数据处理流水线系统，一般来说关心吞吐量和端到端延迟。换句话说∶处理了多少数据?数据从输入到产出需要多少时间?（某些流水线任务还会关注某个单独处理阶段的延迟。）
• 所有的系统都应该关注∶正确性。是否返回了正确的回复，是否读取了正确的数据，或者进行了正确的数据分析操作。正确性是系统健康程度的一个重要指标，但是它更关注系统内部的数据，而不是系统本身，所以这通常不是SRE 直接负责的。
  

利用某种监控系统，大部分指标数据都在服务器端被收集，例如Borgmon（具体参见第10章）或者Prometheus。或者利用某种日志分析系统，例如分析日志中HTTP500回复所占的比例。然而，某些系统可以加入对客户端数据的收集，否则可能会错失一些不影响服务器端指标，但是对用户产生影响的问题。例如、只关注莎士比亚服务器搜索后端的延迟可能会错失由页面JavaScript脚本导致的用户可见的延迟问题。在这个例子中，度量页面在浏览器中可用的延迟是度量用户体验的一个更好的指标。