同创永益

同创永益 查看完整档案

北京编辑  |  填写毕业院校北京同创永益发展有限公司  |  运营 编辑 www.hatech.com.cn 编辑
编辑

同创永益,面向未来的组织韧性服务提供商

个人动态

同创永益 发布了文章 · 4月15日

干货丨Zabbix 源码解析之监控项数据采集流程

转自@twt社区,作者:张帆

一、概述

监控项数据采集是一个监控工具最基本的功能,监控数据采集的准确、实时、有效是Zabbix其它监控功能正常运转的前提。因此,Zabbix运维人员有必要了解监控项数据采集流程,并有针对性的设计巡检和问题处理流程,确保监控数据质量。

Zabbix 的监控采集类型很丰富,我最常用的是Agent方式,因此,就挑选Linux的内存监控(Zabbix内置key:vm.memory.size)为例来梳理一下监控项数据采集流程。

二、程序流程图

下图是我们梳理的vm.memory.size监控项采集流程图,数据采集的过程设计得缜密而复杂:
image.png

下面,我们将对主要流程和具体实现进行解析,涉及函数的具体实现解析写在了代码注释中。

三、相关数据结构定义

在介绍vm.memory.size具体实现之前,我们先介绍几个相关数据结构的定义。

(1)struct ZBXMETRIC

该结构体用于记录zabbix的监控项配置信息

image.png

(2) struct AGENTREQUEST

该结构体用于记录zabbix Agent的监控项请求信息
image.png

(3) struct AGENTRESULT

该结构体用于记录给zabbix Agent返回的采集数据

image.png

四、监控项vm.memory.size配置

用法: vm.memory.size[]

mode参数:

•total (*) - 总物理内存. mode的默认值

•free (*) - 可用内存.

•active - 内存当前使用或最近使用,它在RAM中是活跃的。

•inactive - 未使用内存.

•wired - 被标记为始终驻留在RAM中的内存,不会移动到磁盘。

•pinned - 同“wired”。

•anon - 与文件无关的内存(不能重新读取)。

•exec - 可执行代码,通常来自于一个(程序)文件。

•file - 缓存最近访问文件的目录。

•buffers (*) - 缓存磁盘读写数据。

•cached (*) - 缓存文件系统读写数据。

•shared - 可以同时被多个进程访问的内存。

•used (*) - 已使用内存。

•pused (*) - 已使用内存占总内存的百分比。

•available (*) - 可用内存

•pavailable (*) - 可用内存占总内存的百分比。

假如我们在某Host下定义了2个item:

Item1:Total memory Key1:vm.memory.size[total]

Item2:Available memory Key2:vm.memory.size[available]

这2个item就会被insert到Server数据库的items表中,这样该Host的Agent就可以获取到相应的采集任务了(获取流程本文不具体阐述),下面我们来重点看下vm.memory.size的采集实现和数据上送。

image.png

五、监控项vm.memory.size 采值实现

vm.memory.size监控项在不同的操作系统下实现各不相同,Linux系统下的实现,在src/libs/zbxsysinfo/linux/linux.c中。其配置项存放于parameters_specific数组中,可以看到对应的实现函数为VM_MEMORY_SIZE,

image.png

  1. VM_MEMORYSIZE函数 (位置在:src/libs/zbxsysinfo/linux/memory.c)

用来接受参数,并对应调用对应的取值函数进行数据采集,并返回数据。

具体实现如下:

image.png

从源码中可以看到,Linux系统支持的模式包括如下参数,与官方文档中所列的参数不同。

•total

•free

•buffers

•used

•pused

•available

•pavailable

•shared

•cached

•active

•anon

•inactive

•slab

通过分析各个参数对应的取值逻辑,可分为2种方法:

•第一种:调用sysinfo函数获取指标值。通过这种方式获取的选项参数有:total,free,buffers,used,pused,pavailable,shared。

•第二种:读取/proc/meminfo文件中的指标值。通过这种方式获取的选项参数有:available,cached,active,anon,inactive,slab。

下面我们分别对两种情况进行分析。

(1)调用sysinfo函数

Linux中sysinfo()函数是用来获取系统相关统计信息的函数。它会将结果存储在struct sysinfo结构体中。
image.png

函数声明:

int sysinfo(struct sysinfo *info);

struct sysinfo的定义如下:
image.png

total,free,buffers,used,pused,pavailable,shared等指标,都是以struct sysinfo中的成员的取值来计算的。

• total:info.totalram * info.mem_unit

• free:info.freeram * info.mem_unit

• buffers:info.bufferram * info.mem_unit

• used:(info.totalram - info.freeram) * info.mem_unit

• pused:(info.totalram - info.freeram) / (double)info.totalram * 100

• pavailable:available / (info.totalram info.mem_unit) 100(available在/proc/meminfo文件中读出)

• shared:info.sharedram * info.mem_unit(仅Linux 2.4)

(2) 读取/proc/meminfo文件

该功能在VM_MEMORY_PROC_MEMINFO函数中实现。向meminfo_entry参数传递"Cached:", "Active:", "AnonPages:", "Inactive:", "Slab:"字段。

其中available的获取比较特殊,它先检测/proc/meminfo文件文件中是否有"MemAvailable:"字段,如果没有,则再调用sysinfo函数获取。

具体实现如下:
image.png
image.png
image.png
image.png

六、监控项vm.memory.size 数据上送

前面解析的监控项的采值逻辑,下面我们来分析数据从Agent端上送到Server的过程。

介绍几个相关的函数:

1.init_metrics函数

vm.memory.size监控项会被存储到parameters_specific数组中。那么parameters_specific数组在哪儿被使用到呢?就在init_metrics函数中。

init_metrics函数在zabbix Server和zabbix Agent启动的过程中都被调用了,因此这些监控项在zabbix启动时已经被设置好了。

image.png

2.add_metric函数

add_metric函数会向commands数组中添加值。commands是在sysinfo.c中定义的一个ZBX_METRIC结构体变量,初始值是NULL。

image.png

add_metric函数具体实现如下:

image.png

3.process函数

commands数组在哪里被使用到了呢?在process函数中,process函数定义在src/libs/zbxsysinfo/sysinfo.c中。

image.png
image.png
image.png

在process函数中会最终调用监控项实现函数,那process函数在哪被调用到的呢?

在zabbix_agent中,调用process函数的地方有2处,分别位于agent的被动模式和主动模式的实现中。我们分别来分析一下。

(1) 被动模式下的processlistener函数

image.png

(2)主动模式下的processactivechecks函数

  1. 监控项值的序列化与上送

介绍完相关的函数和调用,下面我们可以具体来分析数据上送的过程了

(1)agent与server通信协议

首先是通信协议,agent与server间的通信协议比较简单,其协议格式为:。

• PROTOCOL: 协议头,该字段长度为4个字节,内容为"ZBXD"。

• FLAGS: 协议标志,该字段长度为1个字节。有2个取值(这两个值可以使用“或”操作同时取):

– 0x01:ZBX_TCP_PROTOCOL,zabbix TCP通信协议

– 0x02:ZBX_TCP_COMPRESS,使用压缩算法

• DATALEN: 数据长度,该字段长度为4个字节。整型,以小端模式表示。

– 注意该长度不包含协议头这几个字段的长度,它仅表示DATA字段的数据长度。

• RESERVED: 保留字段,用作协议扩展,字段长度为4字节。当ZBX_TCP_COMPRESS标志被设置后,RESERVED字段会保存未被压缩时的数据段的长度。整型,以小端模式表示。

• DATA: 数据内容,使用JSON格式来序列化。

(2)监控项值的传递

1、我们以主动模式下会被调用的send_buffer函数(zbx_tcp_send()最终会调用到zbx_tcp_send_ext()函数)为例,分析一下监控项值如何发送给server。

被动模式下zbx_tcp_send_to(s, *value, ...)函数最终也会调用到zbx_tcp_send_ext()函数,与主动模式下最终的处理是一致的,我们不再单独分析。

具体实现如下:

image.png
image.png
image.png
image.png
image.png
image.png

根据上面的源码分析结果,可得出agent发送的数据的格式如下:

