IT评测·应用市场-qidao123.com技术社区

标题: GaussDB高智能--自治运维技术（中） [打印本页]

---

作者: 拉不拉稀肚拉稀    时间: 2024-10-13 10:33
标题: GaussDB高智能--自治运维技术（中）
目录
2.4 日志分析  
（1）日志解析阶段
（2）日志分析模型的练习
（3）在线检测模块
2.5 慢SQL发现  
（1）练习阶段
（2）猜测流程
2.6 慢SQL诊断  
（1）获取慢SQL相干信息
（2）获取数据库关键指标信息    
（3）联合数据库关键指标信息和执行计划，分析慢SQL根因；
2.7 集群故障根因诊断  

---

2.4 日志分析  

日志是产品最紧张的基础运维数据之一，它是一种文本数据，一般由时间戳和文本消息（等级、常量、别的变量）构成，实时记载了业务的运行状态。因此凡是能够打印日志的装备，理论上均可以通过分析日志，进行故障猜测、亚健康检测、故障定界定位等维护运动。对故障诊断任务而言,日志相较指标有着诊断代码段级别故障，支持对步调执行逻辑的跟踪，捕获故障细节的上风，而且很多时候是唯一可用的故障诊断数据源。
GaussDB的日志分析功能主要是将非布局化的日志流，转换为时序数据，而后自然地与非常检测等机制进行对接，便于整合完整的非常诊断能力。日志分析功能包括两个关键部分，一个是日志收罗模块，另一个是日志分析模块，这两个部分都在日志收罗端实现，其整体模块布局图如下：    

日志收罗和分析的步调如下：
（1）启动本功能的exporter, 使用Linux的inotify体系调用，监听日志写入变乱；
（2）GaussDB数据库实例向被监听的日志文件目录写入日志；
（3）exporter 通过inotify体系调用，获知日志写入变乱，exporter的LogCollector子模块从日志文件目录中读取被写入的日志文件内容；
（4）exporter的LogAnalyst模块获取写入的日志文件内容，并对其进行量化整理；
（5）时序数据库访问exporter，LogAnalyst将已经量化好的日志指标项返回时序数据库。    
日志分析功能在具体实现上，主要包括离线学习模块和在线检测模块两部分，其计划流程图如下图所示：

此中离线学习模块具体有以下步调：
（1）日志解析阶段

数据预处理：根据预设正则表达式去除噪声变量和拆分日志记载文本字符串得到单词列表，如日志记载“2020 04 23 17:01:11 INFO getGraceTime, customerID: lisi4, bpID: d1, graceTime:0”通过正则表达式更换customerID信息为通配符‘*’，并拆分字符和驼峰词定名词得到三部分，分别是时间：“2020 04 23 17:01:11”，等级：“INFO”，“单词列表”：['get', 'grace', 'time', ',', 'customer', 'id', ':', '*', ',', ‘bp’, 'id', ':', 'd1hg123', 'grace', 'time', ':', '0']；
日志初始模板提取：这里关键词指日志常量部分，一般来讲常用英文，通过关键词词典，这里使用了维基百科语料出现频率前10000且含有字母数目超过2的纯英文单词加上业务专有术语作为关键词词典，将上述单词列表里非关键词更换为通配符，得到日志初始模板['get', 'grace', 'time', ',', 'customer', 'id', ':', '*', ',', ‘bp’, 'id', ':', '*', 'grace', 'time', ':', '*']；
日志记载聚类：相同日志初始模板的日志记载会被聚类为一个日志聚集,好比日志记载“getGraceTime, customerID: lisi4, bpID: d1, graceTime:0”与另一个日志记载“getGraceTime, customerID: zhangsan123, bpID: ss2, graceTime:0”的日志初始模板都是['get', 'grace', 'time', ',', 'customer', 'id', ':', '*', ',', ‘bp’, 'id', ':', '*', 'grace', 'time', ':', '*']，因此这两条日志记载会被聚类在同一个日志聚集里；
日志聚类的不变量提取：对于同一日志聚集里多条日志记载的单词列表相同位置的不变量提取日志模板，如对上述日志聚集对应的单词列表['get', 'grace', 'time', ',', 'customer', 'id', ':', '*', ',', ‘bp’, 'id', ':', '*', 'grace', 'time', ':', '*']和['get', 'grace', 'time', ',', 'customer', 'id', ':', '*', ',', ‘bp’, 'id', ':', '*', 'grace', 'time', ':', '*']，通过相同位置的两两比较，保存此中不变量，变化的单词位置则更换为通配符‘*’，最后得到该日志聚集里日志记载的日志模板“getGraceTime, customerID: *, bpID: *, graceTime:0”；
可变深度模板前缀树构建：以日志模板诸的每个单词（包括常量和通配符）为节点构建可变深度模板前缀树，逐个插入上述过程中得到的日志模板，建立单词列表到日志模板的映射，可以在线对日志单词列表推理其日志模板。此中可变深度指单个通配符节点答应匹配更多或更少的单词，从而能实现在线提取变长变量的日志记载的模板。
（2）日志分析模型的练习

