做企业网站要哪些人员,网上销售推广方案,装潢设计哪里可以学,宽屏网站和普通网站对于任何应用服务和组件#xff0c;都需要一套完善可靠谱监控方案。尤其redis这类敏感的纯内存、高并发和低延时的服务#xff0c;一套完善的监控告警方案#xff0c;是精细化运营的前提。本文分几节#xff0c;细说Redis的监控和告警#xff1a;1.Redis监控告警的价值2.R… 对于任何应用服务和组件都需要一套完善可靠谱监控方案。尤其redis这类敏感的纯内存、高并发和低延时的服务一套完善的监控告警方案是精细化运营的前提。本文分几节细说Redis的监控和告警1.Redis监控告警的价值2.Redis监控的数据采集3.Redis告警策略4.基于Open Falcon的Redis监控告警方案 Redis监控告警的价值 Redis监控告警的价值对每个角色都不同重要的几个方面 redis故障快速通知定位故障点对于DBAredis的可用性和性能故障需快速发现和定位解决。分析redis故障的Root causeredis容量规划和性能管理redis硬件资源利用率和成本 redis故障快速发现定位故障点和解决故障 当redis出现故障时DBA应在尽可能短时间内发现告警如果故障对服务是有损的(如大面积网络故障或程序BUG)需立即通知SRE和RD启用故障预案(如切换机房或启用emergency switch止损。如果没完善监控告警;假设由RD发现服务故障再排查整体服务调用链去定位甚于用户发现用问题通过客服投诉再排查到redis故障的问题整个redis故障的发现、定位和解决时间被拉长把一个原本的小故障被”无限”放大。 分析redis故障的Root cause 任何一个故障和性能问题其根本“诱因”往往只有一个称为这个故障的Root cause。一个故障从DBA发现、止损、分析定位、解决和以后规避措施最重要一环就是DBA通过各种问题表象层层分析到Root cause找到问题的根据原因才能根治这类问题避免再次发生。完善的redis监控数据是我们分析root cause的基础和证据。 备注Troubleshtooing定位Root cause就像医生通过病人的病历和检查报告找到“真正的病灶”让病人康复和少受苦一样有意思和复杂或像刑警通过案件的证据分析和推理寻找那个唯一的真相一样惊心动魄。(快看DBA又在吹牛了其实在大型商业系统中一次故障轻松就达直接损失数十万间接损失更大那“抓住元凶”避免它再次“作案”同样是“破案”。 问题表现是综合情的一般可能性较复杂这里举2个例子 服务调用Redis响应时间变大的性能总是可能网络问题redis慢查询redis QPS增高达到性能瓶颈redis fork阻塞和请求排队redis使用swap, cpu达到饱和(单核idle过低),aof fsync阻塞网络进出口资源饱和等等redis使用内存突然增长快达到maxmemory; 可能其个大键写入键个数增长某类键平均长度突增fork COW, 客户端输入/输出缓冲区,lua程序占用等等 Root cause是要直观的监控数据和证据而非有技术支撑的推理分析。 redis响应抖动分析定位root casue是bgsave时fork导致阻塞200ms的例子。而不是分析推理redis进程rss达30gb,响应抖动时应该有同步fork子进程时页表拷贝时要阻塞父进程估计页表大小xx再根据内存copy连续1m数据要xx 纳秒分析出可能fork阻塞导致的。要的不是这种分析 说明粮厂有个习惯在分析root cause尽量能拿到直观证据。因为一旦引入推理步骤每一步的推理结果都可能出现偏差最终可能给出错误root cause. “元凶”又逃过一劫它下次作案估计就会更大。所以建议任何小的故障或抖动至少从个人或小组内部深入分析找到root cause这样个人或组织都会成长快 形成良好的氛围。 Redis容量规划和性能管理 通过分析redis资源使用和性能指标的监控历史趋势数据对集群进行合理扩容(Scale-out)、缩容(Scale-back)对性能瓶颈优化处理等。Redis资源使用饱和度监控设置合理阀值一些常用容量指标redis内存使用比例swap使用cpu单核的饱和度等当资源使用容量预警时能及时扩容避免因资源使用过载导致故障。另一方面如果资源利用率持续过低及时通知业务并进行redis集群缩容处理避免资源浪费。进一步容器化管理redis后根据监控数据系统能自动地弹性扩容和缩容。 Redis性能监控管理及时发现性能瓶颈进行优化或扩容把问题扼杀在”萌芽期“避免它”进化“成故障。 Redis硬件资源利用率和成本 从老板角度来看最关心的是成本和资源利用率是否达标。如果资源不达标就得推进资源优化整合提高硬件利用率减少资源浪费。砍预算减成本。资源利用率是否达标的数据都是通过监控系统采集的数据。 这一小节扯了这么多 只是强调redis不是只有一个端口存活监控就可以了。下面进入主题怎么采集redsis监控数。 老板曾说监控告警和数据备份是对DBA和SRE最基础也是最高的要求当服务和存储达到产品规模后可认为“无监控不服务无备份不存储”。 Redis监控数据采集 redis监控的数据采集数据采集1分钟一次分为下面几个方面 服务器系统数据采集Redis Server数据采集Redis响应时间数据采集Redis监控Screen 服务器系统监控数据采集 服务器系统的数据采集这部分包含数百个指标. 采集方式现在监控平台自带的agent都会支持如Zabbix和Open Falcon等这里就不介绍采集方法。 我们从redis使用资源的特性分析各个子系统的重要监控指标。 服务器存活监控 ping监控告警 CPU 平均负载(Load Average): 综合负载指标(暂且归类cpu子系统)当系统的子系统出现过度使用时平均负载会升高。可说明redis的处理性能下降(平均响应时间变长、吞吐量降低)。CPU整体利用率或饱和度(cpu.busy): redis在高并发或时间复杂度高的指令cpu整体资源饱和导致redis性能下降请求堆积。CPU单核饱和度(cpu.core.idle/core0): redis是单进程模式常规情况只使用一个cpu core, 单某个实例出现cpu性能瓶颈导致性能故障但系统一般24线程的cpu饱和度却很低。所以监控cpu单核心利用率也同样重样。CPU上下文切换数(cpu.switches)context swith过高xxxxxx 内存和swap 系统内存余量大小(mem.memfree)redis是纯内存系统系统内存必须保有足够余量避免出现OOM导致redis进程被杀或使用swap导致redis性能骤降。系统swap使用量大小(mem.swapused)redis的”热数据“只要进入swap,redis处理性能就会骤降 不管swap分区的是否是SSD介质。OS对swap的使用材质还是disk store. 这也是作者早期redis实现VM,后来又放弃的原因。 说明系统内存余量合理给各种缓冲区fork cow足够的内存空间。另一个问题我的系统使用Redis缓存集群”不怕挂就怕慢“或redis集群高可用做得厉害这样redis的服务器是否能关闭swap呢 磁盘 磁盘分区的使用率df.bytes.used.percent)磁盘空间使用率监控告警确保有足磁盘空间用AOF/RDB, 日志文件存储。不过 redis服务器一般很少出现磁盘容量问题磁盘IOPS的饱和度(disk.io.util)如果有AOF持久化时要注意这类情况。如果AOF持久化每秒sync有堆积可能导致写入stall的情况。 另外磁盘顺序吞吐量还是很重要太低会导致复制同步RDB时拉长同步RDB时间。期待diskless replication 网络 网络吞吐量饱和度(net.if.out.bytes/net.if.in.bytes)如果服务器是千兆网卡Speed: 1000Mb/s单机多实例情况有异常的大key容量导致网卡流量打滿。redis整体服务等量下降苦于出现故障切换。丢包率Redis服务响应质量受影响 Redis Server监控数据采集 通过redis实例的状态数据采集采集监控数据的命令ping,info all, slowlog get/len/reset/cluster info/config get Redis存活监控 redis存活监控(redis_alive):redis本地监控agent使用ping如果指定时间返回PONG表示存活否则redis不能响应请求可能阻塞或死亡。redis uptime监控(redis_uptime)uptime_in_seconds Redis 连接数监控 连接个数(connected_clients)客户端连接个数如果连接数过高影响redis吞吐量。常规建议不要超过5000.参考官方benchmarks连接数使用率(connected_clients_pct): 连接数使用百分比通过(connected_clients/macclients)计算如果达到1redis开始拒绝新连接创建。 123127.0.0.1:6380 set mykey myvalue(error) ERR max number of clients reached127.0.0.1:6380 拒绝的连接个数(rejected_connections): redis连接个数达到maxclients限制拒绝新连接的个数。新创建连接个数(total_connections_received): 如果新创建连接过多过度地创建和销毁连接对性能有影响说明短连接严重或连接池使用有问题需调研代码的连接设置。list阻塞调用被阻塞的连接个数(blocked_clients): BLPOP这类命令没使用过如果监控数据大于0还是建议排查原因。 Redis内存监控 redis分配的内存大小(used_memory): redis真实使用内存不包含内存碎片单实例的内存大小不建议过大常规10~20GB以内。redis内存使用比例(used_memory_pct): 已分配内存的百分比通过(used_memory/maxmemory)计算对于redis存储场景会比较关注未设置淘汰策略(maxmemory_policy)的达到maxmemory限制不能写入数据。 123127.0.0.1:6380 set mykey myvalue(error) OOM command not allowed when used memory maxmemory.127.0.0.1:6380 redis进程使用内存大小(used_memory_rss): 进程实际使用的物理内存大小包含内存碎片如果rss过大导致内部碎片大内存资源浪费和fork的耗时和cow内存都会增大。redis内存碎片率(mem_fragmentation_ratio): 表示(used_memory_rss/used_memory)碎片率过大导致内存资源浪费 说明1、如果内存使用很小时mem_fragmentation_ratio可以远大于1的情况这个告警值不好设置需参考used_memory大小。2、如果mem_fragmentation_ratio小于1表示redis已使用swap分区 Redis综合性能监控 Redis Keyspace redis键空间的状态监控 键个数(keys): redis实例包含的键个数。建议控制在1kw内单实例键个数过大可能导致过期键的回收不及时。设置有生存时间的键个数(keys_expires): 是纯缓存或业务的过期长都建议对键设置TTL; 避免业务的死键问题. expires字段估算设置生存时间键的平均寿命(avg_ttl): redis会抽样估算实例中设置TTL键的平均时长单位毫秒。如果无TTL键或在Slave则avg_ttl一直为0LRU淘汰的键个数(evicted_keys): 因used_memory达到maxmemory限制并设置有淘汰策略的实例对排查问题重要可不设置告警过期淘汰的键个数(expired_keys): 删除生存时间为0的键个数包含主动删除和定期删除的个数。 Redis qps redis处理的命令数(total_commands_processed): 监控采集周期内的平均qps,redis单实例处理达数万如果请求数过多redis过载导致请求堆积。redis当前的qps(instantaneous_ops_per_sec): redis内部较实时的每秒执行的命令数可和total_commands_processed监控互补。 Redis cmdstat_xxx 这小节讲解redis记录执行过的所有命令 通过info all的Commandstats节采集数据. 每类命令执行的次数(cmdstat_xxx): 这个值用于分析redis抖动变化比较有用 以下表示每个命令执行次数总共消耗的CPU时长(单个微秒)平均每次消耗的CPU时长单位微秒 1234# Commandstatscmdstat_set:calls6,usec37,usec_per_call6.17cmdstat_lpush:calls4,usec32,usec_per_call8.00cmdstat_lpop:calls4,usec33,usec_per_call8.25 Redis Keysapce hit ratio redis键空间请求命中率监控通过此监控来度量redis缓存的质量如果未命中率或次数较高可能因热点数据已大于redis的内存限制导致请求落到后端存储组件可能需要扩容redis缓存集群的内存容量。当然也有可能是业务特性导致。 请求键被命中次数(keyspace_hits): redis请求键被命中的次数请求键未被命中次数(keyspace_misses): redis请求键未被命中的次数当命中率较高如95%如果请求量大未命中次数也会很多。可参考Baron大神写的Why you should ignore MySQL’s key cache hit ratio请求键的命中率(keyspace_hit_ratio):使用keyspace_hits/(keyspace_hitskeyspace_misses)计算所得是度量Redis缓存服务质量的标准 Redis fork redis在执行BGSAVE,BGREWRITEAOF命令时redis进程有fork操作。而fork会对redis进程有个短暂的卡顿,这个卡顿redis不能响应任务请求。所以监控fork阻塞时长是相当重要。如果你的系统不能接受redis有500ms的阻塞那么就要监控fork阻塞时长的变化做好容量规划。 最近一次fork阻塞的微秒数(latest_fork_usec): 最近一次Fork操作阻塞redis进程的耗时数单位微秒。 redis network traffic redis一般单机多实例部署当服务器网络流量增长很大需快速定位是网络流量被哪个redis实例所消耗了 另外redis如果写流量过大可能导致slave线程“客户端输出缓冲区”堆积达到限制后被Maser强制断开连接出现复制中断故障。所以我们需监控每个redis实例网络进出口流量设置合适的告警值。 说明网络监控指标 需较高的版本才有应该是2.8.2x以后 redis网络入口流量字节数(total_net_input_bytes)redis网络出口流量字节数(total_net_output_bytes)redis网络入口kpsinstantaneous_input_kbpsredis网络出口kps(instantaneous_output_kbps) 前两者是累计值根据监控平台1个采集周期(如1分钟)内平均每秒的流量字节数。 Redis慢查询监控 redis慢查询是排查性能问题关键监控指标。因redis是单线程模型(single-threaded server),即一次只能执行一个命令如果命令耗时较长其他命令就会被阻塞进入队列排队等待这样对程序性能会较大。redis慢查询保存在内存中最多保存slowlog-max-len(默认128个慢查询命令当慢查询命令日志达到128个时新慢查询被加入前会删除最旧的慢查询命令。因慢查询不能持久化保存且不能实时监控每秒产生的慢查询个数。我们建议的慢查询监控方法 设置合理慢查询日志阀值,slowlog-log-slower-than, 建议1ms(如果平均1ms, redis qps也就只有1000)设置全理慢查询日志队列长度slowlog-max-len建议大于1024个因监控采集周期1分钟建议避免慢查询日志被删除另外慢查询的参数过多时会被省略对内存消耗很小每次采集使用slowlog len获取慢查询日志个数每次彩集使用slowlog get 1024 获取所慢查询并转存储到其他地方如MongoDB或MySQL等方便排查问题并分析当前慢查询日志最长耗时微秒数。然后使用slowlog reset把慢查询日志清空下个采集周期的日志长度就是最新产生的。 redis慢查询的监控项 redis慢查询日志个数slowlog_len):每个采集周期出现慢查询个数如1分钟出现10次大于1ms的慢查询redis慢查询日志最长耗时值(slowlog_max_time)获取慢查询耗时最长值因有的达10秒以下的慢查询可能导致复制中断甚至出来主从切换等故障。 Redis持久化监控 redis存储场景的集群就得redis持久化保障数据落地减少故障时数据丢失。这里分析redis rdb数据持久化的几个监控指标。 最近一次rdb持久化是否成功(rdb_last_bgsave_status):如果持久化未成功建议告警说明备份或主从复制同步不正常。或redis设置有”stop-writes-on-bgsave-error”为yes当save失败后会导致redis不能写入操作最近一次成功生成rdb文件耗时秒数(rdb_last_bgsave_time_sec):rdb生成耗时反应同步时数据是否增长 如果远程备份使用redis-cli –rdb方式远程备份rdb文件时间长短可能影响备份线程客户端输出缓冲内存使用大小。离最近一次成功生成rdb文件写入命令的个数rdb_changes_since_last_save):即有多少个写入命令没有持久化最坏情况下会丢失的写入命令数。建议设置监控告警离最近一次成功rdb持久化的秒数(rdb_last_save_time): 最坏情况丢失多少秒的数据写入。使用当前时间戳 - 采集的rdb_last_save_time(最近一次rdb成功持久化的时间戳)计算出多少秒未成功生成rdb文件 Redis复制监控 不论使用何种redis集群方案redis复制都会被使用。 复制相关的监控告警项 redis角色(redis_role):实例的角色是master or slave复制连接状态(master_link_status): slave端可查看它与master之间同步状态当复制断开后表示down,影响当前集群的可用性。需设置监控告警。复制连接断开时间长度(master_link_down_since_seconds):主从服务器同步断开的秒数建议设置时长告警。主库多少秒未发送数据到从库(master_last_io_seconds):如果主库超过repl-timeout秒未向从库发送命令和数据会导致复制断开重连。详细分析见文章Redis复制中断和无限同步问题。 在slave端可监控建议设置大于10秒告警从库多少秒未向主库发送REPLCONF命令(slave_lag): 正常情况从库每秒都向主库发送REPLCONF ACK命令如果从库因某种原因未向主库上报命令主从复制有中断的风险。通过在master端监控每个slave的lag值。从库是否设置只读(slave_read_only)从库默认只读禁止写入操作监控从库只读状态如果关闭从库只读有写入数据风险。关于主从数据不一致,见文章分析 Redis复制主从数据不-致主库挂载的从库个数(connected_slaves):主库至少保证一个从库不建议设置超过2个从库。复制积压缓冲区是否开启(repl_backlog_active):主库默认开启复制积压缓冲区用于应对短时间复制中断时使用部分同步方式。复制积压缓冲大小(repl_backlog_size):主库复制积压缓冲大小默认1MB,因为是redis server共享一个缓冲区建议设置100MB. 说明 关于根据实际情况设置合适大小的复制缓冲区。可以通过master_repl_offset指标计算每秒写入字节数同时乘以希望多少秒内闪断使用“部分同步”方式。 Redis集群监控 这里所写redis官方集群方案的监控指标数据基本通过cluster info和info命令采集。 实例是否启用集群模式(cluster_enabled): 通过info的cluster_enabled监控是否启用集群模式。集群健康状态clusster_state):如果当前redis发现有failed的slots默认为把自己cluster_state从ok个性为fail, 写入命令会失败。如果设置cluster-require-full-coverage为NO,则无此限制。集群数据槽slots分配情况(cluster_slots_assigned):集群正常运行时默认16384个slots检测下线的数据槽slots个数(cluster_slots_fail):集群正常运行时应该为0. 如果大于0说明集群有slot存在故障。集群的分片数(cluster_size集群中设置的分片个数集群的节点数cluster_known_nodes集群中redis节点的个数 Redis响应时间监控 响应时间是衡量一个服务组件性能和质量的重要指标。使用redis的服务通常对响应时间都十分敏感比如要求99%的响应时间达10ms以内。因redis的慢查询日志只计算命令的cpu占用时间不会考虑排队或其他耗时。 最长响应时间respond_time_max):最长响应时间的毫秒数99%的响应时间长度(respond_time_99_max):99%的平均响应时间长度(respond_time_99_avg):95%的响应时间长度respond_time_95_max):95%的平均响应时间长度(respond_time_95_avg): 响应时间监控的方式建议最简单方法使用Percona tcprstat 原文地址https://zhuoroger.github.io/2016/08/20/redis-monitor-and-alarm/ .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
