根据 dba_errors 制定 数据库报警邮件

一.dba_errors表

官网对这个表的说明如下:

ALL_ERRORS:describes the current errors on the stored objects accessible to the current user.

DBA_ERRORS:describes the current errors on all stored objects in the database.

USER_ERRORS:describes the current errors on the stored objects owned by the current user.This view does not display the OWNER column.

示例:

SQL> select owner,name,type,text,attribute from dba_errors;

OWNERNAMETYPETEXTATTRIBUTE

---------- ------------------------- ------------ -------------------------------------------------- ---------

SYSPROC_ALARM_KC_SCBPROCEDUREPL/SQL: ORA-00942: table or view does not existERROR

SYSPROC_ALARM_KC_SCBPROCEDUREPL/SQL: SQL Statement ignoredERROR

SYSPROC_ALARM_KC_SCBPROCEDUREPLS-00201: identifier 'JOBLOG.WRITELOG' must be de ERROR

SYSPROC_ALARM_KC_SCBPROCEDUREPL/SQL: Statement ignoredERROR

SYSPROC_ALARM_KC_SCBPROCEDUREPLS-00201: identifier 'RUNLOG.ERRORLOG' must be de ERROR

SYSPROC_ALARM_KC_SCBPROCEDUREPL/SQL: Statement ignoredERROR

从这个表里面,我们可以看到数据库当前存在的错误,这些错误信息包含对象名称,类型,所有者,错误类型和错误原因。

如果该表里有这些错误,就可以调用Oracle的发送邮件的存储过程,将这些信息发送到相关邮箱或者移动的139邮箱,该邮箱可以直接将邮件发送到手机。这样就可以起到一个及时通知的作用。

发送邮件的存储过程参考Blog:

Oracle发送邮件存储过程

http://blog.youkuaiyun.com/xujinyang/article/details/6830560

二.存储过程

/* Formatted on 2011/5/19 20:48:30 (QP5 v5.163.1008.3004) */

CREATEORREPLACEPROCEDUREgetsenterrlog

AS

email_titleVARCHAR2(100);--email标题

email_contentVARCHAR2(1000);--email内容

email_serverVARCHAR2(20);-- email服务器

email_senderVARCHAR2(20);--email发送邮箱

email_userVARCHAR2(20);--email用户

email_pwdVARCHAR2(20);--emai密码

email_receiver1VARCHAR2(100);--email接收人

email_receiver2VARCHAR2(100);--email接收人

email_receiver3VARCHAR2(100);--email接收人

CURSORc1

IS

SELECT*FROMdba_errors;

BEGIN

/**

过程内容:查询dba_errors表,如果有错误,就发送到139邮箱

作者:Dave

时间:2011-5-19

*/

email_server:='192.168.1.100';

email_sender:='dvd.dba@gmail.com';

email_user:='tianlesoftware';

email_pwd:='pwd';

email_receiver1:=

'13888888888@139.com;dvd.dba@gmail.com';

email_receiver2:=

'13888888888@139.com;dvd.dba@gmail.com';

email_receiver3:=

'13888888888@139.com;dvd.dba@gmail.com';

FORxINc1

LOOP

IFx.owner='SYS'

THEN

email_title:=x.owner||',s '|| x.TYPE||': '|| x.name||' report '|| x.attribute||'!';

email_content:=x.text;

--DBMS_OUTPUT.put_line (email_title);

--DBMS_OUTPUT.put_line (email_content);

procsendemail(email_content,email_title,email_sender,email_receiver1,email_server,25,1,email_user,email_pwd,'','bit 7');

ELSIFx.owner='SYSTEM'

THEN

email_title:=x.owner||',s '|| x.TYPE||': '|| x.name||' report '|| x.attribute||'!';

email_content:=x.text;

--DBMS_OUTPUT.put_line (email_title);

--DBMS_OUTPUT.put_line (email_content);

--调用发送邮件过程

procsendemail(email_content,email_title,email_sender,email_receiver2,email_server,25,1,email_user,email_pwd,'','bit 7');