上述离线学习模块是与数据库日志布局和内容相干的，功能在发布时，会自带一个小的预练习模型。此模型的练习和使用过程对用户是透明的，用户无需任何额外操纵。
（3）在线检测模块

日志解析阶段的数据预处理：与离线学习模块同等，根据预设正则表达式去除噪声变量和拆分日志记载文本字符串得到单词列表；
日志解析阶段的可变深度模板前缀树推理：通过模板前缀树匹配单词列表，将每个日志记载的单词列表映射到日志模板。如果出现变量数目有变化的日志，如“2020 04 23 17:01:11 INFO getGraceTime, customerID: lisi4,zhangsan3, bpID: d1, graceTime:0”,可变深度模板前缀树会答应单个通配符节点“*”匹配更多的单词（这个例子里则是“lisi4”和“zhangsan3”）提取出日志模板['get', 'grace', 'time', ',', 'customer', 'id', ':', '*', ',', ‘bp’, 'id', ':', '*', 'grace', 'time', ':', '0']。别的如果前缀树无法搜索到相应日志模板，则代表该日志模板为离线学习数据里没有出现过，会被标记为新增非常日志。    
日志分析时，对已经在内存中模板化后的日志进行分析处理，提取我们渴望使用的日志模板，进行指标量化。
2.5 慢SQL发现  

慢SQL发现基于数据库的汗青SQL语句，通过对汗青SQL语句的执行表现进行总结归纳，将之再用于推断新的未知业务上。由于短时间内数据库SQL语句执行时长不会有太大的差距，SQLdiag可以从汗青数据中检测出与已执行SQL语句相似的语句效果集，并基于SQL向量化技术和模板化方法猜测SQL语句执行时长。慢SQL发现不须要SQL语句的执行计划，对数据库性能不会有任何的影响。
慢SQL发现的时序执行图如下：    

在整个慢sql发现过程中，存在两个主要步调：

• 练习阶段：通过用户输入的日志地址导入汗青sql数据，练习自编码模型，聚类模型及执行时间序列模型。
  
• 猜测阶段：用户输入待猜测负载，体系根据练习阶段生成的自编码模型对待猜测负载进行编码，之后根据练习阶段生成的聚类模型进行分类，进而根据每类的汗青信息猜测执行时间。
  

慢SQL发现中的练习阶段和猜测阶段的具体计划如下：
（1）练习阶段