image.png

2、agent发送数据后,会从server端收到响应数据,响应数据的格式如下:

image.png

在响应数据中,response的状态可以是success或failure。响应数据的检测与解析在check_response函数中操作。

image.png

(3) 数据上送的具体实现

zbx_tcp_send()最终会调用到zbx_tcp_send_ext()函数,agent与server间的通信协议的数据序列化是在zbx_tcp_send_ext()函数中实现的。

![image.png
image.png

image.png
image.png

至此,监控项数据采集流程就解析完了,以上仅供参考,欢迎指正。

查看原文

赞 0 收藏 0 评论 0

同创永益 发布了文章 · 4月12日

干货丨Hadoop MapReduce 作业长时间卡死怎么办?

转自@twt社区,作者:孟洋。

1. 问题描述

当前,我们通过编写Hadoop MapReduce程序对来自上游的源数据文件进行贴源预处理加工。源数据文件发到Hadoop集群后,我们的预处理程序会对源数据进行编码转换、数据去重、加时间拉链、数据清洗、错误数据处理等操作,生成贴源的ODS层数据,供上层建模使用。

一直以来系统运行稳定,未出现过问题。但一段时间以来部分源文件的预处理作业频繁出现作业长时间卡死的问题,导致Hadoop集群资源被长时间占用,其他作业因资源不足而无法正常调起,影响了预处理加工的时效性。对此我们从各方面进行了分析和处理,具体过程如下。

2. 问题分析

2.1. 数据倾斜可能性分析

当问题出现时,我们首先考虑到可能是因为数据倾斜问题导致了作业长时间卡死的现象。于是我们首先检查YARN控制台的作业信息如图2-1:

图2-1 YARN控制台reduce任务运行情况

从上图可以看到有大量的reduce任务长时间运行,而非少部分reduce任务长时间运行。数据倾斜的典型现象是大部分reduce任务执行时间较短,只有很少的reduce任务长时间运行,可以说上图反映的情况与数据倾斜并不完全相符,同时,我们也对MR程序处理的源数据文件进行了按Key值分组计算,发现并未有数据分布不均衡的情况,因此我们排除了因数据倾斜导致作业卡死的可能性。

2.2. Hadoop集群组件状态分析

通过查看Hadoop集群UI页面上各组件状态以及查看NameNode、DataNode、ResouceManager等系统服务日志信息,可以确认集群及各组件没有问题,运行正常,从而排除因集群本身问题导致作业卡死。

2.3. 日志分析

我们发现这些长时间运行的作业都是卡死在reduce阶段,有大量reduce任务卡在27%-30%进度不再运行,如图2-1所示。同时也有部分map任务和reduce任务失败。于是我们查看了该作业的如下日志信息:

1)通过yarn -logs获取的job日志:
image.png

2)job对应的容器日志为如图2-2和图2-3所示

image.png

图2-2 异常作业容器信息1

image.png

图2-3 异常作业容器信息2

3)失败map任务日志:
image.png

图2-4 失败map任务日志

4)失败reduce任务日志:

image.png

图2-5 失败reduce任务日志

5)长时间卡死的reduce任务的syslog日志:
image.png

6)长时间卡死的reduce任务的syslog.shuffle的日志:
image.png
image.png

7)长时间卡死的reduce任务的进程栈

image.png

根据上述日志进行如下分析:

(1)job日志中异常1:[communication thread] org.apache.hadoop.mapred.Task: Communicationexception。这个是任务的一种状态报告机制,当出现异常时会有重试机制(默认为3次)。后续没有出现异常,则说明已恢复正常,不需要关注.

(2)job日志中异常2:[communication thread]org.apache.hadoop.yarn.util.ProcfsBasedProcessTree: Error reading the streamjava.io.IOException: 没有那个进程。出现该异常信息后,任务持续卡住长达11小时,在任务界面上依然是running状态,原因不明。

(3)失败map任务和失败reduce任务日志显示任务超时,容器被killed,对应的进程退出码为143。从UI日志截图显示的任务超过10分钟无响应(对应yarn容器配置中mapreduce.task.timeout=10分钟)而被kill掉。该情况通常发生在任务高并发、IO竞争激烈的场景下,考虑优化超时时间、容器内存配置等参数。但该问题不是导致作业卡死的原因,如果超长reduce任务可以超时被kill也不会出现本文之前描述的情况。

(4)对于长时间卡死的reduce任务的syslog日志中“IOException: 没有那个进程”异常,一般是读取“/proc/meminfo”、“/proc/cpuinfo”等本地文件时出现,正常情况下任何用户都可以访问这些文件,初步诊断为可能是没有更多的文件描述符来打开/proc/下对应进程文件的信息。通过“ulimit -n”查询发现所有的节点配置所有用户对应的打开文件数为100000,在系统繁忙时可能有些偏少,后续考虑提升至150000。但这不是导致作业卡死的原因。

(5)通过查看长时间卡死的reduce任务的syslog.shuffle日志,可以发现对应的shuffle任务在较短的时间内就处理了大量的map结果,但是shuffer任务本身日志中并没有报错,呈现任务卡死现象,原因不明。

(6)因上述日志没有查到任务长时间卡死的线索,我们又查了卡死reduce任务进程的堆栈信息,从堆栈信息中,我们发现reduce任务获取map任务完成事件的线程状态是阻塞,也就是说reduce任务在等待map任务完成的信号但一直没收到,而事实上该job的所有map任务都已经完成,这导致整个作业卡死,在高并发情况下会偶现这种情况。之所以reduce没有触发超时kill机制是reduce任务的ping心跳发送本身并没有异常,而事件获取线程也并未退出(若因异常退出,会直接导致reducetask异常而重跑任务)。我们进一步查了job的如下三个参数:

ipc.client.ping=true

ipc.ping.interval=60000

ipc.client.rpc-timeout.ms=0

因设置了基于TCP的Socket的网络超时时间,当任务节点读取数据时发生SocketTimeoutException时,会自动的向服务器端发送ping包,来测试当前客户端与服务器端的连接是否正常,对应的参数为ipc.ping.interval(默认为60000ms)。ipc.client.rpc-timeout.ms是RPC客户端等待相应的超时时间值,当参数的值为0时,在远程方法调用没有接受到数据的情况下,只要ping服务正常,就不会超时,而只会按ipc.ping.interval时间间隔不停发出ping服务,如果有ipc.client.rpc-timeout.ms>0,该时间内未收到远程方法返回的数据即超时,随即停止发送ping服务,从而可以有效避免卡死。当前集群ping发送机制是打开的,每1分钟定期向服务器发送ping服务,但是超时时间设置为0,即永不超时,会一直处于读取map数据的阶段,这也就是AM一直认为该reduce任务还活着而没有按照任务超时机制将其kill。这样问题的核心原因基本找到了。

2.4. 作业运行外围情况分析

在分析日志的同时,我们也关注了作业卡死时段的其他外围情况:

1)有大量作业在该时段被调起;

2)近期集群进行了扩容,正在进行数据均衡操作中,节点间IO竞争激烈;

3)鉴于hadoop的任务分配原则(本地数据优先,计算在数据所在节点上进行的原则),在任务高峰期,某些节点IO竞争激烈,会导致任务超时现象发生。

2.5. 分析小结

综上,可以得到如下结论:

1)ipc.client.rpc-timeout.ms=0参数设置不合理,无超时退出机制,导致在高并发、IO竞争激烈的场景下,触发了任务长时间卡死的问题;

2)节点文件描述符数偏低,导致任务执行中出现“IOException: 没有那个进程”异常;

3)超时时间、容器内存配置等参数不够优化,导致部分任务超时失败退出,影响job执行;

4)大量作业并发和数据均衡操作一定程度上加剧了IO的竞争程度,间接触发了卡死问题的出现。

其中1)是产生问题的主要因素。

3. 问题解决

问题原因找到就好制定处理方案了,我们通过控制作业并发、降低数据均衡操作带宽和调整如下集群参数来解决问题:

image.png
image.png

上述操作执行后,问题得到解决。