ELSE

email_title:=x.owner||',s '|| x.TYPE||': '|| x.name||' report '|| x.attribute||'!';

email_content:=x.text;

--DBMS_OUTPUT.put_line (email_title);

--DBMS_OUTPUT.put_line (email_content);

procsendemail(email_content,email_title,email_sender,email_receiver3,email_server,25,1,email_user,email_pwd,'','bit 7');

ENDIF;

ENDLOOP;

EXCEPTION

WHENNO_DATA_FOUND

THEN

RETURN;

WHENOTHERS

THEN

RETURN;

END;

不同用户的错误,发送到相关的责任人,当然DBA肯定都要收到。

三.使用Scheduler Job部署

Oracle 10g Scheduler特性

http://blog.youkuaiyun.com/xujinyang/article/details/6830222

3.1创建Job:

BEGIN

DBMS_SCHEDULER.CREATE_JOB (

job_name => 'Jobgetsenterrlog',

job_type => 'STORED_PROCEDURE',

job_action =>'GETSENTERRLOG',--调用的过程名称

start_date => sysdate,

repeat_interval => 'FREQ=MINUTELY;INTERVAL=1');--每个一分钟执行一次

END;

/

关于这些参数的说明,参考上面的链接。

注意:

JOB虽然成功创建了,但却并未执行.因为ENABLED参数当不显式指定时,该参数的默认值为false。

3.2启用Job

exec dbms_scheduler.enable('Jobgetsenterrlog');

3.3停止Job

exec dbms_scheduler.disable(' Jobgetsenterrlog');



-------------------------------------------------------------------------------------------------------

