测试环境中出现了一个异常的告警现象：一条告警通过 Thanos Ruler 的 HTTP 接口观察到持续处于 active 状态，但是从 AlertManager 这边看这条告警为已解决状态。按照 DMP 平台的设计，告警已解决指的是告警上设置的结束时间已经过了当前时间。一条发送至 AlertManager 的告警为已解决状态有三种可能：1. 手动解决了告警2. 告警只产生了一次，第二次计算告警规则时会发送一个已解决的告警3. AlertManager 接收到的告警会带着一个自动解决时间，如果还没到达自动解决时间，则将该时间重置为 24h 后首先，因为了解到测试环境没有手动解决过异常告警，排除第一条；其次，由于该告警持续处于 active 状态，所以不会是因为告警只产生了一次而接收到已解决状态的告警，排除第二条；最后，告警的告警的产生时间与自动解决时间相差不是 24h，排除第三条。那问题出在什么地方呢？
创新互联服务项目包括南平网站建设、南平网站制作、南平网页制作以及南平网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，南平网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到南平省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！
分析
下面我们开始分析这个问题。综合第一节的描述，初步的猜想是告警在到达 AlertManager 前的某些阶段的处理过程太长，导致告警到达 AlertManager 后就已经过了自动解决时间。我们从分析平台里一条告警的流转过程入手，找出告警在哪个处理阶段耗时过长。首先，一条告警的产生需要两方面的配合：
metric 数据
告警规则
将 metric 数据输入到告警规则进行计算，如果符合条件则产生告警。DMP 平台集成了 Thanos 的相关组件，数据的提供和计算则会分开，数据还是由 Prometheus Server 提供，而告警规则的计算则交由 Thanos Rule（下文简称 Ruler）处理。下图是 Ruler 组件在集群中所处的位置：
看来，想要弄清楚现告警的产生到 AlertManager 之间的过程，需要先弄清除 Ruler 的大致机制。官方文档对 Ruler 的介绍是：You can think of Rule as a simplified Prometheus that does not require a sidecar and does not scrape and do PromQL evaluation (no QueryAPI)。
不难推测，Ruler 应该是在 Prometheus 上封装了一层，并提供一些额外的功能。通过翻阅资料大致了解，Ruler 使用 Prometheus 提供的库计算告警规则，并提供一些额外的功能。下面是 Ruler 中告警流转过程：
请点击输入图片描述
请点击输入图片描述
首先，图中每个告警规则 Rule 都有一个 active queue（下面简称本地队列），用来保存一个告警规则下的活跃告警。
其次，从本地队列中取出告警，发送至 AlertManager 前，会被放入 Thanos Rule Queue（下面简称缓冲队列），该缓冲队列有两个属性：
capacity（默认值为 10000）：控制缓冲队列的大小，
maxBatchSize（默认值为 100）：控制单次发送到 AlertManager 的最大告警数
了解了上述过程，再通过翻阅 Ruler 源码发现，一条告警在放入缓冲队列前，会为其设置一个默认的自动解决时间（当前时间 + 3m），这里是影响告警自动解决的开始时间，在这以后，有两个阶段可能影响告警的处理：1. 缓冲队列阶段2. 出缓冲队列到 AlertManager 阶段（网络延迟影响）由于测试环境是局域网环境，并且也没在环境上发现网络相关的问题，我们初步排除第二个阶段的影响，下面我们将注意力放在缓冲队列上。通过相关源码发现，告警在缓冲队列中的处理过程大致如下：如果本地队列中存在一条告警，其上次发送之间距离现在超过了 1m（默认值，可修改），则将该告警放入缓冲队列，并从缓冲队列中推送最多 maxBatchSize 个告警发送至 AlertManager。反之，如果所有本地队列中的告警，在最近 1m 内都有发送过，那么就不会推送缓冲队列中的告警。也就是说，如果在一段时间内，产生了大量重复的告警，缓冲队列的推送频率会下降。队列的生产方太多，消费方太少，该队列中的告警就会产生堆积的现象。因此我们不难猜测，问题原因很可能是是缓冲队列推送频率变低的情况下，单次推送的告警数量太少，导致缓冲队列堆积。下面我们通过两个方面验证上述猜想：首先通过日志可以得到队列在大约 20000s 内推送了大约 2000 次，即平均 10s 推送一次。结合缓冲队列的具体属性，一条存在于队列中的告警大约需要 (capacity/maxBatchSize)*10s = 16m，AlertManager 在接收到告警后早已超过了默认的自动解决时间（3m）。其次，Ruler 提供了 3 个 metric 的值来监控缓冲队列的运行情况：
thanos_alert_queue_alerts_dropped_total
thanos_alert_queue_alerts_pushed_total
thanos_alert_queue_alerts_popped_total
通过观察 thanos_alert_queue_alerts_dropped_total 的值，看到存在告警丢失的总数，也能佐证了缓冲队列在某些时刻存在已满的情况。
解决通过以上的分析，我们基本确定了问题的根源：Ruler 组件内置的缓冲队列堆积造成了告警发送的延迟。针对这个问题，我们选择调整队列的 maxBatchSize 值。下面介绍一下这个值如何设置的思路。由于每计算一次告警规则就会尝试推送一次缓冲队列，我们通过估计一个告警数量的最大值，得到 maxBatchSize 可以设置的最小值。假设你的业务系统需要监控的实体数量分别为 x1、x2、x3、...、xn，实体上的告警规则数量分别有 y1、y2、y3、...、yn，那么一次能产生的告警数量最多是(x1 * y2 + x2 * y2 + x3 * y3 + ... + xn * yn)，最多推送（y1 + y2 + y3 + ... + yn）次，所以要使缓冲队列不堆积，maxBatchSize 应该满足：maxBatchSize = (x1 * y2 + x2 * y2 + x3 * y3 + ... + xn * yn) / (y1 + y2 + y3 + ... + yn)，假设 x = max(x1,x2, ...,xn), 将不等式右边适当放大后为 x，即 maxBatchSize 的最小值为 x。也就是说，可以将 maxBatchSize 设置为系统中数量最大的那一类监控实体，对于 DMP 平台，一般来说是 MySQL 实例。
注意事项
上面的计算过程只是提供一个参考思路，如果最终计算出该值过大，很有可能对 AlertManager 造成压力，因而失去缓冲队列的作用，所以还是需要结合实际情况，具体分析。因为 DMP 将 Ruler 集成到了自己的组件中，所以可以比较方便地对这个值进行修改。如果是依照官方文档的介绍使用的 Ruler 组件，那么需要对源码文件进行定制化修改。
可能是服务器硬盘出现故障。
解决办法：
1、重启设备，进入RAID管理界面。
2、选中硬盘状态为Frn-Bad的硬盘，然后选择makeunconfiguredgood，点击回车，此时硬盘状态变为Foreign。
3、清除已存在的RAID信息，此时硬盘变为UG(UnconfigGood)状态，重新拔插该硬盘，保存退出RAID卡管理界面。
4、重启设备，此时黄灯已消失，故障解决，也就是重新做RAID，安装操作系统即可。
数据库文件系统包括:
data file (数据文件)
log file (日志文件)
control file (控制文件,用来连接实例与database)
系统文件主要就这三种。给你找了个详细答案，以oracle数据库为例
如下：
1、控制文件（参数文件init.ora记录了控制文件的位置）
控制文件包括如下主要信息
数据库的名字，检查点信息，数据库创建的时间戳
所有的数据文件，联机日志文件，归档日志文件信息
备份信息等
有了这些信息，Oracle就知道那些文件是数据文件，现在的重做日志文件是哪些，这些都是系统启动和运行的基本条件，所以他是Oracle运行的根本。如果没有控制文件系统是不可能启动的。控制文件是非常重要的，一般采用多个镜相复制来保护控制文件，或采用RAID来保护控制文件。控制文件的丢失，将使数据库的恢复变的很复杂。
控制文件信息可以从V$Controlfile中查询获得
2、数据文件（数据文件的详细信息记载在控制文件中）
可以通过如下方式查看数据文件
SQL select name from v$datafile;
NAME
---------------------------------------------
/u05/dbf/PROD/system_01.dbf
/u06/dbf/PROD/temp_01.dbf
/u04/dbf/PROD/users_01.dbf
/u09/dbf/PROD/rbs_01.dbf
/u06/dbf/PROD/applsys_indx_01.dbf
/u05/dbf/PROD/applsys_data_01.dbf
从以上可以看出，数据文件大致可以分为以下几类：
i. 系统数据文件(system_01.dbf)
存放系统表和数据字典，一般不放用户的数据，但是用户脚本，如过程，函数，包等却是保存在数据字典中的。
名词解释：数据字典 数据字典是一些系统表或视图，他存放系统的信息，他包括数据库版本，数据文件信息，表与索引等段信息，系统的运行状态等各种和系统有关的信息和用户脚本信息。数据库管理员可以通过对数据字典的查询，就可以了解到Oracle的运行状态。
ii. 回滚段文件(rbs_01.dbf)
如果数据库进行对数据的修改，那么就必须使用回滚段，回滚段是用来临时存放修改前的数据(Before Image)。回滚段通常都放在一个单独的表空间上（回滚表空间），避免表空间碎片化，这个表空间包含的数据文件就是回滚数据文件。
iii. 临时数据文件(temp_01.dbf)
主要存放用户的排序等临时数据，与回滚段相似，临时段也容易引起表空间碎片化，而且没有办法在一个永久表空间上开辟临时段，所以就必须有一个临时表空间，它所包含的数据文件就是临时数据文件，主要用于不能在内存上进行的排序操作。我们必须为用户指定一个临时表空间。
iv. 用户数据文件(/applsys_data_01.dbf ,applsys_indx_01.dbf)
存放用户数据，这里列举了两类常见的用户型数据，一般数据和索引数据，一般来说，如果条件许可的话，可以考虑放在不同的磁盘上。
3、重做日志文件（联机重做日志）
用户对数据库进行的任何操作都会记录在重做日志文件。在了解重做日志之前必须了解重做日志的两个概念，重做日志组和重做日志组成员(Member)，一个数据库中至少要有两个日志组文件，一组写完后再写另一组，即轮流写。每个日志组中至少有一个日志成员，一个日志组中的多个日志成员是镜相关系，有利于日志文件的保护，因为日志文件的损坏，特别是当前联机日志的损坏，对数据库的影响是巨大的。
联机日志组的交换过程叫做切换，需要特别注意的是，日志切换在一个优化效果不好的数据库中会引起临时的“挂起”。挂起大致有两种情况：
在归档情况下，需要归档的日志来不及归档，而联机日志又需要被重新利用
检查点事件还没有完成（日志切换引起检查点），而联机日志需要被重新利用
解决这种问题的常用手段是：
i.增加日志组
ii.增大日志文件成员大小
通过v$log可以查看日志组，v$logfile可以查看具体的成员文件。
4、归档日志文件
Oracle可以运行在两种模式之中，归档模式和不归档模式。如果不用归档模式，当然，你就不会有归档日志，但是，你的系统将不会是一个实用系统，特别是不能用于生产系统，因为你可能会丢失数据。但是在归档模式中，为了保存用户的所有修改，在重做日志文件切换后和被覆盖之间系统将他们另外保存成一组连续的文件系列，该文件系列就是归档日志文件。
有人或许会说，归档日志文件占领我大量的硬盘空间，其实，具体想一想，你是愿意浪费一点磁盘空间来保护你的数据，还是愿意丢失你的数据呢？显而义见，我们需要保证我们的数据的安全性。其实，归档并不是一直占领你的磁盘空间，你可以把她备份到磁带上，或则删除上一次完整备份前的所有日志文件。
5、初始化参数文件
initSID.ora或init.ora文件，因为版本的不一样，其位置也可能会不一样。在8i中，通常位于$ORACLE_HOME/admin//Pfile下，初始化文件记载了许多数据库的启动参数，如内存，控制文件，进程数等，在数据库启动的时候加载（Nomount时加载），初始化文件记录了很多重要参数，对数据库的性能影响很大，如果不是很了解，不要轻易乱改写，否则会引起数据库性能下降。
6、其他文件
i . 密码文件
用于Oracle 的具有sysdba权限用户的认证.
ii. 日志文件
报警日志文件（alert.log或alrt.ora）
记录数据库启动，关闭和一些重要的出错信息。数据库管理员应该经常检查这个文件，并对出现的问题作出即使的反应。你可以通过以下SQL 找到他的路径select value from v$PARAMETER where name ="background_dump_dest";
后台或用户跟踪文件
系统进程或用户进程出错前写入的信息，一般不可能读懂，可以通过ORACLE的TKPROF工具转化为可以读懂的格式。对于系统进程产生的跟踪文件与报警日志文件的路径一样，用户跟踪文件的路径，你可以通过以下SQL找到他的路径select value from v$PARAMETER where name ="user_dump_dest";
首先了解什么是外部表，与其它表的区别，建立一个简单的外部表(主要看操作过程)，最后我们用外部表查看ORACLE报警日志
1.了解oracle外部表
外部表定义：结构被存放在数据字典，而表数据被放在OS文件中的表
作用：在数据库中查询OS文件的数据，还可以将OS文件数据装载到数据库中
与其它表的区别：在外部表上不能执行DML操作，也不能在外部表上建索引，只能执行select操用
2.建一个简单的外部表1.建一个OS上的文件
因为外部表主要是查看OS上的文件，首先在OS上建一个文件
mkdir -p /oracle/ext
vi /oracle/ext/ext.dat
10,20,30
40,50,60
70,80,90
2.授予用户权限，并建立目录对象
在此我们先建一个新用户
create user test identified by “123” default tablespace test quota unlimited on test;
用户授权
SQL grant create any directory to test;
建立目录对象
SQL conn test / 123
Connected.
SQL create directory ext as '/oracle/ext';
Directory created.
3.建立外部表
SQL create table exttable(
id number,name varchar2(10)，i number
)organization external
(type oracle_loader
default directory ext
access parameters
(records delimited by newline
fields terminated by ','
)location('ext.dat')
);
4.测试
SQL select * from exttable;
ID NAMEI
---------- ---------- ----------
10 20 30
40 50 60
70 80 90
测试成功，可见在数据库中可以查询OS文件的数据
2. 使用外部表查看oracle报警日志
由于在上面实验中已建立了一个用户，并赋相应的权限，而且也有了OS文件(即报警文件alert_SID.log)，所以在此直接建立目录对象并建立外部表就可以了。
1.建立目录对象
SQL conn test / 123
Connected.
SQL create directory bdump as '/oracle/u01/app/oracle/admin/db2/bdump';
Directory created.
2.建立外部表
SQL create table alert_log(
text varchar2(400)
)organization external
(type oracle_loader
default directory bdump
access parameters
(records delimited by newline
)location('alert_db2.log')
);
3.测试
首先查看能否查到alert_db2.log的内容
SQL select * from alert_log where rownum 10;
TEXT
--------------------------------------------------------------------------------
Thu Jun 11 00:51:46 2009
Starting ORACLE instance (normal)
Cannot determine all dependent dynamic libraries for /proc/self/exe
Unable to find dynamic library libocr10.so in search paths
RPATH = /ade/aime1_build2101/oracle/has/lib/:/ade/aime1_build2101/oracle/lib/:/a
de/aime1_build2101/oracle/has/lib/:
LD_LIBRARY_PATH is not set!
The default library directories are /lib and /usr/lib
Unable to find dynamic library libocrb10.so in search paths
Unable to find dynamic library libocrutl10.so in search paths
9 rows selected.
测试成功
然后我们测试查报警信息’ORA-%’
SQL select * from alert_log where text like 'ORA-%';
TEXT
--------------------------------------------------------------------------------
ORA-00202: control file: '/oracle/u01/app/oracle/product/10.2.0/db2/dbs/cntrldb2
.dbf'
ORA-27037: unable to obtain file status
ORA-205 signalled during: ALTER DATABASE MOUNT…
ORA-00301: error in adding log file '/home/oracle/oracle/oradata/testdb/redo01.l
og' - file cannot be created
ORA-27040: file create error
ORA-1501 signalled during: CREATE DATABASE db2
ORA-00200: control file could not be created
TEXT
--------------------------------------------------------------------------------
ORA-00202: control file: '/oracle/u01/app/oracle/product/10.2.0/db2/dbs/cntrldb2
.dbf'
ORA-27038: created file already exists
ORA-1501 signalled during: CREATE DATABASE db2
ORA-00200: control file could not be created
ORA-00202: control file: '/oracle/u01/app/oracle/product/10.2.0/db2/dbs/cntrldb2
.dbf'
ORA-27038: created file already exists
ORA-1501 signalled during: CREATE DATABASE db2
测试成功，
可见我们可以使用外部表来方便的查看ORACLE的报警信息
故障排除指南ora-609：流产过程未知OsPID进行opiodr（文档ID 1121357.1）
alert.log显示ora-609与tns-12537：TNS：关闭连接（文档ID 1538717.1）
致命的Ni连接12560”和“ora-609 opiodr流产过程在警报日志错误（文档ID 987162.1）
数据库的警报日志中常会见到ora-609、ora-3136 / ora-609 tns-12537和tns-12547或tns-12170 12170，“tns-12535等相关错误，对此类型问题进行整理归纳，如下：
1。ora-609错误的排查指南：
报警日志可以看到如下错误信息：
致命的Ni连接错误12537，连接：
(LOCAL=NO)
版本信息：
TNSLinux：版本11.2.0.3.0生产
Oracle将NT协议适配器Linux：版本11.2.0.3.0生产
TCP / IP协议适配器的Linux版本NT：11.2.0.3.0生产
时间：26-feb-2013 02:23:51
追踪未打开
TNS错误结构：
主要错误代码：12537 ns
tns-12537：TNS：连接关闭
错误代码：12560 ns级
主要错误代码：0新台币
NT错误代码：0次
NT操作系统错误代码：0
流产过程未知OsPID进行opiodr（28725）由于ora-609
第一个解释这种错误
消息
流产过程未知OsPID进行opiodr（.....）由于ora-609
只是一个通知，Oracle数据库关闭（终止）专用工艺由于ora-609。
ora-609意味着“无法连接到传入的连接”这样的数据库的过程是“中止”（闭）因为它不能连接到传入连接被听者传递给它的。
这是在SQLNET错误堆栈发现，在我们的例子中是：
tns-12537：TNS：连接关闭。
基本上专用的过程没有一个客户端连接了工作。
此报错类似通知：Oracle因为ora-609关闭或者叫中止了一个到数据库的专有连接——OsPID进行（28725）。
ora-609错误原因是：无法与进入的连接进行联系，所以无法将此连接转入监听器，所以数据库的过程中止此进程。
此时报错tns-12537：TNS：连接关闭，根本原因为客户端连接不正常。
客户端通过监听器连接Oracle数据库的过程：
1。客户端发起一个到数据库的连接，所以连接到监听器
2。听众开始（叉）专用数据库的过程中，会收到这个连接（会话）
三.在这个专门的程序开始，听者通过连接从客户这个过程
4。服务器进程将连接从听众继续与客户握手
5。服务器进程和客户交流建立会话所需的信息（即，两个常见的任务，用户登录）
6。会议开了
简单说就是：
1。客户端连接到监听器
2。监听派生叉一个子进程，交转化为专有服务器进程专用数据库的过程
3。第2步完成后，监听将客户端的连接转入此专有进程专用工艺
4服务器进程收到从监听来的连接信息后，需要继续与客户端的连接进行握手。
5。服务器进程与客户端进程交换建立会话需要的信息，如用户名、密码等
6。以上好后，会话打开。
在介于3、4步时客户端连接关闭，专用数据库的过程与客户端通信时发现客户端关闭了。
###############################
使用跟踪来排查：
文档：故障排除指南ora-609：流产过程未知OsPID进行opiodr（文档ID 1121357.1）
对于这种问题的排查，使用听众。日志或者SQLNET的跟踪效果不太好，因为每秒可能有很多连接同时SQLNET的跟踪未提供更多的客户端信息。
此时可以尝试使用OS层面的跟踪。
如：1111为监听进程，PS EF | grep tnslsnr查出
Linux：信息射频O /甲氧苄啶/ lsnr1.log P 1111
HP-UX：意大利-员工- AFPO /甲氧苄啶/ lsnr1.log 1111
如果使用微量跟踪，如下：
三.Oracle Net 16级服务器跟踪。添加到服务器端sqlnet.ora文件
DIAG_ADR_ENABLED=off # Disable ADR if version 11g
TRACE_LEVEL_SERVER = 16 # Enable level 16 trace
TRACE_TIMESTAMP_SERVER = ON # Set timestamp in the trace files
TRACE_DIRECTORY_SERVER = DIRECTORY # Control trace file location
TRACE_FILELEN_SERVER =n #Control size of trace set in kilobytes eg 20480
TRACE_FILENO_SERVER =n #Control number of trace files per process
使用errorstack方法如下：
4。errorstack：设置errorstack捕捉失败。这是特别有用当捕获Oracle Net客户端跟踪是不可行的。
SQL ALTER SESSION事件609 errorstack（3）”；
一旦被收集而错误转载有一些痕迹：
SQL ALTER SESSION事件609关”；
###############################################
关于此问题的解决方法有：
文档：alert.log显示ora-609与tns-12537：TNS：关闭连接（文档ID 1538717.1）
可能原因：
客户端卡住、崩溃；连接被防火墙杀死；客户端超时设置；客户端连接后立刻关闭；网络不稳定；
需要检查客户端dns。或/或中信息SQLNET：
在客户家sqlnet.ora Oracle可能超时：
sqlnet.outbound_connect_time
sqlnet.recv_timeout
sqlnet.send_timeout
tcp_connect_timeout
客户可能超时连接描述符（硬编码在客户端应用程序或客户端dns，ORA）：
connect_timeout