经过此次问题处理,我们也总结了一套针对Hadoop程序长时间执行问题的解决思路:

1、首先检查是否有数据倾斜,因为大部分情况下是由这个原因引发Hadoop程序长时间执行问题。数据倾斜的典型现象是大部分reduce任务执行时间较短,只有很少的reduce任务长时间运行,同时某个key对应的数据比其他key对应的数据多很多,一旦出现上述情况就可判断是出现数据倾斜情况,需要对key值特别多的数据进行单独处理,比如在key上加随机数把数据打散,使得数据尽可能的平均shuffle到各reduce节点上,充分利用各节点的算力。

2、如果未出现数据倾斜的情况,那就需要先检查集群各主要组件的运行情况,如HDFS、YARN、Spark、Hive等,确认各组件是否正常,有相当一部分Hadoop程序长时间执行问题由组件运行问题引起。一般通过查看Hadoop集群UI页面上各组件状态和查看各组件系统日志来判定组件运行是否有问题。

3、如果上述两项均无问题,我们就需要针对日志进行更为细致的分析了,重点需要查看job日志、容器日志、map和reduce节点日志、以及map和reduce任务的进程栈,尤其是任务的进程栈对一些疑难问题的分析解决有很大帮助。一般到这一步引起超时问题的原因就很多了,需要具体问题具体分析,但我们不妨重点检查是否是相关超时参数设置不合理导致,如以下参数

image.png

以上思考仅供参考,希望对大家解决问题有所帮助。

查看原文

赞 0 收藏 0 评论 0

同创永益 发布了文章 · 4月9日

干货丨如何进行容器管理平台监控(k8s)

转自@twt社区,作者:李志伟

随着容器化、分布式的不断发展,业务系统的逻辑变得复杂,定位问题越来越困难,就需要从宿主机、容器管理平台和容器应用等多个层面进行监控,才可以定位性能问题、异常问题、安全问题等。本文介绍容器管理平台(k8s)的监控方法。

监控方式

容器类监控一般采用Prometheus进行监控,支持默认的pull模式获取数据,这也是官方推荐的方式。但是如果一些网络或防火墙等原因无法直接pull到数据的情况,就要借助Pushgateway让Prometheus转换为push方式获取数据;又比如我们将prometheus搭建在外网去监控内网应用的情况下,由于内网有诸多安全限制使得无法穿透,这时就要借助push模式来解决问题,还有就是监控的轮询监控大于被监控程序的执行时间,比如5秒pull一次数据,但是被监控程序1秒就执行完了。如下为pull和push的通用比较:

Pull

实时性取决于定时任务;客户端是有状态,需要知道拉取点,服务器端无状态,通常是短连接;难点实时性和流量的取舍。

Push

实时性较好;客户端无状态,服务器端有状态,需要了解每个客户端的推送点;通常是长链接;难点客户端能力和push能力不匹配问题。

K8s集群监控

使用系统命令查看kubectl top pod --all-namespaces

使用prometheus查询语句

`sum(kube_pod_container_resource_limits{resource="cpu", unit="core",
namespace="$Namespace"})`

CPU usage / available CPU in cluster

sum (rate (container_cpu_usage_seconds_total{namespace="$Namespace"}[1m])) / sum(machine_cpu_cores) * 100

Kube_namespaces_cpu_used_percent >80%

Kube_namespaces_memory_memused_bytes_percebt>80%

Kube_namespaces_requests_cpu_percent>80%

Kube_namespaces_requests_memory_percent>80%

Pod监控项

资源限制

spec:

containers:

imagePullPolicy: Always

name: kubernetes-serve-hostname

resources:

limits:

cpu: "1"

memory: 512Mi

requests:

cpu: "1"

memory: 512Mi

Pod Metrics

监控项举例:

Kube_pod_container_limit_cpu_cores>2

Node节点监控及告警

命令Kubectl get nodes

连续5分钟node状态是非ready,与master节点失联,最大告警2次

先检查状态

Systemctl status kubelet

Systemctl restart kubelet

守护进程(daemonset)监控

Kube_daemonset_statsu_number_unavailable>0 不可用pod数大于0

Kube_daemonset_current_number_normal==0 daemonset的pod与期望

Kube_daemonset_updated_number_normal==0 daemonset已更新与期望

守护进程监控项

无状态应用监控

Kube_deployment_status_replicas_unavailable>0 不可用副本数大于0

Kube_deployment_current_replicas_normal==0 当前副本数与期待副本数不一致

Kube_deployment_updated_replicas_normal==0 updateed副本数与期望副本数不一致。

Kubectl get deploy busybox

有状态应用监控

有状态核心告警

Kube_statefulset_replicas_ready_normal==0 副本是否与期望副本一致

Kube_statefulset_replicas_current_normal==0 当前副本与期望

查看未正常运行的pod的状态和事件,查看kubeclt deploy状态和事件

负载均衡器监控

应用访问通过ingress controller转发到ingress,再转发到具体的服务,最后转到具体的pod。因此ingress 监控至关重要。

URL、源IP、UserAgent、状态码、入流量、出流量、响应时间等,从这些信息中,我们能够分析出非常多的信息,例如:

1.网站访问的PV、UV;

2.网站访问的错误比例;

3.后端服务的响应延迟;

4.不同URL访问分布。

主要监控指标:

监控metric

事件监控

事件监控是Kubernetes中的另一种监控方式,可以弥补资源监控在实时性、准确性和场景上的缺欠。

Kubernetes的架构设计是基于状态机的,不同的状态之间进行转换则会生成相应的事件,正常的状态之间转

换会生成Normal等级的事件,正常状态与异常状态之间的转换会生成Warning等级的事件。通过获取事件,实时诊断集群的异常与问题。

Pod常见问题列表:

  • ImagePullBackOff
  • CrashLoopBackOff
  • RunContainerError
  • 处于Pending状态的Pod
  • 处于未就绪状态的Pod

ImagePullBackOff

当Kubernetes无法获取到Pod中某个容器的镜像时,将出现此错误。

可能原因:

  • 镜像名称无效,例如拼错镜像名称,或者镜像不存在。
  • 您为image指定了不存在的标签。
  • 您检索的镜像是私有registry,而Kubernetes没有凭据可以访问它。

解决方法:

  • 前两种情况可以通过修改镜像名称和标记来解决该问题。
  • 第三种情况,您需要将私有registry的访问凭证,通过Secret添加到Kubernetes中并在Pod中引用它。

CrashLoopBackOff

如果容器无法启动,则Kubernetes将显示错误状态为:CrashLoopBackOff。

可能原因:

  • 应用程序中存在错误,导致无法启动。
  • 未正确配置容器。
  • Liveness探针失败太多次。

解决方法:

  • 您可以尝试从该容器中检索日志以调查其失败的原因。如果容器重新启动太快而看不到日志,则可以使用命令:$ kubectl logs <pod-name>--previous。

RunContainerError

当容器无法启动时,出现此错误。

可能原因:

  • 挂载不存在的卷,例如ConfigMap或Secrets。
  • 将只读卷安装为可读写。

解决方法:

  • 请使用kubectl describe pod命令收集和分析错误。

处于Pending状态的Pod

当创建应用时,在变更记录中该Pod一直Pending状态。

可能原因:

  • 集群没有足够的资源(例如CPU和内存)来运行Pod。
  • 当前的命名空间具有ResourceQuota对象,创建Pod将使命名空间超过配额。
  • 该Pod绑定到一个处于pending状态的PersistentVolumeClaim。

解决方法:

  • 检查$ kubectl describe pod<pod name>命令输出的“事件”部分内容或者在控制台查看应用事件。
  • 对于因ResourceQuotas而导致的错误,可以使用$ kubectl get events--sort-by=.metadata.cre-ationTimestamp命令检查集群的日志。

处于未就绪状态的Pod

如果Pod正在运行但未就绪(not ready),则表示readiness就绪探针失败。

可能原因:

  • 当“就绪”探针失败时,Pod未连接到服务,并且没有流量转发到该实例。

解决方法:

  • 就绪探针失败是应用程序的特定错误,请检查$ kubectl describe pod<pod name>命令输出的“事件”部分内容,或者在控制台查看对应的应用事件。