条件条件：用户已导入数据，准备好自己的典型业务SQL汗青记载，且输入格式为：(SQL执行时长，SQL语句，SQL锁等候时长)，此中锁等候时长和SQL执行时长二者必须保证至少有一个不为0. 每一行通过跳格(TAB)分隔。    
用户在Console页面输入汗青日志文件的路径与渴望模型文件保存的路径。
前处理模块起首对日志进行前处理，抽取初级特性并对语句进行模板化，然后将模板化后的语句进行向量化处理，保存向量化过程所使用的字典。将数据集向量传入自编码模块。
自编码模块对数据集数据进行自编码练习，保存自编码模型并将编码后的数据集传给聚类模块。
聚类模块对编码后的数据集进行聚类，保存聚类模型。数据集在分类后，每类分别抽取全部类语句的汗青执行时间记载，建立时间序列猜测模型。
（2）猜测流程

条件条件：练习阶段已完成，而且用户输入的待猜测负载格式准确。
用户在页面输入待猜测负载文件路径与效果文件保存路径。
与练习阶段同样，前处理模块会对待猜测负载模板化，随后读取保存的字典将模板化后的语句向量化。在此步调中，如果前处理模块捕获到新元素的数目大于用户设定的重练习阈值，会提示用户该环境并询问用户是否重新练习。如果选是，则会重新开始练习阶段，否则继承执行猜测阶段；如果前处理模块捕获到新元素的数目不大于用户设定的重练习阈值，执行猜测阶段。
读取练习阶段生成的自编码模型及聚类模型，对待猜测负载进行编码后分类。
使用各类的时间序列猜测模型，猜测待猜测负载的执行时间，保存至用户指定路径。
自编码器在计划时，可以采用2种不同的模型，分别为：
Doc2vec：着重于前后文特性关系的文本向量化编码器。
LSTM：着重于练习样本本身特性关系的向量化自编码器。
模型对好比下表所示：    

模型	优点	缺点
Doc2Vec	练习和猜测速度快，模型简朴可控	容易产生过分解读短期词语，遗失距离较远的单词间关系的问题。
LSTM	计算量大、练习速度较慢，模型须要调优，对计划和实现的要求较高。	避免了Doc2Vect的主要缺点，使用逐层降维再还原的隐藏层练习语句中全部词语的内部关系。

聚类的计划流程图如下：

    

对恣意一个新SQL模板，计算它的访问频次汗青与现有聚类中心的距离，判断是否超过阈值。
检测已聚类的模板与聚类中心点的距离，如果相似度低于阈值,则移除当前聚类。
计算聚类中心之间的距离，如果超过阈值，则归并两个聚类。
通过以上三个步调可以确保该online聚类算法能够对数据做到自适应，而且确保聚类中的模板与聚类中心始终是相似的。
猜测模型采用3种不同出发点的模型，分别为：

• 线性：线性意味着假定输入与输出之间存在一定线性关系。
  
• 影象：模型是否能够综合输入与它从汗青数据中保存下的信息来猜测未来。
  
• 核函数：模型支持核函数就可以对非线性关系进行分析。
  

通常，线性模型能够有效的避免过拟合，而且对计算资源和练习数据要求较低，在猜测较近的未来时间时表现较好。具有影象性的模型可以挖掘数据的动态行为信息，但是增加了练习的复杂性与模型对数据的依赖。较好的一个方案是采用ENSEMBE方法，将多个模型进行归并做平均猜测。    
2.6 慢SQL诊断  

慢SQL诊断提供诊断慢SQL所须要的须要信息，资助开辟者回溯执行时间超过阈值的SQL，诊断SQL性能瓶颈，用户无需通过复现就能离线诊断特定慢SQL的性能问题。慢SQL提供表和函数两种维度的查询接口，用户从接口中能查询到作业的执行计划，开始、结束执行时间，执行查询的语句，行运动，内核时间，CPU时间，执行时间，解析时间，编译时间，查询重写时间，计划生成时间，网络时间，IO时间，网络开销，锁开销等。全部信息都是脱敏的。
慢SQL诊断的执行流程如下：

在慢SQL根因诊断过程中，主要包括以下步调：
（1）获取慢SQL相干信息

慢SQL相干信息包括SQL文本信息、SQL执行计划、SQL执行开始时间、SQL执行结束时间、SQL执行计划；
（2）获取数据库关键指标信息    

