测试环境中出现了一个异常的告警现象：一条告警通过 Thanos Ruler 的 HTTP 接口观察到持续处于 active 状态，但是从 AlertManager 这边看这条告警为已解决状态。按照 DMP 平台的设计，告警已解决指的是告警上设置的结束时间已经过了当前时间。一条发送至 AlertManager 的告警为已解决状态有三种可能：1. 手动解决了告警2. 告警只产生了一次，第二次计算告警规则时会发送一个已解决的告警3. AlertManager 接收到的告警会带着一个自动解决时间，如果还没到达自动解决时间，则将该时间重置为 24h 后首先，因为了解到测试环境没有手动解决过异常告警，排除第一条；其次，由于该告警持续处于 active 状态，所以不会是因为告警只产生了一次而接收到已解决状态的告警，排除第二条；最后，告警的告警的产生时间与自动解决时间相差不是 24h，排除第三条。那问题出在什么地方呢？
创新互联建站是创新、创意、研发型一体的综合型网站建设公司，自成立以来公司不断探索创新，始终坚持为客户提供满意周到的服务，在本地打下了良好的口碑，在过去的10余年时间我们累计服务了上千家以及全国政企客户，如茶艺设计等企业单位，完善的项目管理流程，严格把控项目进度与质量监控加上过硬的技术实力获得客户的一致表扬。
分析
下面我们开始分析这个问题。综合第一节的描述，初步的猜想是告警在到达 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 组件，那么需要对源码文件进行定制化修改。
在oracle的服务器上直接敲命令oerr错误类型、错误编号，oracle会告诉你错在什么地方，怎么解决这个错误，或者到oracle的网站上下载她的技术文档，然后打开，进入主页，在左上角有errormessage。点击进入，然后查找你要查看的error信息。
首先了解什么是外部表，与其它表的区别，建立一个简单的外部表(主要看操作过程)，最后我们用外部表查看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的报警信息
要获得逻辑驱动器或存储卷的性能计数器数据，必须在命令提示符下键入diskperf –yv。
默认情况下，操作系统使用diskperf –yd命令包含物理驱动器数据。
使用命令diskperf的详细信息，请在命令提示符下键入diskperf -？。
ORA-28040: No matching authencation protocol
1、问题复现：Spring boot 应用启动时候正常，但是页面访问后台接口，程序再访问数据库时，控制台报错如下：没有匹配的身份验证协议
Caused by: java. sql. SQLExceptiona ORA-28040: No matching authentication protocol
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java 112)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java: 331)
....
2、产生原因：当时环境是：Java jdk 1.8 + Spring boot ，在开发环境时是 Oracle 11g，此时运行正常，后面到测试环境换成 Oracle 12C，就发生上面的错误，经过检查发现原来是 .jar 文件里面打了两个不同版本的 Oracle 驱动。
3、解决方式：直接用压缩工具打开 .jar 文件，然后手动删除多余的 ojdbc14-x.x.x.jar 文件，只留下 ojdbc8 版本的驱动即可。
OracleOraDb11g_home1TNSListener服务启动后停止
1、问题复现：有时候连接 Oralce 的时候发现连接不上，然后打开 "services.msc" 服务面板发现 xxxxTNSListener 监听服务没有启动，当手动启动监听服务的时候，它弹框提示：“本地计算机上的OracleOraDb11g_home1TNSListener服务启动后停止。某些服务在未由其他服务或程序使用时将自动停止。”
2、产生原因：Oracle 数据库通常都会提供远程访问，比如小张电脑上安装了 Oralce 数据库，小李、小刘就可以直接访问小张的Oracle。Oracle 开启远程访问，需要在配置文件中设置本机 ip 地址，这样其它人才能通过 IP 访问，然而当 IP 在某些情况下发生变化时，比如切换了网络，或者是动态 IP 等情况，Oracle 监听器监听的 IP 与计算机实际 IP 就会不一致，然后就会发生上面的错误。
3、解决方式：找到 Oracle 数据库安装目录下的 listener.ora 文件，比如 C:appThinkproduct11.2.0dbhome_1NETWORKADMINlistener.ora。然后修改其中监听的 IP 为 Oralce 安装的计算机 IP 地址，比如下面的 192.168.3.195。最后再次启动监听服务即可正常。