网站建设项目组织结构图,网站开发 cms,物业公司网站建设方案,重庆保姆网1、理解Redis监控
Redis运维和监控的意义不言而喻#xff0c;可以以下三个方面入手
1.首先是Redis自身提供了哪些状态信息#xff0c;以及有哪些常见的命令可以获取Redis的监控信息;
2.一些常见的UI工具可以可视化的监控Redis;
3.理解Redis的监控体系;2、Redis自身状态及命…1、理解Redis监控
Redis运维和监控的意义不言而喻可以以下三个方面入手
1.首先是Redis自身提供了哪些状态信息以及有哪些常见的命令可以获取Redis的监控信息;
2.一些常见的UI工具可以可视化的监控Redis;
3.理解Redis的监控体系;2、Redis自身状态及命令
状态信息 - info Redis提供的INFO命令不仅能够查看实时的吞吐量(ops/sec)还能看到一些有用的运行时信息。
127.0.0.1:6379 info
# Server
redis_version:3.2.3 #redis版本号
redis_git_sha1:00000000 #git sha1摘要值
redis_git_dirty:0 #git dirty标识
redis_build_id:443e50c39cbcdbe0 #redis构建id
redis_mode:standalone #运行模式standalone、sentinel、cluster
os:Linux 3.10.0-514.16.1.el7.x86_64 x86_64 #服务器宿主机操作系统
arch_bits:64 服务器宿主机CUP架构32位/64位
multiplexing_api:epoll #redis IO机制
gcc_version:4.8.5 #编译 redis 时所使用的 GCC 版本
process_id:1508 #服务器进程的 PID
run_id:b4ac0f9086659ce54d87e41d4d2f947e19c28401 #redis 服务器的随机标识符 用于 Sentinel 和集群
tcp_port:6380 #redis服务监听端口
uptime_in_seconds:520162 #redis服务启动以来经过的秒数
uptime_in_days:6 #redis服务启动以来经过的天数
hz:10 #redis内部调度进行关闭timeout的客户端删除过期key等等频率程序规定serverCron每秒运行10次
lru_clock:16109450 #自增的时钟用于LRU管理,该时钟100ms(hz10,因此每1000ms/10100ms执行一次定时任务)更新一次
executable:/usr/local/bin/redis-server
config_file:/data/redis-6380/redis.conf 配置文件的路径# Clients
connected_clients:2 #已连接客户端的数量不包括通过从属服务器连接的客户端
client_longest_output_list:0 #当前连接的客户端当中最长的输出列表
client_biggest_input_buf:0 #当前连接的客户端当中最大输入缓存
blocked_clients:0 #正在等待阻塞命令BLPOP、BRPOP、BRPOPLPUSH的客户端的数量# Memory
used_memory:426679232 #由 redis 分配器分配的内存总量以字节byte为单位
used_memory_human:406.91M #以可读的格式返回 redis 分配的内存总量实际是used_memory的格式化
used_memory_rss:443179008 #从操作系统的角度返回 redis 已分配的内存总量俗称常驻集大小。这个值和 top 、 ps等命令的输出一致
used_memory_rss_human:422.65M # redis 的内存消耗峰值(以字节为单位)
used_memory_peak:426708912
used_memory_peak_human:406.94M
total_system_memory:16658403328
total_system_memory_human:15.51G
used_memory_lua:37888 # Lua脚本存储占用的内存
used_memory_lua_human:37.00K
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:1.04 # used_memory_rss/ used_memory
mem_allocator:jemalloc-4.0.3# Persistence
loading:0 #服务器是否正在载入持久化文件0表示没有1表示正在加载
rdb_changes_since_last_save:3164272 #离最近一次成功生成rdb文件写入命令的个数即有多少个写入命令没有持久化
rdb_bgsave_in_progress:0 #服务器是否正在创建rdb文件0表示否
rdb_last_save_time:1559093160 #离最近一次成功创建rdb文件的时间戳。当前时间戳 - rdb_last_save_time多少秒未成功生成rdb文件
rdb_last_bgsave_status:ok #最近一次rdb持久化是否成功
rdb_last_bgsave_time_sec:-1 #最近一次成功生成rdb文件耗时秒数
rdb_current_bgsave_time_sec:-1 #如果服务器正在创建rdb文件那么这个域记录的就是当前的创建操作已经耗费的秒数
aof_enabled:0 #是否开启了aof
aof_rewrite_in_progress:0 #标识aof的rewrite操作是否在进行中
aof_rewrite_scheduled:0 #rewrite任务计划当客户端发送bgrewriteaof指令如果当前rewrite子进程正在执行那么将客户端请求的bgrewriteaof变为计划任务待aof子进程结束后执行rewrite
aof_last_rewrite_time_sec:-1 #最近一次aof rewrite耗费的时长
aof_current_rewrite_time_sec:-1 #如果rewrite操作正在进行则记录所使用的时间单位秒
aof_last_bgrewrite_status:ok #上次bgrewriteaof操作的状态
aof_last_write_status:ok #上次aof写入状态# Stats
total_connections_received:10 #服务器已经接受的连接请求数量
total_commands_processed:9510792 #redis处理的命令数
instantaneous_ops_per_sec:1 #redis当前的qpsredis内部较实时的每秒执行的命令数
total_net_input_bytes:1104411373 #redis网络入口流量字节数
total_net_output_bytes:66358938 #redis网络出口流量字节数
instantaneous_input_kbps:0.04 #redis网络入口kps
instantaneous_output_kbps:3633.35 #redis网络出口kps
rejected_connections:0 #拒绝的连接个数redis连接个数达到maxclients限制拒绝新连接的个数
sync_full:0 #主从完全同步成功次数
sync_partial_ok:0 #主从部分同步成功次数
sync_partial_err:0 #主从部分同步失败次数
expired_keys:0 #运行以来过期的key的数量
evicted_keys:0 #运行以来剔除(超过了maxmemory后)的key的数量
keyspace_hits:87 #命中次数
keyspace_misses:17 #没命中次数
pubsub_channels:0 #当前使用中的频道数量
pubsub_patterns:0 #当前使用的模式的数量
latest_fork_usec:0 #最近一次fork操作阻塞redis进程的耗时数单位微秒
migrate_cached_sockets:0 #是否已经缓存了到该地址的连接# Replication
role:master #实例的角色是master or slave
connected_slaves:0 #连接的slave实例个数
master_repl_offset:0 #主从同步偏移量,此值如果和上面的offset相同说明主从一致没延迟与master_replid可被用来标识主实例复制流中的位置
repl_backlog_active:0 #复制积压缓冲区是否开启
repl_backlog_size:1048576 #复制积压缓冲大小
repl_backlog_first_byte_offset:0 #复制缓冲区里偏移量的大小
repl_backlog_histlen:0 #此值等于 master_repl_offset - repl_backlog_first_byte_offset,该值不会超过repl_backlog_size的大小# CPU
used_cpu_sys:507.00 #将所有redis主进程在核心态所占用的CPU时求和累计起来
used_cpu_user:280.48 #将所有redis主进程在用户态所占用的CPU时求和累计起来
used_cpu_sys_children:0.00 #将后台进程在核心态所占用的CPU时求和累计起来
used_cpu_user_children:0.00 #将后台进程在用户态所占用的CPU时求和累计起来# Cluster
cluster_enabled:0# Keyspace
db0:keys5557407,expires362,avg_ttl604780497
db15:keys1,expires0,avg_ttl0查看某个section的信息
127.0.0.1:6379 info memory
# Memory
used_memory:1067440
used_memory_human:1.02M
used_memory_rss:9945088
used_memory_rss_human:9.48M
used_memory_peak:1662736
used_memory_peak_human:1.59M
total_system_memory:10314981376
total_system_memory_human:9.61G
used_memory_lua:37888
used_memory_lua_human:37.00K
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
mem_fragmentation_ratio:9.32
mem_allocator:jemalloc-4.0.3监控执行命令 - monitor monitor用来监视服务端收到的命令。有一定的性能损耗但是个人认为是值得的。
127.0.0.1:6379 monitor
OK
1616045629.853032 [10 192.168.0.101:37990] PING
1616045629.858214 [10 192.168.0.101:37990] PING
1616045632.193252 [10 192.168.0.101:37990] EXISTS test_key_from_app
1616045632.193607 [10 192.168.0.101:37990] GET test_key_from_app
1616045632.200572 [10 192.168.0.101:37990] SET test_key_from_app 1616045625017
1616045632.200973 [10 192.168.0.101:37990] SET test_key_from_app 16160456226213、Redis可视化监控工具
只能可视化指标不能监控 redis-stat、RedisLive、redmon 等工具。 用于生产环境 基于redis_exporter以及grafana可以做到指标可视化持久化监控以及报警等。
redis-stat 是一个比较有名的redis指标可视化的监控工具采用ruby开发基于redis的info和monitor命令来统计不影响redis性能。
它提供了命令行彩色控制台展示模式 和web模式 RedisLive 采用python开发的redis的可视化及查询分析工具。
docker运行
docker run --name redis-live -p 8888:8888 -d snakeliwei/redislive访问http://192.168.99.100:8888/index.html
redmon redmon提供了cli、admin的web界面同时也能够实时监控redis。
docker运行
docker run -p 4567:4567 -d vieux/redmon -r redis://192.168.99.100:6379监控 cli 动态更新配置 redis_exporter redis_exporter在新窗口打开为Prometheus提供了redis指标的exporter支持Redis 2.x, 3.x, 4.x, 5.x, and 6.x配合Prometheus以及grafana的Prometheus Redis插件可以在grafana进行可视化及监控
二、redis的监控体系
redis这类敏感的纯内存、高并发和低延时的服务一套完善的监控告警方案是精细化运营的前提。
什么样的场景会用到redis监控体系 一个大型系统引入了Redis作为缓存中间件
1.部署架构采用Redis-Cluster模式;
2.后台应用系统有几十个应用实例数超过二百个;
3.所有应用系统共用一套缓存集群;
4.集群节点数几十个加上容灾备用环境节点数量翻倍;
5.集群节点内存配置较高。Redis监控体系具备什么价值
1.redis故障快速通知定位故障点
2.分析redis故障的Root cause。//任何一个故障和性能问题其根本“诱因”往往只有一个称为这个故障的Root cause
3.redis容量规划和性能管理
4.redis硬件资源利用率和成本
