测试环境中出现了一个异常的告警现象：一条告警通过 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 组件，那么需要对源码文件进行定制化修改。
关于ORACLE数据库结构的简介
ORACLE的数据库结构大家都了解吗?如果不了解，下面我为大家整理了关于ORACLE数据库结构简介的文章，希望能为你提供帮助：
一、物理结构：
1、数据文件：ORACLE数据库包含若干数据文件，数据文件存储数据库数据，包括表、索引等等。数据文件的几个特点：
1)一个数据文件只允许分配给一个数据库
2)数据文件可设置为自动扩展
3)一个或多个数据文件构成表空间
在进行数据库 *** 作的时候，数据库先从内存寻找要 *** 作的数据，如果没有找到的话，再从数据文件取出数据放在内存中，然后才对内存中的数据进行相关的 *** 作。 *** 作完的数据并没有立即写到数据文件中(这样减少了磁盘的IO)，而是放在内存中，然后由DBWn进程决定何时批量写入数据文件。
2、控制文件：每一个数据库都有一个或多个控制文件，控制文件包含了数据库的物理结构，包括：
1)数据库名
2)数据文件名及位置
3)重做日志文件名及位置
4)数据库的建立时间等等
一般一个数据库都有若干个控制文件镜像。数据库在打开的时候(ALTER
DATABASE OPEN)，会读取控制文件中的信息来打开数据库。当数据库的物理结构发生变化的时候，比如增加一个数据文件、一组重做日志等等，控制文件都会自动地做相应的修改。在数据库物理结构发生变化后，最好重新备份一下控制文件，用于数据库恢复。
3、重做日志文件：重做日志中记录了数据的变化。一般一个数据库都会有两到三组重做日志文件。同一日志组的镜像最好分布于不同的磁盘上。
4、归档日志：当数据库启动归档的时候，重做日志会被自动归档到指定的位置。
5、初始化参数文件：包含了数据库启动时的配置信息
6、警告和跟踪日志文件
1)跟踪文件：每一个后台进程都有一个单独的'跟踪文件，比如当系统发现某一个进程有问题的时候，相关的信息就会写到相应的跟踪文件中。可以从数据库的跟踪文件来发现和调试数据库的错误。
2)警告文件，也叫警告日志。是一个特别的跟踪文件，它记录着数据库启动、运行中的相关信息，它是按时间顺序进行记录的。
7、备份文件
二、逻辑结构
1、表空间：相关逻辑对象的集合。在oracle10g中，在创建数据库的时候就自动创建了SYSTEM和SYSAUX表空间。
2、数据块：数据存储在数据块中，一个数据块的大小(DB_BLOCK_SIZE)由 *** 作系统块来决定。可以指定5种，分别为2K、4K、8K、16K、32K。
3、区：一系列连续的数据块组成区，区存储特定类型的数据，比如索引，表等等。
4、段：由一系列区组成段。
1)数据段：对于每一个非聚集表有一数据段，表的所有数据存放在该段。每一聚集有一个数据段，聚集中每一个表的数据存储在该段中。分区表中的每一个分区有一个数据段，分区中的数据存储在该段中。
2)索引段：每一个索引有一索引段，存储索引数据。分区索引中的每一分区有一个索引段。
3)回滚段：用于临时存储要撤消的信息，这些信息用于生成读一致性数据库信息，在数据库恢复时使用，回滚未提交的事务。系统回滚段用于处理系统事务，不建议用户使用系统回滚段来做其它 *** 作。
4)临时段：当一个SQL语句需要临时工作区时，由ORACLE建立临时段。当语句执行完毕，临时段的区退回给系统。
套Power AIX上的9.2.0.1系统在数据库打开过程中遇到ORA-00600:[2667]内部错误，详细日志如下:Wed Mar 9 19:03:38 2011
RESETLOGS is being done without consistancy checks. This may result
in a corrupted database. The database should be recreated.
RESETLOGS after incomplete recovery UNTIL CHANGE 117699122479
Resetting resetlogs activation ID 2197911857 (0x83017931)
Wed Mar 9 19:03:47 2011
LGWR: Primary database is in CLUSTER CONSISTENT mode
Assigning activation ID 2284878888 (0x88307c28)
Thread 1 opened at log sequence 1
Current log# 3 seq# 1 mem# 0: /s01/maclean/oradata/PROD/redo03.log
Successful open of redo thread 1.
Wed Mar 9 19:03:47 2011
SMON: enabling cache recovery
Wed Mar 9 19:03:47 2011
Errors in file /s01/maclean/admin/PROD/udump/PROD_ora_585914.trc:
ORA-07445: exception encountered: core dump [] [] [] [] [] []
Wed Mar 9 19:03:48 2011
Errors in file /s01/maclean/admin/PROD/bdump/PROD_pmon_602286.trc:
ORA-07445: exception encountered: core dump [] [] [] [] [] []
Wed Mar 9 19:03:50 2011
Errors in file /s01/maclean/admin/PROD/bdump/PROD_lgwr_548884.trc:
ORA-00600: internal error code, arguments: [2667], [1], [1], [3], [1739273391], [1739273391], [1739273391], [7267]
LGWR: terminating instance due to error 600
相关的初始化参数
fast_start_mttr_target = 300
_allow_resetlogs_corruption= TRUE
undo_management = AUTO
undo_tablespace = UNDOTBS1
以上可以看到lgwr关键进程在数据库open后几秒后遭遇了ORA-00600:[2667]内部错误后终止了实例。
该数据库在之前因为丢失当前日志文件进行了已经实施了一系列的非常规恢复 *** 作，包括设置一系列的underscore参数:
Before I provide the steps to fix the ora-00600 error, I want to tell you that this database is opened with the unsupported parameter"allow_resetlogs_corruption".
*************************************************************************
* By forcing open the database using this parameter, there is a strong *
* likelihood of logical corruption, possibly affecting the data *
* dictionary. Oracle does not guarantee that all of the data will be *
* accessible nor will it support a database that has been opened by *
* this method and that the database users will be allowed to continue *
* work. All this does is provide a way to get at the contents of the *
* database for extraction, usually by export. It is up to you to *
* determine the amount of lost data and to correct any logical *
* corruption issues. *
* *
*************************************************************************
2) The steps to get rid of the ora-00600 are as follows:
+ Change UNDO_MANAGEMENT=AUTO to
UNDO_MANAGEMENT=MANUAL
+ Remove or comment out UNDO_TABLESPACE and UNDO_RETENTION.
+ Add
_CORRUPTED_ROLLBACK_SEGMENTS =(comma separated list of Automatic Undo segments)
Example:
_CORRUPTED_ROLLBACK_SEGMENTS = (_SYSSMU1$, _SYSSMU2$, _SYSSMU3$, _SYSSMU4$,
_SYSSMU5$, _SYSSMU6$, _SYSSMU7$, _SYSSMU8$, _SYSSMU9$, _SYSSMU10$)
Note, sometimes the alert log will tell you what Automatic Undo segments are in use.
Search the alert log for SYSS. If the alert log does not contain that information then use _SYSSMU1$
through _SYSSMU10$ as shown in the example above.
In UNIX you can issue this command to get the undo segment names:
$ strings system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort -u
From the output of the strings command above, add a $ to end of each _SYSSMU undo segment name.
++ Startup mount the database as follows:
SQL > startup mount
SQL > recover database
SQl > alter database open
*._corrupted_rollback_segments= (_SYSSMU730$, _SYSSMU731$, _SYSSMU732$, _SYSSMU733$, _SYSSMU734$,
_SYSSMU735$, _SYSSMU736$, _SYSSMU737$, _SYSSMU738$, _SYSSMU739$, _SYSSMU744$, _SYSSMU740$, _SYSSMU741$,
_SYSSMU742$, _SYSSMU743$, _SYSSMU744$, _SYSSMU745$, _SYSSMU746$, _SYSSMU747$, _SYSSMU748$, _SYSSMU749$, _SYSSMU74t$,
_SYSSMU75$, _SYSSMU750$, _SYSSMU751$, _SYSSMU752$, _SYSSMU753$, _SYSSMU754$, _SYSSMU755$, _SYSSMU756$, _SYSSMU757$,
_SYSSMU758$, _SYSSMU759$, _SYSSMU76$, _SYSSMU760$, _SYSSMU761$, _SYSSMU762$, _SYSSMU763$, _SYSSMU764$, _SYSSMU765$,
_SYSSMU766$, _SYSSMU767$, _SYSSMU768$)
如果自己搞不定可以找ASKMACLEAN专业ORACLE数据库修复团队成员帮您恢复!
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）