监控指标阈值

推荐值

查看原文

赞 0 收藏 0 评论 0

同创永益 发布了文章 · 4月9日

干货丨采用 Oracle12c In memory 特性,一定能提高性能吗?

转自@twt社区,作者:杨建旭。

【摘要】Oracle 12c 中的 In memory特性,到底对性能有多大提升?本文描述了在一系列的实验中,不同场景下的性能表现。

Oracle 12c 中的 In memory 选件通过在 SGA 中分配独立的内存区域 (In Memory Area) ,对数据使用列式压缩存储来提高查询性能。

那么,这个 In memory 特性,到底能对性能有多大提升,我们做了一系列的实验,来看看不同场景下的性能表现。但首先要说的是,采用了 In memory 特性,性能并不一定提高,后面我会举例子。

1、相关参数

In Memory 区的大小由参数 inmemory_size 控制,该参数是一个静态参数 , 修改后需要重启数据库方可生效。

修改命令:

SQL> alter system set inmemory_size=2G scope=spfile;

System altered.

重启之后

2、普通场景下,数据库采用 In-memory 特性后,应用查询速度都有明显提升。

应用查询测试结果

可以看出,三种查询条件,采用了内存特性之后,响应时间分别提升了 23倍、2倍和6倍。**

3、数据库采用 In-memory 特性后,增删改的执行速度差异不大。

增删改测试结果

4、某些场景插入的速度仍然有较大提升

不过在某些场景下(比如,单用户大批量插入,后面的案例均采用单用户),插入的速度还是可以提升不少的,如下图。

测试案例中准备了 100 万笔数据,采用 Insert into Select 方式插入两张表,测试结果如下:

5、有其他业务压力干扰下的查询性能对比

某复杂的联合查询,内存表比普通表的查询速度提升20倍。那么,在有其他业务压力干扰下,它的查询性能是怎么样的?

带着这个问题,我们以每秒 5000 笔的速度向内存表和普通表插入数据。在该压力下测试这个复杂联合查询的性能

复杂 SQL :此处略过,写出来有好几行,看不懂

可以看出,在这个压力干扰下(每秒 5000笔插入数据的干扰),这个查询性能的提升,从原来的 20倍,变成了 4.3倍。**

6、DML v.s. QUERY LOW 方式

Oracle 有不同的压缩方式,我们先看看有哪些,都是怎么介绍的。

关注一下“ MEMCOMPRESS FOR QUERY LOW ”,咱们简称 QUERY LOW 吧,这个是缺省方式,号称查询性能最优。

上面的实验中我们是采用 DML 的方式的内存表,现在采用 QUERY LOW 方式试试:

内存表采用 QUERY LOW方式后,性能提升变成了 3.5倍,似乎还不如 DML的提升 4.3倍。看来官方文档也只能参考参考,具体您的环境、您的场景是什么参数性能好,那还得去调优。

DML v.s. QUERY LOW方式的性能的确有差异,这种差异是固定的吗?

我们换一个 SQL 语句,换成一个比较简单的 SQL 查询看看

在这个简单 SQL查询的场景中, QueryLow方式性能提升效果更明显。因此,谁快谁慢 it depends。

7、跨分区查询
在两实例均开启 In-Memory 特性的情况下,跨分区查询的效率竟然不如只在一个实例使用 In-Memory 特性。

8、综上

总体来说, In-Memory 特性是可以提升大部分查询场景的性能,但增删改场景很可能是混个持平,对于一些特殊场景,竟然还不如不使用 In-Memory 。不同的压缩方式下,性能的确不同,但有些场景下并不是官方介绍的那个性能结果,如果要得到最佳的性能,还得靠调优。

查看原文

赞 0 收藏 0 评论 0

同创永益 发布了文章 · 4月8日

数字韧性为企业数字化转型提供稳定保障

2020年黑天鹅事件频出,各行各业都在一片混沌和逆境中挑战着生存和增长的能力,在国家多项数字经济政策引导下,开始坚定地找寻数字化转型的目标和方法。

该如何乘风而上?相比初创企业的轻装上阵,大型传统企业要如何实现“大象转身”?数字化转型历经多年发展,该如何向更高的阶段发展,去重构企业的业务流程和模式?

3月31日,由中国信息通信研究院、中国通信标准化协会主办的2021数字化转型发展高峰论坛在北京精彩召开。为了响应国家关于推动数字经济和实体经济融合发展的重要指示精神,此次论坛以“数字赋能,共建共享”为主题,旨在把脉中国数字化发展,推动数字基础设施建设,引领产业数字化发展方向,并由此搭建数字化领域政用产学研专业交流平台。

(共建共享平台建立仪式)

作为信创核心企业、灾备和业务连续性领域的领军企业,同创受邀参加此次论坛。同创永益技术总监郑阳先生在金融行业数字化转型特设环节,以“企业数字韧性”为主题做了专题演讲,针对目前企业数字韧性的挑战与痛点陈述,以及实践案例深度分析,赢得了广泛赞誉。

(同创永益技术总监 郑阳)

以下根据郑阳总监现场分享编写:

建立数字韧性,实现业务永续

什么叫韧性:一个材料在受到外力冲击的时候,抵抗断裂的一种能力,韧性越大,断裂的可能性越小。

数字化就是用数字的技术去改变商业模式,把这两个概念结合在一起看,那么数字韧性就是组织在不断变化且日益复杂的数字环境中去抵抗、吸收、恢复和适应业务中断,以使其能够实现其目标,并反弹和繁荣的能力。我们反弹的韧性,一是人员,然后是流程、最后是技术,企业的业务肯定是跟人是息息相关的,新冠疫情期间会不会因为人员的隔离导致我们的业务中断,不能持续?流程方面,企业有没有办法避免灾难的发生,或者在灾难发生前、发生时、发生后能不能做到更加的游刃有余?技术方面不过多地展开,跟数字化相关的,肯定有新的技术。

(现场分享)

为什么去定义数字韧性?我们叫业务连续性,为什么上升到数字韧性的程度?第一,信息化向智能化的转变,信息化和智能化、数字化没有很清晰的界定,我们从另外一个角度去看这个问题,信息化更强调管理和流程,数字化更强调分析与决策,包括我们的智能化。我们从这个角度去界定并且在转变的过程当中。从传统的服务器向云端的转变,边缘计算的广泛应用落地。

饯行数字化落地,云原生时代的复杂现状,从云的形态上来讲,有混合云,专属云等等,云的结构越来越复杂,不只是互联网公司,传统企业也在做所谓的明态改造,稳态的业务还在跑稳态的业务下,这种稳明的业务,整个的业务架构非常复杂。

我们认为在数字韧性需要关注的几个问题:第一,传统方案有局限性,技术的不断迭代升级,造成了技术栈非常复杂;第二,数据安全性也是涉及存储技术的改变,原来有商务存储,分布式存储,软件定义存储等,怎么在这种多元化的存储环境下保证数据的安全可靠?第三,厂商锁定的问题,连续性这个问题在同构云架构之下,解决容易一些,异构云架构下是非常大的挑战。第四是业务架构,增长运维人员的压力,在这种复杂性的环境下赋能给他们,替他们解压?这是企业转型的问题,还是比较习惯传统的解决方案,怎么样让他们更快地适应新的业务形态?

同创永益把数字韧性问题及解决方案大致分为:灾难恢复管理智能运维管理以及业务连续性管理

灾备指挥管理平台通过场景管理、演练管理、灾难切换、 应急指挥、流程管理、咨询建议规划等服务,提供数据中心应用级别容灾自动化切换、指挥决策和管理能力。

智能的运维管理:什么叫容量管理?比如我的存储不够了,影响我的业务,容量管理可以对系统里的容量进行管控,比如说未来或者一周的需求是什么样的?IT应急管理系统,通过完善一个事件的监测和追踪,业务连续性的管理,通过我们的风险分析,平台化线上的分析工具,保持企业的连续性,知识对齐方面对企业人员进行认证、培训、服务。这是我们同创永益的八个产品和服务对应我们的数字韧性解决方案。