数据库关键指标信息包括数据库部分GUC参数、状态参数、资源指标、负载指标、节点上别的历程信息，典型指标信息如下表所示：

参数范例	参数名称	参数解释
Guc参数	Work_mem	写入临时文件之前内部排序操纵和散列表使用的内存量
	Shared_buffers	数据库共享内存
	max_connections	最大客户端连接数
状态参数	QPS	数据库每秒哀求数
	Current_connection	数据库当前连接数
资源指标	Cpu usage	数据库cpu使用率
	Memory_usage	数据库内存使用率
	IO	数据库磁盘IO（IO read和IO write）
	Disk_usgae	数据库磁盘使用率

（3）联合数据库关键指标信息和执行计划，分析慢SQL根因；

在慢SQL文本、执行计划和其他信息的基础上，基于特定规则对慢SQL的根因进行分析，涉及到的规则如下：

• 环境一：执行计划中出现SeqScan算子，且该算子执行代价较大或扫描行数较大，该场景下扫描算子IO占用高，引起性能慢；
  

暗昧查询like，建议避免暗昧查询或全暗昧查询；
查询中包罗is not null，建议不要使用is not null，否则会导致索引失效;
查询条件中使用了不即是操纵符（!=），SQL中的不等操纵符限制索引，引起全表扫描，建议把不等操纵符改成or;    
or语句连接条件中包罗列没有全部创建索引，建议相干列全部创建索引;
update语句update了全部字段，建议如果只更改了1、2个字段，不要update全部字段、否则频繁调用会引起显着的性能消耗；
select count(*) from table，建议如果不是须要的话请杜绝此操纵;
where子句中对字段进行表达式操纵，这将导致SQL引擎放弃使用索引而使用全表扫描，建议修改where子句，对字段不要进行表达式操纵；
where子句中使用函数操纵，导致SQL引擎放弃使用索引而进行全表扫描，建议避免在where子句中使用函数操纵；
not in 导致全表扫描，建议对于连续性的数值，可以使用between代替；
范围查询语句中的range条件范围过大；

• 环境二：查询语句执行计划sort算子代价较大，同时在该SQL执行期间，数据目录下的base/pgsql_tmp路径下产生了临时文件;该场景下盘触发读写IO，引起的性能慢；
  

此时可能缘故原由是查询语句排序成本过高，导致出现慢SQL，建议调解work_mem的巨细；

• 环境三：两表join操纵，选择了NestLoop方式，且执行代价较大，该场景计算慢，引起的性能慢；
  

此时可能缘故原由是大表join操纵，NestLoop算子执行较慢，导致慢SQL，建议通过设置GUC参数enable_nestloop=off关掉NestLoop，让优化器选择其他join方式；

• 环境四：Agg操纵使用Sort Aggregate算子，且执行代价较大；
  

此时可能缘故原由是对于较大效果集的Aggregate操纵，Sort Aggregate算子的性能较差，建议通过设置GUC参数enable_sort=off，让优化器选择HashAgg算子；    

• 环境五：执行计划正常，不存在代价较大算子；
  

相干列中存在大量重复索引，导致插入性能速度变慢，建议先删除重复索引后再进行插入操纵；
数据库负载哀求会合，引起IO、CPU、MEMORY等资源指标上升，导致数据库资源紧张从而产生慢SQL；
外部历程占用大量体系资源，导致数据库资源紧张，进而出现慢SQL，建议制止没有须要的大历程；
慢SQL根因分析有两种使用方式，第一种方式是定期从sqlite数据库中拉取慢SQL信息，并基于上述规则去分析慢SQL根因，最后将效果输出到日志；第二种方式是通过用户输入慢SQL信息，然后基于特定规则去分析慢SQL根因，最后将效果输出到命令行；
使用时将Anomaly-detection中的main.py作为统一步调入口，与慢SQL诊断相干参数如下表所示，命令如下：

