Redis介绍
Redis是一种高级key-value数据库。它跟memcached类似,不过数据可以持久化,而且支持的数据类型很丰富。有字符串,链表、哈希、集合和有序集合5种。支持在服务器端计算集合的并、交和补集(difference)等,还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务器。Redis的所有数据都是保存在内存中,然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”);也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。
Redis监控
首先判断客户端和服务器连接是否正常
1
2
3
4
5
6
7
|
# 客户端和服务器连接正常,返回PONG redis> PING PONG # 客户端和服务器连接不正常(网络不正常或服务器未能正常运行),返回连接异常 redis 127.0 . 0.1: 6379 > PING
Could not connect to Redis at 127.0 . 0.1: 6379: Connection refused
|
Redis 监控最直接的方法就是使用系统提供的 info 命令,只需要执行下面一条命令,就能获得 Redis 系统的状态报告。
1
|
redis-cli info |
结果会返回 Server、Clients、Memory、Persistence、Stats、Replication、CPU、Keyspace 8个部分。从info大返回结果中提取相关信息,就可以达到有效监控的目的。
先解释下各个参数含义
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
# Server redis_version: 2.8 . 8 # Redis 的版本
redis_git_sha 1: 00000000
redis_git_dirty: 0
redis_build_id:bf 5 d 1747 be 5380 f
redis_mode:standalone os:Linux 2.6 . 32 -220.7 . 1 .el 6 .x 86 _ 64 x 86 _ 64
arch_bits: 64
multiplexing_api:epoll gcc_version: 4.4 . 7 #gcc版本
process_id: 49324 # 当前 Redis 服务器进程id
run_id:bbd 7 b 17 efcf 108 fdde 285 d 8987 e 50392 f 6 a 38 f 48
tcp_port: 6379
uptime_in_seconds: 1739082 # 运行时间(秒)
uptime_in_days: 20 # 运行时间(天)
hz: 10
lru_clock: 1734729
config_file:/home/s/apps/RedisMulti_video_so/conf/zzz.conf # Clients connected_clients: 1 #连接的客户端数量
client_longest_output_list: 0
client_biggest_input_buf: 0
blocked_clients: 0
# Memory used_memory: 821848 #Redis分配的内存总量
used_memory_human: 802.59 K
used_memory_rss: 85532672 #Redis分配的内存总量(包括内存碎片)
used_memory_peak: 178987632
used_memory_peak_human: 170.70 M #Redis所用内存的高峰值
used_memory_lua: 33792
mem_fragmentation_ratio: 104.07 #内存碎片比率
mem_allocator:tcmalloc -2.0
# Persistence loading: 0
rdb_changes_since_last_save: 0 #上次保存数据库之后,执行命令的次数
rdb_bgsave_in_progress: 0 #后台进行中的 save 操作的数量
rdb_last_save_time: 1410848505 #最后一次成功保存的时间点,以 UNIX 时间戳格式显示
rdb_last_bgsave_status:ok rdb_last_bgsave_time_sec: 0
rdb_current_bgsave_time_sec: -1
aof_enabled: 0 #redis是否开启了aof
aof_rewrite_in_progress: 0
aof_rewrite_scheduled: 0
aof_last_rewrite_time_sec: -1
aof_current_rewrite_time_sec: -1
aof_last_bgrewrite_status:ok aof_last_write_status:ok # Stats total_connections_received: 5705 #运行以来连接过的客户端的总数量
total_commands_processed: 204013 # 运行以来执行过的命令的总数量
instantaneous_ops_per_sec: 0
rejected_connections: 0
sync_full: 0
sync_partial_ok: 0
sync_partial_err: 0
expired_keys: 34401 #运行以来过期的 key 的数量
evicted_keys: 0 #运行以来删除过的key的数量
keyspace_hits: 2129 #命中key 的次数
keyspace_misses: 3148 #没命中key 的次数
pubsub_channels: 0 #当前使用中的频道数量
pubsub_patterns: 0 #当前使用中的模式数量
latest_fork_usec: 4391
# Replication role:master #当前实例的角色master还是slave connected_slaves: 0
master_repl_offset: 0
repl_backlog_active: 0
repl_backlog_size: 1048576
repl_backlog_first_byte_offset: 0
repl_backlog_histlen: 0
# CPU used_cpu_sys: 1551.61
used_cpu_user: 1083.37
used_cpu_sys_children: 2.52
used_cpu_user_children: 16.79
# Keyspace db 0: keys= 3 ,expires= 0 ,avg_ttl= 0 #各个数据库的 key 的数量,以及带有生存期的 key 的数量
|
内存使用
如果 Redis 使用的内存超出了可用的物理内存大小,那么 Redis 很可能系统会被杀掉。针对这一点,你可以通过 info 命令对 used_memory 和 used_memory_peak 进行监控,为使用内存量设定阀值,并设定相应的报警机制。当然,报警只是手段,重要的是你得预先计划好,当内存使用量过大后,你应该做些什么,是清除一些没用的冷数据,还是把 Redis 迁移到更强大的机器上去。
持久化
如果因为你的机器或 Redis 本身的问题导致 Redis 崩溃了,那么你唯一的救命稻草可能就是 dump 出来的rdb文件了,所以,对 Redis dump 文件进行监控也是很重要的。可以通过对rdb_last_save_time 进行监控,了解最近一次 dump 数据操作的时间,还可以通过对rdb_changes_since_last_save进行监控来获得如果这时候出现故障,会丢失(即已改变)多少数据。
Keys
通过获取Keyspace中的结果得到各个数据库中key的数量
QPS
即每分钟执行的命令个数,即:(total_commands_processed2-total_commands_processed1)/span,为了实时得到QPS,可以设定脚本在后台运行,记录过去几分钟的total_commands_processed。在计算QPS时,利用过去的信息和当前的信息得出QPS的估计值。
参考
http://www.cnblogs.com/kaituorensheng/p/3979298.html
相关推荐
在“redis监控模板-配置-脚本.zip”压缩包中,包含了一些关键组件,用于帮助Zabbix监控Redis实例: 1. **redis.conf**:这是Redis服务器的主要配置文件,包含了Redis服务器的所有设置。例如,你可以通过修改`bind`...
然而,它也有局限性,如代理层可能导致性能损耗,缺乏监控界面,以及无法平滑地增加或减少Redis实例,这使得扩展集群变得困难。 3. Codis是针对Twemproxy的不足而研发的,主要解决了平滑扩展的问题。Codis由Codis ...
将两者结合,配合Grafana的可视化能力,可以构建出一个高度自定义的Redis监控解决方案。通过这种方式,你可以获取到详细的性能指标,并根据需求设置报警规则。 6. Elastic Stack (Elasticsearch, Logstash, Kibana)...
配置Zabbix监控Redis的方案一:使用Zabbix内置的Redis监控模板。Zabbix提供了现成的Redis监控模板,包含了各种关键性能指标,如内存使用、命令执行速率、连接数等。步骤如下: 1. 在Zabbix服务器上安装Redis监控所需...
该项目是一款基于Java和前端技术的Redis监控与故障转移解决方案源码,包含810个文件,其中包含201个CSS文件、148个PNG图片、145个Java源文件、96个JavaScript文件、88个GIF图片、45个XML文件、20个属性文件、18个...
Redis是一款高性能的键值数据库,常用于数据缓存、消息队列等场景。在大型分布式系统中,为了保证高可用性和可扩展性,通常会采用Redis...因此,对于任何使用Redis集群的企业或项目,都应当重视并配备相应的监控方案。
Grafana提供了丰富的仪表板模板,可以快速创建展示MySQL和Redis监控的图表。 4. **监控指标**:通过Prometheus和Grafana,你可以监控MySQL和Redis的CPU使用率、内存使用量、QPS(每秒查询数)、延迟、连接数等关键...
首先,我们需要在Zabbix服务器上安装相应的Redis监控插件。在本例中提到的是"redis4bix",它模仿了"db4bix"插件的模式,用于收集Redis的数据。安装过程通常包括以下几个步骤: 1. **下载和解压插件**:获取"redis4...
"Ecology&Emessage&Emobile集群+redis部署方案"就是一个这样的实践,它涵盖了生态系统建设、消息服务、移动应用以及Redis缓存的集成部署。接下来,我们将深入探讨这个方案中的核心知识点。 首先,"Ecology"在这里指...
2. **Redis监控指标**: 对于Redis,常见的监控指标包括但不限于: - 连接数(`INFO clients`) - 内存使用情况(`INFO memory`) - 操作命令统计(`INFO commandstats`) - 数据库键值数量(`INFO keyspace`)...
哨兵是Redis提供的高可用解决方案的一部分,它负责监控Redis服务器的状态,并在主服务器出现故障时自动进行故障转移操作,确保服务的持续可用性。 **3.1 安装与配置** 哨兵本身也是Redis的一个组件,但需要独立...
在本文中,我们将探讨如何构建一个自定义的Redis监控系统。 首先,我们可以利用开源工具redis-stat来获取基础的监控信息。然而,为了满足更复杂的需求,我们需要解析Redis的INFO命令输出,从中提取关键数据,以实现...
监控Redis的负载和性能,根据需要调整配置参数。 这种Session共享方案的优势在于,Redis作为一个中心化的Session存储,减少了服务器之间的通信开销,提高了系统的可扩展性。同时,由于Redis支持多线程访问,因此在...
5. **故障恢复与高可用**: Codis通过心跳检测机制监控各个组件的状态,当检测到某个Redis实例失效时,会自动将流量切换到其他健康的节点,保证服务的连续性。同时,Zookeeper或Etcd的集群特性也提供了冗余和故障...
### Redis主备部署方案详解 #### 一、概述 Redis是一种高性能的键值存储系统,在很多应用场景中都需要保证数据的高可用性和持久性。为了达到这一目标,通常会采用主备复制的方式部署Redis,以此来确保即使在主节点...
这款工具提供了一种免费且高效的解决方案,用于管理和监控 Redis 以及 memcached 的运行状态。在 v1.7.5 版本中,TreeNMS 带来了多项增强功能和优化,以提升用户体验和系统的稳定性。 **Redis 管理** Redis 是一个...
Redis 两主部署高可用性解决方案 Redis 作为一个高性能的 NoSQL 数据库,广泛应用于各种行业的数据存储和缓存中。然而,Redis 的高可用性是企业级应用的关键所在。因此,本文将详细介绍 Redis 两主部署的实现方案,...