作为业务连续性领域的领军企业,同创永益有着十余年的连续性领域的技术积淀以及完整的业内产品矩阵,服务了近百家中大型金融行业客户,有着丰富的实战经验。迄今为止,已经与数十家世界500强的金融企业/机构成为合作伙伴。

同创永益的八大解决方案可以完美帮助企业数字韧性建立与增长,通过咨询帮助及定制化的各种解决方案,解决企业数字化转型落地到实现业务永续。

通过不断的自主研发创新,同创永益期望成为业务连续性、IT韧性和灾难恢复领域最具影响力的领导者,并携手合作伙伴,在支撑客户关键业务成长的同时,为客户持续创造新的业务价值,围绕客户需求和产业发展,共创美好数字化未来。

查看原文

赞 0 收藏 0 评论 0

同创永益 发布了文章 · 4月7日

干货丨k8s 集群优化之监控平台的建立

转自@twt社区,作者:谢文博。

优化首先需要建立起一个目标,到底优化要达到一个什么样的目标,期望满足什么样的需求,解决业务增加过程中发生的什么问题。监控平台的建立是为Kubernetes集群及运行的业务系统得出系统的真实性能,有了现有系统当前的真实性能就可以设定合理的优化指标,基本基线指标才能合理评估当前Kubernetes容器及业务系统的性能。本文介绍了如何建立有效的监控平台。

1. 监控平台建设

所有的优化指标都是建立在对系统的充分了解上的,常规基于Kubernetes的监控方案有以下大概有3种,我们就采用比较主流的方案,也降低部署成本和后期集成复杂度。

主流也是我们选取的方案是Prometheus +Grafana +cAdvisor +(要部署:Prometheus-operator, met-ric-server),通过Prometheus提供相关数据,Prometheus定期获取数据并用Grafana展示,异常告警使用AlertManager进行告警。实际部署过程中实施也可以考虑使用Kube-prometheus项目(参见注释1)整体部署节省大量工作,以下是官方架构图,涉及到组件如下:

  • Prometheus Operator
  • Prometheus
  • Alertmanager
  • Prometheus node-exporter
  • Prometheus Adapter for KubernetesMetrics APIs
  • kube-state-metrics
  • Grafana

上图中的Service和ServiceMonitor都是Kubernetes的资源,一个ServiceMonitor可以通过labelSelector的方式去匹配一类Service,Prometheus也可以通过labelSelector去匹配多个ServiceMonitor。

主要监控范围分为:资源监控,性能监控,任务监控,事件告警监控等,因为本篇主要讲的是性能优化,所以侧重点放在性能监控上,但是优化是全方位的工作所以也会涉及到资源,健康度,事件,日志等,另外就针对每种监控类型的告警管理。

*注释1:项目地址如下,就部署方式可参见项目介绍在此就不赘述:https://github.com/coreos/kube-prometheus

2.数据采集

各维度的数据采集主要通过以下方式:

  • 部署cAdvisor(参见注释2)采集容器相关的性能指标数据,并通过metrics接口用Prometheus抓取;
  • 也可根据需求可将各种监控,日志采集的Agent部署在独立的容器中,跟随Pod 中的容器一起启动监督采集各种数据,具体可根据实际需求;
  • 通过Prometheus-node-exporter采集主机的性能指标数据,并通过暴露的metrics接口用Prometheus抓取
  • 通过exporter采集应用的网络性能(Http、Tcp等)数据,并通过暴露的metrics接口用Prometheus抓取
  • 通过kube-state-metrics采集k8S资源对象的状态指标数据,并通过暴露的metrics接口用Prometheus抓取
  • 通过etcd、kubelet、kube-apiserver、kube-controller-manager、kube-scheduler自身暴露的metrics获取节点上与k8S集群相关的一些特征指标数据。
*注释2:node-exporter:负责采集主机的信息和操作系统的信息,以容器的方式运行在监控主机上。cAdvisor:负责采集容器的信息,以容器的方式运行在监控主机上。

3. 资源监控說明

资源监控主要分为这几大类:如:CPU,内存,网络,磁盘等信息的监控(其它还有对GPU等监控),另外就是对各种组件服务的资源使用情况,自定义告警阈值等(简单的告警获可以沿用内部已有的,复杂的告警指标需自己根据集群和业务特征通过获取参数进行计算或撰写PromQL获取),建立全方位的监控指标(主要监控指标项可参见Kube-prometheus部署后的相关信息,在此就不赘述),主要监控项如下;

  • 容器 CPU,Mem,Disk, Network等资源占用等情况;
  • Node、Pod相关的性能指标数据;
  • 容器内进程自己主动暴露的各项指标数据;
  • 各个组件的性能指标涉及组件如:ECTD,API Server, Controller Manager, Scheduler, Kubelet等;

4. 主要指标监控

主要的监控指标,是依据Google提出的四个指标:延迟(Latency)、流量(Traffic)、错误数(Errors)、饱和度(Saturation)。实际操作中可以使用USE或RED(详见注释3和4)方法作为衡量方法,USE用于资源,RED用于服务,它们在不同的监控场景有不同维度描述,相结合能够描述大部分监控场景指标,合理的使用以下监控指标,有助用户判断当前K8S集群的实际运行情况,可根据指标变化反复优化各个参数和服务,使其达到更加的状态,更详细的监控指标信息,可参见Kube-prometheus相关监控信息。

4.1 Cadvisor指标采集

cAdvisor(详见参考1)提供的Container指标最终是底层Linux cgroup提供的。就像Node指标一样,但是我们最关心的是CPU/内存/网络/磁盘。

1.CPU(利用率)

对于Container CPU利用率,K8S提供了每个容器的多个指标:

.#过去10秒容器CPU的平均负载

container_cpu_load_average_10s

.#累计用户消耗CPU时间(即不在内核中花费的时间)

container_cpu_user_seconds_total

.#累计系统CPU消耗的时间(即在内核中花费的时间)

container_cpu_system_seconds_total

.#累计CPU消耗时间

container_cpu_usage_seconds_total

.#容器的CPU份额

container_spec_cpu_quota

.#容器的CPU配额

container_spec_cpu_shares

.#查询展示每个容器正在使用的CPU

sum(

rate(container_cpu_usage_seconds_total [5m]))

by(container_name)

.# 过去10秒内容器CPU的平均负载值

container_cpu_load_average_10s{container="",id="/",image="",name="",namespace="",pod=""}

.#累计系统CPU消耗时间

sum(rate(container_cpu_usage_seconds_total{name=~".+"}[1m])) by (name) * 100

.#全部容器的CPU使用率总和,将各个CPU使用率进行累加后相除

sum(rate(container_cpu_usage_seconds_total{container_name="webapp",pod_name="webapp-rc-rxli1"}[1m])) / (sum(container_spec_cpu_quota{container_name="webapp",pod_name="webapp-rc-rxli1"}/100000))

2.CPU(饱和度)

sum(

rate(container_cpu_cfs_throttled_seconds_total[5m]))

by (container_name)

3.内存

cAdvisor中提供的内存指标是从可参见官方网站,以下是内存指标(如无特殊说明均以字节位单位):

.#高速缓存(Cache)的使用量

container_memory_cache

.# RSS内存,即常驻内存集,是分配给进程使用实际物理内存,而不是磁盘上缓存的虚拟内存。RSS内存包括所有分配的栈内存和堆内存,以及加载到物理内存中的共享库占用的内存空间,但不包括进入交换分区的内存

container_memory_rss

.#容器虚拟内存使用量。虚拟内存(swap)指的是用磁盘来模拟内存使用。当物理内存快要使用完或者达到一定比例,就可以把部分不用的内存数据交换到硬盘保存,需要使用时再调入物理内存

container_memory_swap

.#当前内存使用情况,包括所有使用的内存,不管是否被访问 (包括 cache, rss, swap等)

container_memory_usage_bytes

.#最大内存使用量

container_memory_max_usage_bytes

.#当前内存工作集(working set)使用量

container_memory_working_set_bytes

.#内存使用次数达到限制

container_memory_failcnt

.#内存分配失败的累积数量