1. python main.py [-m MODE] [-q QUERY] [-s START_TIME] [-e END_TIME]

复制代码

参数名称	释义
-m MODE	指定运行模式 [collect, server]，此中collect是数据收罗服务，server是数据网络服务、资源非常检测和慢SQL诊断服务，后续也媾和web server对接，将网络数据表现在网页中。
diagnosis	用户自行调用慢SQL根因分析功能
-q QUERY	SQL文本信息
-s START_TIME	SQL执行开始的时间（参考作用，可选）
-e END_TIME	SQL执行结束的时间（参考作用，可选）

Collect模式用于在数据库节点本地网络信息方式；Server模式用于数据存储、非常检测和慢SQL诊断，后续还会扩展其他功能。    
基于主动收罗后，Server自主发现问题，示例效果如下所示：

1. {START-TIME: 2021-03-22 16:58:19， END-TIME: 2021-03-25 16:58:19,SQL: select i_id from bmsql_item where i_id not in(1,100)，RCA: The plan contains SeqScan operator, possibly caused by ‘NOT IN’，Suggestion: For the continuous values, ‘BETWEEN’ is recommended}

复制代码

用户自行调用慢SQL根因分析功能：

1. python main.py diagnosis -q ‘select i_id from bmsql_item where i_id not in(1,100)’ -s ‘2021-03-22 16:58:19’ -e ‘2021-03-25 16:58:19’

复制代码

输出效果如下：

RCA：The plan contains SeqScan operator，and is possibly caused by NOT IN, Suggestion: For the continuous values, BETWEEN is recommended. 复制代码

上述示例中，用户输入了SQL执行的起止时间，工具会在数据库WDR报告中在该时间范围内进行搜寻，以发现SQL的准确执行时间和结束时间，之后基于上述规则进行分析；如果用户在命令行中只输入了一种时间，则工具会以该时间为基准，在正负2小时之内进行搜寻，以匹配该SQL的准确时间信息；如果用户没有提供任何的时间信息，则工具会以现在时间为基准，往前推24小时进行搜寻，以确定该SQL的准确执行时间信息；如果在搜寻时间范围内都没有发现该条SQL，则会在命令行输出如下信息：

Error: Sorry, can not find the information of this slow SQL. 复制代码

同时该功能只支持单条SQL的分析，如果同时输入多条SQL，则只会对第一条进行分析。      
2.7 集群故障根因诊断  

在现网业务中须要对发生的故障缘故原由进行快速定位定界，集群故障根因诊断功能可以通过网络数据库集群中各个组件（如CMS、DN）等的信息和即时状态（如网络连通性），来判断集群环境是否存在故障，以及故障根因。可用于实现集群级别的故障根因诊断。    
自治运维服务支持CN、DN、CMS等节点日志收罗，以及支持基于节点间网络连通（如ping）状态收罗。经过故障场景分析和梳理，并对数据集进行枚举扩充，终极实现DN、CN故障快速定位。
集群故障根因诊断的计划和交互图如下：

自治运维服务通过收罗各个组件（如DN、CN、CMS等）的关键日志信息，以及即时状态信息（如网络连通状态），构建集群状态特性，然后，根据DBMind预置的根因模型库，对问题根因进行判断。对于日志信息的收罗对日志格式有一定要求，当日志格式发生变化时，须要代码同步更新以实现收罗。下表中的“包罗关键词”列即为收罗日志所使用的正则匹配格式。
此中，DN组件故障场景特性与根因分别下表所示：