<think> 我们正在处理关于 `container_network_transmit_errors_total` 的查询。根据用户要求,我们需要提供该指标的含义、监控意义、处理方法等,并参考之前的回答结构(关于`container_network_receive_packets_dropped_total`)来组织内容。 指标名称:container_network_transmit_errors_total 类型:Counter(计数器) 含义:该指标表示容器自启动以来在发送方向(outbound)累计发生的网络错误数量(如发送错误)。这些错误可能包括各种发送过程中遇到的问题,例如冲突、帧错误等。 数据来源:通常由cAdvisor从容器网络接口的统计信息中采集,具体对应Linux网络接口的`tx_errors`统计值。 标签:通常包括`pod_name`(Pod名称)、`namespace`(命名空间)、`interface`(网络接口,如eth0)等。 监控意义: - 发送错误通常指示网络问题,可能包括物理网卡问题、网络拥塞、配置错误等。 - 高错误率可能导致数据包重传,影响网络吞吐量和应用性能。 - 持续的错误可能意味着网络设备故障或电缆问题。 处理方法: - 检查容器所在节点的物理网络设备状态。 - 检查网络拥塞情况(如交换机端口错误计数)。 - 调整容器网络配置(如增加缓冲区大小)。 - 升级网络驱动或固件。 与之前指标`container_network_receive_packets_dropped_total`类似,我们可以构建类似的监控和告警。 下面我们按照之前回答的结构来组织内容: ### `container_network_transmit_errors_total` 详解 #### **1. 指标含义** `container_network_transmit_errors_total` 是容器网络健康度的关键指标,表示**容器自启动以来在发送方向(outbound)累计发生的网络错误数量**: - **数据类型**:计数器(Counter),数值单调递增 - **单位**:错误次数 - **采集来源**:由 cAdvisor 从容器网络接口的 `tx_errors` 统计值中采集[^1] - **关键标签**: - `pod_name`:所属 Pod 名称 - `interface`:网络接口名(如 eth0) - `namespace`:Kubernetes 命名空间 #### **2. 核心用途** | **场景** | **应用说明** | |------------------------|-----------------------------------------------------------------------------| | **网络质量诊断** | 高错误率指示网络设备故障、线缆问题或配置错误 | | **性能瓶颈定位** | 发送错误导致数据包重传,增加延迟并降低吞吐量 | | **资源规划依据** | 持续错误可能需更换硬件或升级驱动 | | **安全威胁检测** | 错误突增可能是网络攻击(如洪泛攻击)的迹象 | | **微服务弹性评估** | 发送错误可能影响服务间调用,需结合服务网格指标分析 | #### **3. 监控方法** ##### (1) PromQL 基础查询 ```promql -- 查看容器发送错误增长速率(次/秒) rate(container_network_transmit_errors_total[1m]) -- 计算发送错误率(错误次数占发送总包数的百分比) 100 * rate(container_network_transmit_errors_total[5m]) / rate(container_network_transmit_packets_total[5m]) ``` ##### (2) 典型分析场景 **节点级错误监控**: ```promql -- 按节点统计发送错误最严重的Top3容器 topk(3, sum by(instance, pod_name) ( rate(container_network_transmit_errors_total[10m]) ) ) ``` ##### (3) 关联指标分析 需结合以下指标综合诊断: - `container_network_transmit_packets_total`:发送包量,用于计算错误率 - `container_network_transmit_bytes_total`:发送流量过大可能导致错误 - `node_network_transmit_errors_total`:宿主机级别发送错误,用于判断是否宿主机问题 - `container_cpu_usage_seconds_total`:CPU资源不足可能导致发送队列处理错误 #### **4. 运维实践** **异常检测规则**: ```yaml - alert: HighNetworkTransmitErrorRate expr: | # 发送错误率持续高于0.1%触发告警 100 * rate(container_network_transmit_errors_total[5m]) / rate(container_network_transmit_packets_total[5m]) > 0.1 for: 10m labels: severity: warning annotations: summary: "容器网络发送错误率过高 ({{ $labels.pod_name }}: {{ $value }}%)" ``` **故障排查案例**: - **现象**:某服务发送错误率持续高于5%,导致服务间调用超时 - **分析**: - 检查关联指标`container_network_transmit_bytes_total`,发现发送流量在正常范围 - 检查宿主机`node_network_transmit_errors_total`,发现相同时间点宿主机网卡无错误 - 进一步检查发现容器使用的网络接口(veth)驱动存在已知问题 - **解决**: - 升级宿主机内核及网卡驱动 - 调整容器网络配置,增加发送队列长度(`txqueuelen`) > 优化后错误率降至0.05%,服务超时率下降90% #### **5. 技术原理** - **数据来源**:cAdvisor 读取容器 cgroup 网络统计文件: `/sys/fs/cgroup/devices/<container_id>/net_dev` 关键字段关系: | Linux 统计项 | 对应指标 | |---------------------|------------------------------------------| | `tx_packets` | `container_network_transmit_packets_total` | | `tx_errors` | `container_network_transmit_errors_total` | - **常见错误原因**: 1. 网卡发送队列溢出(`txqueuelen`设置过小) 2. 物理网卡故障或线缆损坏 3. 网络驱动缺陷(需升级内核或驱动) 4. 交换机端口配置错误(如双工模式不匹配) > **注意事项**: > - 容器重启时计数器归零 > - 错误率 >0.1% 即需关注,>1% 必须立即处理 > - K8s CNI 插件问题可能导致发送错误 > - 需区分发送错误(`tx_errors`)和接收错误(`rx_errors`) --- [^1]: cAdvisor 网络指标采集原理 [^2]: Linux 网络栈错误诊断指南 §§相关问题§§ 1. 如何区分容器网络发送错误是发生在宿主机还是容器内部? 2. 除了 `container_network_transmit_errors_total`,还有哪些指标可用于诊断网络发送问题? 3. 如何优化容器网络配置以减少发送错误? 4. 容器网络发送错误与微服务调用失败有何关联? </think>### `container_network_transmit_errors_total` 详解 #### **1. 指标含义** `container_network_transmit_errors_total` 是容器网络发送方向的关键指标,表示**容器自启动以来在发送方向(outbound)累计发生的网络错误数量**[^1]: - **数据类型**:计数器(Counter),数值单调递增 - **单位**:错误次数 - **采集来源**:由 cAdvisor 从容器网络接口的 `tx_errors` 统计值中采集 - **关键标签**: - `pod_name`:所属 Pod 名称 - `interface`:网络接口名(如 eth0) - `namespace`:Kubernetes 命名空间 #### **2. 核心用途** | **场景** | **应用说明** | |------------------------|-----------------------------------------------------------------------------| | **网络质量诊断** | 高错误率指示网络设备故障、线缆问题或配置错误 | | **性能瓶颈定位** | 发送错误导致数据包重传,增加延迟并降低吞吐量 | | **资源规划依据** | 持续错误可能需更换硬件或升级驱动 | | **安全威胁检测** | 错误突增可能是网络攻击(如洪泛攻击)的迹象 | | **微服务弹性评估** | 发送错误可能影响服务间调用,需结合服务网格指标分析 | #### **3. 监控方法** ##### (1) PromQL 基础查询 ```promql -- 查看容器发送错误增长速率(次/秒) rate(container_network_transmit_errors_total[1m]) -- 计算发送错误率(错误次数占发送总包数的百分比) 100 * rate(container_network_transmit_errors_total[5m]) / rate(container_network_transmit_packets_total[5m]) ``` ##### (2) 典型分析场景 **节点级错误监控**: ```promql -- 按节点统计发送错误最严重的Top3容器 topk(3, sum by(instance, pod_name) ( rate(container_network_transmit_errors_total[10m]) ) ) ``` ##### (3) 关联指标分析 需结合以下指标综合诊断: - `container_network_transmit_packets_total`:发送包量,用于计算错误率 - `container_network_transmit_bytes_total`:发送流量过大可能导致错误 - `node_network_transmit_errors_total`:宿主机级别发送错误,用于判断是否宿主机问题 - `container_cpu_usage_seconds_total`:CPU资源不足可能导致发送队列处理错误 #### **4. 运维实践** **异常检测规则**: ```yaml - alert: HighNetworkTransmitErrorRate expr: | # 发送错误率持续高于0.1%触发告警 100 * rate(container_network_transmit_errors_total[5m]) / rate(container_network_transmit_packets_total[5m]) > 0.1 for: 10m labels: severity: warning annotations: summary: "容器网络发送错误率过高 ({{ $labels.pod_name }}: {{ $value }}%)" ``` **故障排查案例**: - **现象**:某服务发送错误率持续高于5%,导致服务间调用超时 - **分析**: - 检查关联指标`container_network_transmit_bytes_total`,发现发送流量在正常范围 - 检查宿主机`node_network_transmit_errors_total`,发现相同时间点宿主机网卡无错误 - 进一步检查发现容器使用的网络接口(veth)驱动存在已知问题 - **解决**: - 升级宿主机内核及网卡驱动 - 调整容器网络配置,增加发送队列长度(`txqueuelen`) > 优化后错误率降至0.05%,服务超时率下降90% #### **5. 技术原理** - **数据来源**:cAdvisor 读取容器 cgroup 网络统计文件: `/sys/fs/cgroup/devices/<container_id>/net_dev` 关键字段关系: | Linux 统计项 | 对应指标 | |---------------------|------------------------------------------| | `tx_packets` | `container_network_transmit_packets_total` | | `tx_errors` | `container_network_transmit_errors_total` | - **常见错误原因**: 1. 网卡发送队列溢出(`txqueuelen`设置过小) 2. 物理网卡故障或线缆损坏 3. 网络驱动缺陷(需升级内核或驱动) 4. 交换机端口配置错误(如双工模式不匹配) > **注意事项**: > - 容器重启时计数器归零 > - 错误率 >0.1% 即需关注,>1% 必须立即处理 > - K8s CNI 插件问题可能导致发送错误 > - 需区分发送错误(`tx_errors`)和接收错误(`rx_errors`) --- [^1]: Linux 网络设备统计文档 [^2]: Kubernetes 网络故障排查指南
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值