container_memory_failures_total

.#内存分配失败次数

container_memory_failcnt

4.内存(利用率)

通过PromQL特定条件查询容器内job内存使用情况:

container_memory_usage_bytes{instance="10.10.2.200:3002",job="panamax", name="PMX_UI"}18

kubelet 通过container_memory_working_set_bytes 来判断是否OOM, 所以用 working set来评价容器内存使用量更合理,以下查询中我们需要通过过滤“POD”容器,它是此容器的父级cgroup,将跟踪pod中所有容器的统计信息。

sum(container_memory_working_set_bytes {name!~“ POD”})by name

5.内存(饱和度)

OOM的异常获取没有直接的指标项,因为OOM后Container会被杀掉,可以使用如下查询来变通获取,这里使用label_join组合了 kube-state-metrics 的指标:

sum(container_memory_working_set_bytes) by (container_name) / sum(label_join(kube_pod_con-tainer_resource_limits_memory_bytes,"container_name", "", "container")) by (container_name)

6.磁盘(利用率)

在处理磁盘I/O时,我们通过查找和读写来跟踪所有磁盘利用率,Cadvisor有以下指标可以做位基本指标:

.#容器磁盘执行I/O的累计秒数

container_fs_io_time_seconds_total

.#容器磁盘累计加权I/O时间

container_fs_io_time_weighted_seconds_total

.#查询容器文件系统读取速率(字节/秒)

sum(rate(container_fs_writes_bytes_total{image!=""}[1m]))without (device)

.#查询容器文件系统写入速率(字节/秒)

sum(rate(container_fs_writes_bytes_total{image!=""}[1m]))without (device)

最基本的磁盘I/O利用率是读/写的字节数, 对这些结果求和,以获得每个容器的总体磁盘I/O利用率:

sum(rate(container_fs_reads_bytes_total[5m])) by (container_name,device)

7.网络(利用率)

容器的网络利用率,可以选择以字节为单位还是以数据包为单位。网络的指标有些不同,因为所有网络请求都在Pod级别上进行,而不是在容器上进行以下的查询将按pod名称显示每个pod的网络利用率:

.#接收时丢包累计计数

container_network_receive_bytes_total

.#发送时丢包的累计计数

container_network_transmit_packets_dropped_total

.#接收字节(1m)

sum(rate(container_network_receive_bytes_total{id="/"}[1m])) by (id)

.#上传字节(1m)

sum(rate(container_network_transmit_bytes_total{id="/"}[1m])) by (id)

8.网络(饱和度)

在无法得知准确的网络带宽是多少的情况下,网络的饱和度无法明确定义,可以考虑使用丢弃的数据包代替,表示当前已经饱和,参见以下参数:

.#接收时丢包累计计数

container_network_receive_packets_dropped_total

.#发送时丢包的累计计数

container_network_transmit_packets_dropped_total

注释3:在对于cAdvisor 容器资源,USE方法指标相对简单如下:Utilization:利用率Saturation:饱和度Error:错误注释4:USE 方法的定义:Resource:所有服务器功能组件(CPU,Disk,Services等)Utilization:资源忙于服务工作的平均时间Saturation:需要排队无法提供服务的时间Errors:错误事件的计数RED 方法的解释:Rate:每秒的请求数。Errors:失败的那些请求的数量。
参考 1:更详细关于cAdvisor的参数信息大家可以一下地址获取,也可以自己组合更加适用于自己集群的监控指标:https://github.com/google/cadvisor/blob/master/docs/storage/prometheus.md参考2:关于Node_exporter,大家有兴趣可以参考Prometheus项目中关于Node_exporter里面说明如下:https://github.com/prometheus/node_exporter

5. 事件告警监控

监控Event 转换过程种的变化信息,以下只是部份告警信息,Kube-Prometheus项目中有大部分告警指标,也可以从第三方导入相关告警事件:

.#存在执行失败的Job:

kube_job_status_failed{job=”kubernetes-service-endpoints”,k8s_app=”kube-state-metrics”}==1

.#集群节点状态错误:

kube_node_status_condition{condition=”Ready”,status!=”true”}==1

.#集群节点内存或磁盘资源短缺:

kube_node_status_condition{condition=~”OutOfDisk|MemoryPressure|DiskPressure”,status!=”false”}==1

.#集群中存在失败的PVC:

kube_persistentvolumeclaim_status_phase{phase=”Failed”}==1

.#集群中存在启动失败的Pod:

kube_pod_status_phase{phase=~”Failed|Unknown”}==1

.#最近30分钟内有Pod容器重启:

changes(kube_pod_container_status_restarts[30m])>0

6. 日志监控

日志也是K8S集群和容器/应用服务的很重要的数据来源,日志中也能获取各种指标和信息,主流的方式采用常驻的Agent采集日志信息,将相关发送到Kafka集群最后写入ES,也通过Grafana进行统一展示各项指标。

6.1 日志采集

  • 一种方式将各个容器的日志都写入宿主机的磁盘,容器挂载宿主机本地Volume,采用Agent(Filebeat或Fluentd )采集这个部署在宿主机上所有容器转存的日志,发送到远端ES集群进行加工处理;
  • 另一种是对于业务组(或者说Pod)采集容器内部日志,系统/业务日志可以存储在独立的Volume中,可以采用Sidecar模式独立部署日志采集容器,来对进行日志采集,对于DaemonSet和Sidecar这两种日志采集模式,大家可以根据实际需要选择部署;
  • 通过部署在每个Node上的Agent进行日志采集,Agent会把数据汇集到Logstash Server集群,再由Logstash加工清洗完成后发送到Kafka集群,再将数据存储到Elasticsearch,后期可通过Grafana或者Kibana做展现,这也是比较主流的一个做法。

6.2 日志场景

主要需要采集的各种日志分为以下场景:

1.主机系统内核日志采集:

  • 一方面是主机系统内核日志,主机内核日志可以协助开发/运维进行一些常见的问题分析诊断,如:Linux Kernel Panic涉及的(Attempted to kill the idle task,Attempted to kill init,killing interrupt handler)其它致命异常,这些情况要求导致其发生的程序或任务关闭,通常异常可能是任何意想不到的情况;
  • 另一方面是各种Driver 驱动异常,比如:Driver内核对象出现异常或者说使用GPU的一些场景,各种硬件的驱动异常可能是比较常见的错误;
  • 再就是文件系统异常,一些特定场景(如:虚机化,特定文件格式),实际上是会经常出现问题的。在这些出现问题后,开发者是没有太好的办法来去进行监控和诊断的。这一部分,其实是可以主机内核日志里面来查看到一些异常。

2.组件日志采集:

K8S集群中各种组件是集群非常重要的部份,既有内部组件也有外部的如:API Server, Controller-man-ger,Kubelet , ECTD等, 它们会产生大量日志可用于各种错误分析和性能优化,也能帮助用户很好分析K8S集群各个组件资源使用情况分析,异常情况分析;还有各种第三方插件的日志(尤其是一些厂商贡献的网络插件或算法),也是优化分析的重点;

3.业务日志采集:

业务日志分析也是优化的很重要的环节,业务系统自身的特性(如:web类,微服务类,API 接口类,基础组件类)都需要日志来分析,结合后面的资源预测和业务部署章节能否更好把握业务特性,创建合理的发布配置和Pod配置,根据日志分析业务访问量,活动周期,业务峰值,调用关系等优化整个过程。

查看原文

赞 0 收藏 0 评论 0

同创永益 发布了文章 · 4月6日

干货丨如何用慢查询找到 Redis 的性能瓶颈?

转自@twt社区,【作者】姜文浩。

Redis数据库是一个基于内存的 key-value存储系统,现在redis最常用的使用场景就是存储缓存用的数据,在需要高速读/写的场合使用它快速读/写,从而缓解应用数据库的压力,进而提升应用处理能力。

由于Redis的单线程架构,所以需要每个命令能被快速执行完,否则会存在阻塞Redis的可能,理解Redis单线程命令处理机制是开发和运维Redis的核心之一。