名称	日志种类	包罗关键词(DN组件故障场景特性)
非日志	非日志	DN节点状态: Normal、Unknown、Need repair、Wait promoting、Promoting or Demoting、Disk damaged、Port conflicting、Building、Build failed、CoreDump、ReadOnly、Manually stopped         注意：Normal外的状态都视为非常
CMA日志	CMA日志	datanodeId=(.*?), dn_manual_stop=([0,1]), g_dnDiskDamage=([0,1]), g_nicDown=([0,1]), port_conflict=([0,1])
CMA日志	CMA日志	datanodeId=(.*?), dn_manual_stop=([0,1]), g_dnDiskDamage=([0,1]), g_nicDown=([0,1]), port_conflict=([0,1])
CMA日志	CMA日志	datanodeId=(.*?), dn_manual_stop=([0,1]), g_dnDiskDamage=([0,1]), g_nicDown=([0,1]), port_conflict=([0,1])
system_call日志	system_call日志	could not bind (.*?) socket: Is another instance already running on port (.*?)
CMA日志	CMA日志	datanodeId=(.*?), dn_manual_stop=([0,1]), g_dnDiskDamage=([0,1]), g_nicDown=([0,1]), port_conflict=([0,1])
CMS日志	CMS日志	restart (.*?), there is not report msg for
CMS日志	CMS日志	restart to pending
CMS日志	CMS日志	(instance|instanceId (.*?) (is transaction |set |was set |is )read only
非日志	非日志	DN节点IP是否可以Ping通
ffic日志	ffic日志	恣意内容
内核日志	内核日志	walreceiver could not connect and shutting down
CMA日志	CMA日志	data path disc writable test failed

DN根因和特性的关系流程图如下：    

DN故障诊断部分特性和根因对应关系如下表，对于日志类特性，0代表对应日志不包罗关键字，1代表对应日志包罗关键字，对于其他非日志类特性，0代表否，1代表是，最后不同标签数值代表不同的根因。如下表为DN组件特性与根因对应关系示例：

非日志	DN节点状态:	0	0	0	0	0	0	0	0
CMA日志	datanodeId=(.*?), dn_manual_stop=([0,1]), g_dnDiskDamage=([0,1]), g_nicDown=([0,1]), port_conflict=([0,1])	0	0	0	0	0	0	0	0
CMA日志	datanodeId=(.*?), dn_manual_stop=([0,1]), g_dnDiskDamage=([0,1]), g_nicDown=([0,1]), port_conflict=([0,1])	0	0	0	0	0	0	0	0
CMA日志	datanodeId=(.*?), dn_manual_stop=([0,1]), g_dnDiskDamage=([0,1]), g_nicDown=([0,1]), port_conflict=([0,1])	0	0	0	0	0	0	0	0
system_call日志	could not bind (.*?) socket: Is another instance already running on port (.*?)	0	0	0	0	0	0	0	0
CMA日志	datanodeId=(.*?), dn_manual_stop=([0,1]), g_dnDiskDamage=([0,1]), g_nicDown=([0,1]), port_conflict=([0,1])	0	0	0	0	0	0	0	0
CMS日志	restart (.*?), there is not report msg for	0	0	0	0	0	0	0	0
	phony dead times\(.*?:.*?\) already exceeded, will restart\((.*?)\)
CMS日志	restart to pending	0	0	0	0	0	0	0	0
CMS日志	(instance|instanceId (.*?) (is transaction |set |was set |is )read only	0	0	0	0	0	0	0	0
非日志	DN节点IP是否可以Ping通	0	0	0	0	0	1	1	1
ffic日志	恣意内容	0	0	0	1	1	0	0	0
内核日志	walreceiver could not connect and shutting down	0	1	1	1	1	0	0	1
CMA日志	data path disc writable test failed	1	0	1	0	1	0	1	0
标签	对应故障效果	2	10	10	10	10	9	9	9

通过上述根因和特性之间关联，使用决策树模型，根据故障日志信息，快速获取故障根因，方便运维人员及时进行故障清除。
以上内容从日志分析、慢SQL发现、慢SQL诊断、集群故障根因诊断等方面介绍了GaussDB的自治运维技术，下篇我们将从索引保举、分布键保举、参数调优等三方面继承解读GaussDB的自治运维技术。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 IT评测·应用市场-qidao123.com技术社区 (https://dis.qidao123.com/)

Powered by Discuz! X3.4