DevOps 和 SRE 从业者已经敏锐地意识到系统可靠性的重要性，因为这是每个高绩效组织共同的目标之一。根据可靠的数据定义清晰的可靠性目标对于开发者和 SRE 之间的高效协作至关重要。这一需求涵盖了从应用到后端数据库服务的整个基础设施。
服务水平目标 (SLO) 为所有团队提供了一个强大的接口，用于根据服务水平指标 (SLI) 或数据点设定清晰的性能和可靠性目标。一个好的模式是将 SLI 视为数据，而将 SLO 视为用于做出关键决策的信息。
延伸阅读: https://cloud.google.com/blog/products/devops-sre/sre-fundamentals-slis-slas-and-slos
Redis 是一种流行的多模型 NoSQL 数据库服务器，提供内存数据访问速度，支持搜索、消息传递、流处理、缓存和图等功能。Twitter、Snapchat、Freshworks、GitHub、Docker、Pinterest 和 Stack Overflow 等高性能网站都依赖 Redis 来实时传输数据。
Redis SLOs 可分为三个主要类别
类别 | 定义 | SLO 示例 | SLI 示例 |
吞吐量 | 在给定时间段内通过服务推送的操作数量 | 系统应能够每秒执行 2 亿次操作 | redisenterprise.total_req |
延迟 | 操作所需的时间 | 平均写入延迟不应超过 1 毫秒 | redis_enterprise.avg_latency |
容量 | 底层数据源的内存/存储/网络限制 | 数据库应有 20% 的内存开销来处理突发情况 | redisenterprise.used_memory_percent |
运行自己的性能数据平台既耗时又困难。Datadog 提供了一个优秀的平台，具有开源代理用于收集指标，并允许轻松显示这些指标并在必要时发出警报。
Datadog 可以让你
这是请求从首次到达 Redis Enterprise 代理到返回响应的平均时间。它不包括从远程客户端角度看的完整时间。
由于 Redis 因性能而流行，通常你会期望大多数操作在几毫秒内返回。调整任何警报以匹配你的 SLA。通常建议你同时测量客户端的 Redis 操作延迟，以便更容易确定是服务器变慢还是网络延迟增加导致了性能问题。
可能的原因
原因 | 因素 |
请求激增 | 检查网络流量和每秒操作指标，确定是否存在相应增长 |
慢查询 | 在 Redis Enterprise UI 中检查数据库的慢日志 |
计算资源不足 | 检查 CPU 使用率、内存使用率百分比或逐出次数是否正在增加 |
补救措施
操作 | 方法 |
增加资源 | 通过访问 Web UI 并在数据库上启用集群，可以在线扩容数据库。在极端情况下，可以将更多节点添加到集群并重新平衡资源。 |
低效查询 | Redis 允许你查看具有可调阈值的慢日志。可以在 Redis Enterprise UI 中查看，或者运行：redis-cli -h HOST -p PORT -a PASSWORD SLOWLOG GET 100 |
这是数据库已用内存占设定内存限制的百分比。
在 Redis Enterprise 中，所有数据库都设置了最大内存限制，以确保多租户环境中的隔离。在运行开源 Redis 时也强烈推荐这样做。请注意，Redis 不会在删除键后立即释放内存。根据数据库的大小，通常 80-95% 是一个安全的阈值。
原因 | 因素 |
活动可能激增 | 检查网络流量和每秒操作指标，确定是否存在相应增长 |
数据库大小设置不正确 | 查看一段时间内的内存使用原始字节数，看看使用模式是否发生变化 |
保留策略不正确 | 检查键是否正在被逐出或过期 |
操作 | 方法 |
增加资源 | 通过 Redis Enterprise UI 或 API，可以在不停机的情况下在线提高数据库内存限制。 |
保留策略 | 在缓存使用场景中，为未使用的旧数据设置 TTL 使其过期通常很有帮助。此外，可以设置逐出策略，然而，在资源非常紧张的极高吞吐量环境中，这些策略往往无法跟上。 |
这是 Redis 访问已存在键的百分比。
此指标仅在缓存使用场景中有用，对于其他所有使用场景应忽略。缓存中数据的时效性与缓存缓解到任何后端数据服务的流量的效率之间存在权衡。在确定警报阈值时应仔细考虑这些权衡。
这高度依赖于应用缓存本身，没有适用于大多数情况的通用规则。
请注意，Redis 命令会返回键或字段是否已存在的信息。例如，HSET 命令返回哈希中已添加的字段数量。
这是从数据库中逐出的项目计数。
数据库进出网络流量的计数器。
虽然这两个指标不会帮助你精确定位根本原因，但网络流量是故障的优秀先行指标。网络流量模式的变化表明数据库行为发生了相应变化，通常需要进一步调查。
当前到数据库的客户端连接数。
应同时监控此指标的最小和最大连接数。未达到最小连接数是网络或应用配置错误的优秀指标。超过最大连接数可能表明需要对数据库进行调优。
原因 | 因素 |
未达到最小客户端数 | 客户端配置不正确、网络防火墙或网络问题 |
超过最大连接数 | 客户端库未释放连接或客户端数量增加 |
操作 | 方法 |
客户端配置错误 | 确认客户端配置 |
网络问题 | 从客户端节点通过 TELNET 向端点发出 PING 命令 |
连接数过多 | 请确保你在客户端库中使用了连接池，并且连接池大小设置得当 |
连接数过多 | 使用 rladmin 运行：tune proxy PROXY_NUMBER threads VALUE threads VALUE |
你可以在这里访问完整的指标列表。
按照以下步骤设置 Datadog 代理来监控你的 Redis Enterprise 集群以及数据库指标
在我们开始安装之前，先看看可以运行 Datadog 代理的各种模式
在外部监控模式下，运行在集群外部的 Datadog 代理可以监控多个 Redis Enterprise 集群，如上图所示。
使用本地主机模式，可以将集成安装在 Redis Enterprise 集群的每个节点上。这允许用户将操作系统级别指标与 Redis 特定指标关联起来，以加快根本原因分析。只有 Redis Enterprise 集群的主节点会向 Datadog 提交指标和事件。如果集群主节点发生迁移，新的集群主节点将开始向 Datadog 提交数据。
对于本次演示，我们将利用本地主机模式，因为我们只需要配置两个节点。
选择你偏好的操作系统发行版并安装 Datadog 代理
运行以下命令，使用 Agent 安装集成 wheel。将集成版本替换为 1.0.1。
datadog-agent integration install -t datadog-redisenterprise==<INTEGRATION_VERSION>复制示例配置并更新所需部分，以便从你的 Redis Enterprise 集群收集数据
应将以下最小配置添加到 Enterprise 主节点。
sudo vim /etc/datadog-agent/conf.d/redisenterprise.d/conf.yaml #################################################################
# Base configuration
init_config:
instances:
- host: localhost
username: [email protected]
password: secretPassword
port: 9443类似地，你需要编辑 Enterprise Follower 的配置文件以添加以下内容
sudo vim /etc/datadog-agent/conf.d/redisenterprise.d/conf.yaml #################################################################
# Base configuration
init_config:
instances:
- host: localhost
username: [email protected]
password: secretPassword
port: 9443应将以下配置添加到监控节点
# Base configuration
init_config:
instances:
- host: cluster1.fqdn
username: [email protected]
password: secretPassword
port: 9443
- host: cluster2.fqdn
username: [email protected]
password: secretPassword
port: 9443 sudo service datadog-agent restart在集成菜单下找到 Redis Enterprise 集成
显示向 Datadog 报告数据的主机
列出 Redis Enterprise 仪表盘
Datadog 基础设施列表下的主机详情
显示第 1 个主机指标（CPU、内存使用率、负载平均值等）的 Datadog 仪表盘
显示第 2 个主机指标的 Datadog 仪表盘
运行 datadog-agent 命令显示 Redis Enterprise 集成工作正常。
sudo datadog-agent status redisenterprise (1.0.1)
-----------------------
Instance ID: redisenterprise:ef4cd60aadac5744 [OK]
Configuration Source: file:/etc/datadog-agent/conf.d/redisenterprise.d/conf.yaml
Total Runs: 2
Metric Samples: Last Run: 0, Total: 0
Events: Last Run: 0, Total: 0
Service Checks: Last Run: 0, Total: 0
Average Execution Time : 46ms
Last Execution Date : 2021-10-28 17:27:10 UTC (1635442030000)
Last Successful Execution Date : 2021-10-28 17:27:10 UTC (1635442030000)
让我们运行一个名为 redis-benchmark 的内存基准测试工具，以模拟任意数量的客户端同时连接并执行服务器操作，衡量请求完成所需的时间。
memtier_benchmark --server localhost -p 19701 -a password
[RUN #1] Preparing benchmark client...
[RUN #1] Launching threads now...
此命令指示 memtier_benchmark 连接到你的 Redis Enterprise 数据库并生成以下负载
运行此命令，直到它将你的数据库填充到你希望用于测试的状态。最简单的检查方法是查看数据库指标页面。
memtier_benchmark --server localhost -p 19701 -a Oracle9ias12# -R -n allkeys -d 500 --key-pattern=P:P --ratio=1:0
setting requests to 50001
[RUN #1] Preparing benchmark client...
[RUN #1] Launching threads now...
Datadog 事件流提供你的基础设施和服务事件的即时视图，帮助你排查当前或过去发生的问题。事件流显示你的基础设施生成的最新事件以及相关的监控器，如下图所示。
原因 | 因素 |
未达到最小客户端数 | 客户端配置不正确、网络防火墙或网络问题 |
超过最大连接数 | 客户端库未释放连接或客户端数量增加 |
请输入文本内容，然后按回车。
显示第 1 个主机指标（CPU、内存使用率、负载平均值等）的 Datadog 仪表盘
显示向 Datadog 报告数据的主机
应将以下配置添加到监控节点
原因 | 因素 |
活动可能激增 | 检查网络流量和每秒操作指标，确定是否存在相应增长 |
数据库大小设置不正确 | 查看一段时间内的内存使用原始字节数，看看使用模式是否发生变化 |
保留策略不正确 | 检查键是否正在被逐出或过期 |
虽然这两个指标不会帮助你精确定位根本原因，但网络流量是故障的优秀先行指标。网络流量模式的变化表明数据库行为发生了相应变化，通常需要进一步调查。