许多数据库会提供慢查询日志帮助开发和运维人员定位系统存在的慢操作。所谓慢查询日志就是系统在命令执行前后计算每条命令的执行时间,当然在数据库中最常见的就是select这些sql语句了,当超过预设阀值,就将这条命令的相关信息(例如:发生时间,耗时,命令的详细信息)记录下来,Redis也提供了类似的功能。

那么如何使用Redis所提供的慢查询功能呢?Redis主要提供了slowlog-log-slower-than和slowlog-max-len两个配置参数来提供这项功能。两项参数分别用来设置慢查询的阈值以及存放慢查询的记录。首先对redis的这两个配置进行一个说明 :

从字面意思就可以看出,可以通过slowlog-log-slower-than参数设置什么情况下是慢语句,只有redis命令执行时间大于slowlog-log-slower-than的才会定义成慢查询,才会被slowlog进行记录。它的单位是微秒(1秒=1000毫秒=1000000微秒),在初始情况下默认值是10000,也就是10ms,假如执行了一条比较慢的命令,如果它的执行时间超过了 10ms ,那么它将被记录在慢查询日志中。(如果slowlog-log-slower-than=0会记录所有的命令,slowlog-log-slower than<0对于任何命令都不会进行记录)

从字面意思看,slowlog-max-len说明了慢查询日志最多可以存储多少条记录,实际上Redis使用了一个列表来存储慢查询日志,slowlog-max-len就是列表的最大长度,它自身是一个先进先出队列,当slowlog超过设定的最大值后,会将最早的slowlog删除。简而言之当一个新的命令满足慢查询条件时会被插入到这个列表中,当慢查询日志列表已处于其最大长度时,最早插入的一个命令将从列表中移出,例如slowlog-max-len设置为 50 ,当有第51条慢查询插入的话,那么队头的第一条数据就出列,第51条慢查询就会入列。

接下来详细介绍一下如何配置这两个参数,有两种方式进行配置,以下截图全部使用了redis -5.0.5版本 :

方式一:通过配置redis.conf文件进行配置。

通过修改redis .conf文件之后重启redis服务 , 配置即可生效 。

方式二:通过CONFIG命令进行动态配置

配置查询时间超过1毫秒的命令进行记录

保存500条慢查记录

通过config get命令确认配置已生效

要注意通过config命令配置的为动态生效 , 一旦服务重启则会重新恢复为默认设置 , 所以建议在排查问题时通过config这种方式进行配置 , 但是服务稳定后通过修改配置文件方式进行最终确认 (可以通过config rewrite命令持久化到本地文件 , 但要主要启动redis时要指定redis . conf文件 该命令才可以生效)。

相关的参数已经设置完成了 , 那么如何查看记录的信息呢 ?要想查看所记录的日志 , 主要使用 SLOWLOG GET 或者 SLOWLOG GET number 命令,前者将会输出所有的 slow log ,最大长度取决于 slowlog-max-len 选项的值,而 SLOWLOG GET number 则只打印指定数量的日志。

查看当前日志数量: 使用SHOW LEN命令查看日志数量。

因为我是新安装的redis , 所以现在还没有耗时长日志 , 所以条数是 0,如果日志条数过多,还可以使用slowlog reset命令进行日志清空 。

为了方便演示 ,我将所有的执行命令都记录了下来,以第一条为例,

1、(integer) 1 # 唯一性(unique)的日志标识符

2、(integer) 1562075522 # 被记录命令的执行时间点,以 UNIX 时间戳格式表示

3、(integer) 93 # 查询执行时间,以微秒为单位

4、1."CONFIG" # 执行的命令,以数组的形式排列

5、"GET"

6、" " # 这里完整的命令是 CONFIG GET

慢查询功能可以有效地帮助我们找到Redis可能存在的瓶颈,但在实际使用过程中要注意以下几点:

  • slowlog-max-len配置建议:线上建议调大慢查询列表,记录慢查询时 Redis会对长命令做截断操作,并不会占用大量内存。增大慢查询列表可以减缓慢查询被剔除的可能,例如线上可设置为 2000 以上(5.0.5版本默认为128)。
  • slowlog-log-slower-than配置建议:默认值超过10毫秒判定为慢查询,需要根据Redis并发量调整该值。由于Redis采用单线程响应命令,对于高流量的场景,如果命令执行时间在1毫秒以上,那么Redis最多可支撑OPS不到1000。因此对于高OPS场景的Redis建议设置为1毫秒(OPS指每秒操作次数)。
  • 慢查询只记录命令执行时间,并不包括命令排队和网络传输时间。因此客户端执行命令的时间会大于命令实际执行时间。因为命令执行排队机制,慢查询会导致其他命令级联阻塞,因此当客户端出现请求超时,需要检查该时间点是否有对应的慢查询,从而分析出是否为慢查询导致的命令级联阻塞。
  • 由于慢查询日志是一个先进先出的队列,也就是说如果慢查询比较多的情况下,可能会丢失部分慢查询命令,为了防止这种情况发生,可以定期执行slow get命令将慢查询日志持久化到其他存储中,然后可以进行相关的监控、告警、分析工作。
查看原文

赞 0 收藏 0 评论 0

同创永益 发布了文章 · 4月2日

新版 ISO 22301 全解读

ISO 22301业务连续性管理体系,自其发布以来该体系不断完善以指导企业更好地落地实施,保障业务持续不间断运转。目前共有两个版本,2019版与2012版。

2019 新版针对 2012 旧版而言到底有什么变化?对于业务连续性及行业到底又有什么影响?

解读之前,先回顾一下,什么是 ISO 22301

ISO 22301 是全球首个基于组织业务连续性管理(Business Continuity Management,简称BCM)的国际标准,旨在帮助组织建立预案和确保其业务在面对外部威胁时能够持续运转,例如自然灾害或者信息安全漏洞。

ISO 22301业务连续性管理体系,能够帮助企业制定一套一体化的管理流程计划,使企业对潜在的灾难加以辨别分析,帮助其确定可能发生的冲击对企业运作造成的威胁,并提供一个有效的管理机制来阻止或抵消这些威胁,减少灾难事件给企业带来损失。

以下内容为同创咨询专家樊宇整理编写:

ISO 22301-2019 新版标准的变化

最新版本IS0 22301:2019的关键改进更倾向于结构和术语,以加强对内容的更好理解,并使其与其它 ISO 管理体系标准保持一致。

自2012年首次发布以来,ISO 22301标准已成为业务连续性管理体系的国际标准。根据 ISO 调查,已有超过4000个组织持有了 ISO 22301证书。该标准的受欢迎程度已经在多个行业中快速传播,如银行、保险、证券、化工厂、IT服务提供商以及汽车零件制造商等。

考虑到这种流行性,结合其历年来的实际使用效果。ISO 22301新版本于2019年11月正式发布。

image.png

变化是有限的‍

如果您已经通过 ISO 22301:2012认证,那么过渡到ISO 22301:2019基本没有任何问题。ISO 22301:2019版与2012版对比表明,ISO 22301:2019标准并没有重大的结构更改。

在过去的几年中,对 ISO 管理体系标准进行修订时,有挑战性的主要原因之一为其高级结构,它是所有 ISO 管理体系标准的统一结构和核心文本。但是,2012年版的ISO 22301:2012已经具有高级结构,这是最早采用这种新结构的 ISO 标准之一。

因此,工作组不必重写整个标准,而可以专注于措辞和清晰度。减少了许多多余的部分,定义变得更加一致,用词变得更加合乎逻辑。

image.png

回到BCM的本质‍

很多要求已经被还原到 BCM 的本质上。

第4.1节就是一个很好的例子:ISO 22301:2012年版规定了组织需要做些什么(和记录了什么)才能理解组织及其背景,而新版 ISO 22301:2019仅说明了 “确定外部和内部问题”的需要,而没有具体说明这必须要怎么做。ISO 22301:2019没有说需要考虑哪些方面,也没有包括记录该过程的要求。关于沟通的第7.4节发生了类似的事情,这说明新版本IS0 22301:2019的要求明显降低。

