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 SLO 可以分为三个主要类别
类别 | 定义 | 示例 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 代理
运行以下命令使用代理安装集成轮子。将集成版本替换为 1.0.1。
datadog-agent integration install -t datadog-redisenterprise==<INTEGRATION_VERSION>复制 示例配置 并更新所需部分以从您的 Redis Enterprise 集群收集数据
应将以下最小配置添加到企业主节点。
sudo vim /etc/datadog-agent/conf.d/redisenterprise.d/conf.yaml #################################################################
# Base configuration
init_config:
instances:
- host: localhost
username: user@example.com
password: secretPassword
port: 9443同样，您需要编辑企业跟随者的配置文件以添加以下内容
sudo vim /etc/datadog-agent/conf.d/redisenterprise.d/conf.yaml #################################################################
# Base configuration
init_config:
instances:
- host: localhost
username: user@example.com
password: secretPassword
port: 9443应将以下配置添加到监控节点
# Base configuration
init_config:
instances:
- host: cluster1.fqdn
username: user@example.com
password: secretPassword
port: 9443
- host: cluster2.fqdn
username: user@example.com
password: secretPassword
port: 9443 sudo service datadog-agent restart在集成菜单下查找 Redis Enterprise 集成
显示向 Datadog 报告数据的主机
列出 Redis Enterprise 仪表板
Datadog 基础设施列表中的主机详细信息
Datadog 仪表板显示第一个主机的宿主指标（CPU、内存使用率、负载平均值等）
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 事件流显示您基础设施和服务事件的即时视图，以帮助您排查当前或过去发生的故障。事件流显示您的基础设施和相关监控器生成的最新事件，如下面的图表所示。
原因 | 因素 |
未达到最小客户端 | 错误的客户端配置、网络防火墙或网络问题 |
超过最大连接数 | 客户端库未释放连接或客户端数量增加 |
请点击您的文本内容，然后按回车键。
Datadog 仪表板显示第一个主机的宿主指标（CPU、内存使用率、负载平均值等）
显示向 Datadog 报告数据的主机
应将以下配置添加到监控节点
原因 | 因素 |
活动可能激增 | 检查网络流量和每秒操作指标以确定是否存在相应的增加 |
数据库大小不正确 | 查看内存使用情况的原始字节随时间的变化，以确定使用模式是否已更改 |
保留策略不正确 | 检查密钥是否正在被逐出或过期 |
虽然这两个指标不会帮助您查明根本原因，但网络流量是故障的一个极佳的领先指标。网络流量模式的变化表明数据库行为的相应变化，通常需要进一步调查。