另一个已削减的要求是最高管理者的参与(5.2)。ISO 22301:2012旧版本甚至要求高层管理人员“积极参与演练和测试“,但 ISO 22301:2019新版本的方法更为实用,并着重于保持 BCMS 的有效性。

ISO 22301:2019 其他变化‍

除了大量的细微调整,对申请认证企业的影响很小或没有影响的同时,还有一些值得一提的变化:

第6.3条是很少的新要求之一它要求组织"以计划的方式”对 BCMS 进行更改。尽管从技术上讲此要求是新的,但该条款的内容对于任何人都不应该感到惊讶,也很容易以及应该做到。

现在,关于业务连续性分析( BIA )的第8.2.2节规定,BIA 应该以影响类别为起点。虽然很多组织已经在其 BIA中定义了影响类别,但新版标准将该要求设为强制性

第8.3节已从“业务连续性策略” "重命名为“业务连续性策略和解决方案。这反映岀 ISO 22301:2019该标准越来越实用主义,重点不在于制定确保业务连续性的宏伟战略,而是针对特定风险和影响寻求解决方案。

组织应基于业务影响分析和风险评估的输出,确定并选择业务连续性策略。业务连续性策略应由一个或多个解决方案组成。

从标准中删除了 “风险偏好” 一词。在2012年版本中,风险偏好被定义为“组织愿意承担或保留的风险的数量和类型”。但是,ISO 22301:2019新标准取消了该术语。“风险偏好”不仅是一个相当主观的问题, 而且还是无关紧要的。

image.png

ISO 22301 新版本从发布日期开始,转换期限为3年,即至2022年10月30日结束。

但根据IAF关于COVID-19(新冠疫情)爆发期间的FAQ,将转换过渡期延长6个月至2023年4月30日,即2023年5月1日起,所有 ISO 22301:2012版认证证书均将失效,不论其证书中标识的有效期是否到期。

image.png

同创永益的ISO 22301:2019咨询认证业务正在全面开展中。同时,同创永益已与 BSI(国际认证机构) 达成金融行业战略合作伙伴。

如果您有ISO 22301:2019认证需求,同创永益将给您带来更优惠,更便捷,更专业的咨询服务,全程协助您获得国际认证的ISO 22301:2019证书。

查看原文

赞 0 收藏 0 评论 0

同创永益 发布了文章 · 3月26日

干货丨Zabbix 负载判断与调整配置参数

转自@twt社区【作者】许远

【摘要】本文包括两篇Zabbix应用技能分享:Zabbix 负载判断与调整配置参数;Zabbix_server正常运行,却提示服务器没有运行的解决办法。

Zabbix负载判断与调整配置参数

目的:

在Zabbix负载时提供排查思路及处理方法(主要讲解调整配置参数)

处理负载的方式:

禁用异常监控及使用Zabbix客户端主动方式、调整zabbix配置参数、告警收敛(去除没必要的告警,以及避免告警风暴)、硬件更新

建议:

不使用zabbix管家清理历史数据与趋势数据,数据量大时,zabbix管家数据清理会直接导致zabbix崩溃;可使用数据库表分区的方式,把对应的数据分为多个分区逐个清理

背景:

随着公司体系加大,使用zabbix监控的机器越来越多,主机部分指标时延越来越大,1mà5mà10m

1、检查zabbix队列,查看是否存在5m以上的队列,查看细节确认哪些主机导致队列,有队列则继续下一步(若无队列,界面操作过慢,可以使用IOSTAT检查数据库IO情况)

2、查看对应的主机,是否监控状态异常,状态正常则继续下一步(如果异常:把主机禁用,过几分钟后查看队列是否消失)

3、手动在zabbix采集服务器上使用zabbix_get命令获取界面无数据的指标,正常获取则继续下一步(若异常,根据报错进行处理问题)

zabbix_get –s 客户端IP –k 键值

4、目前可以判断,数据是可以正常获取,但通过客户端推送时,数据响应时间过长(客户端agent可配置超时时间默认3s,可配置30s,修改后数据仍是前面的情况,则继续下一步),导致界面无法显示;

在图形功能找到zabbix的自身监控,查看”Zabbix cache usage.% free”

在图形中,我们可以看到zabbix自身的性能已达到负载,超过预定阈值,我们可以通过调整zabbix-server配置文件参数,加大zabbix性能

StartPollers=160

StartPollersUnreacheable=80

StartTrappers=20

StartPingers=100

StartDiscoverers=120

Cachesize=1024M

startDBSyncers=16

HistoryCacheSize-1024M

TrendCacheSize=1024M

HIstoryTextCacheSize-512M

重启zabbix-server

5、调整参数后,发下zabbix数据采集恢复正常,队列消失

Zabbix_server正常运行,却提示服务器没有运行

Zabbix突然出现了:

Zabbix server is not running:the information displayed may not be current

Zabbix 服务器没有运行:显示的信息可能不是当前的

一、SELinux未关闭

selinux一定要关闭,如果开启selinux,可能zabbix的discovery都不能正常使用

关闭selinux方法:

1、修改/etc/selinux/config文件中的SELINUX=“”值为disable,然后重启。

2、如果不想重启,使用setenforce 0

setenforce 1,selinux为enforcing模式

setenforce 0,selinux为permissive模式

二、zabbix web 目录下面,$ZBX_SERVER 是否为IP,如果是localhost,ping一下localhost是否能解析。如果不能,需要/etc/hosts文件里增加相应的项目。

三、查看php的fsockopen模块是否启用。

方法一:

第一步:

php.ini文件中查找

allow_url_fopen = On

使其值为On

第二步:

php.ini文件中查找

extension=php_openssl.dll

如果前面有分号,去掉分号

第三步:

重启web服务器,apache或IIS

方法二:

  1. vi php.ini

找到 allow_url_fopen 这个参数设置成 On,即

allow_url_fopen = On

  1. 让你的php支持 opensll扩展。

默认,是没有openssl扩展的,只能重新编译安装。

yum install openssl openssl-devel

cd /usr/local/src/php-5.2.14/ext/openssl

/usr/local/php/bin/phpize

./configure –with-openssl –with-php-config=/usr/local/bin/php-config

make && make install

看提示,把编译成的openssl.so 拷贝到你在php.ini 中指定的 extension_dir 下

  1. vi php.ini

加入

extension=openssl.so

  1. 重启web server

四、监控对象占满了trapper进程导致前端与server无法通信

“At least one trapper process must be running to display server availability and view queue in the frontend.”——Trapper进程用于接收前端查询server可用性及队列的请求将StartTrappers=20调整到StartTrappers=100,重启zabbix-server。

查看原文

赞 0 收藏 0 评论 0

同创永益 发布了文章 · 3月26日

干货丨Redis 性能测试和监控

**转自@twt社区,作者:泊涯
很多人在安装部署好Redis后,就没有对Rredis的配置和部署等有效性和高可用性进行性能测试,最终导致上线出现缓存穿透、雪崩等现象,导致性能还是有问题,其实做为技术运维人员在部署好Redis后可以使用Redis自带的压测工具进行简易型压测**,如下命令:

redis-benchmark [option] [option value]

例如在本地搭建一个Redis服务,IP地址是10.100.81.171,这时需要模拟100用户并发链接请求,每个用户现场循环访问100次。

redis-benchmark -h 10.100.81.171 -p 6379 -c 100 -n 100000

参数详解:

1、100000 requests completed in 1.60 seconds //默认是100000,上面有,请求在1.6s内完成 2、3 bytes payload,每次写入3个字节的数据 3、keep alive: 1,保持一个连接,一台服务器来处理这些请求 4、100.00% <= 2 milliseconds,所有请求2毫秒完成 5、62656.64 requests per second 每次能处理请求数量

具体如下图:

Redis读写情况压测,如下:测试存取大小为500字节的数据包的性能 redis-benchmark -h 10.100.81.171 -p 6379 -q -d 500

这时可以通过监控命令或者其他工具看到Redis服务的服务器资源使用情况:

redis-benchmark 工具命令使用介绍:

查看原文

赞 0 收藏 0 评论 0

认证与成就

  • 获得 0 次点赞
  • 获得 1 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 1 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 1月20日
个人主页被 981 人浏览