数据库类型：

SQLite

表解释：

alarm 表与告警相关的值

alarm_log_new 是新产生的告警日志

alarm_trap_rule_new 告警的判断条件，依据是oid。然后输出相应的提示产生对应的告警。

device是与设备基础状态相关的值

device_interfaces 设备的物理端口状态信息，deviceId为0表示为本机，其他每个Id为其纳管的设备。可以看到operStatus储存的值为UP，说明端口状态是通过MQTT协议来同步的，而不是oid。

device_base_info 储存的是其纳管的所有设备信息，设备名称、IP、SN、绑定的模板等。

查询示例

查询告警数量大于100的条目的数据。显示的表头为设备名称、ip地址、告警详情、告警次数、最新产生时间。并按照时间倒序进行排序

 SELECT
  di.name,
  di.ipv4,
  aln.context,
  aln.repeatTime,
  aln.updateTime
FROM alarm_log_new aln
LEFT JOIN device_base_info di 
  ON aln.deviceId = di.id
WHERE aln.repeatTime > 100
ORDER BY aln.updateTime DESC;

查询2025年8月26日的告警

SELECT *
FROM alarm_log_new
WHERE updateTime LIKE '%2025-08-26%';

记录一个比较抽象的例子

问题现象：主机收到的来自下联交换机的端口震荡告警过多，3.5w条 导致了MQTT隧道资源占满影响了设备上线，设置导致主机的web界面卡死挂掉

解决思路：已知主机的告警是通过下联交换机携带的oid信息进行判断，接口down是1.3.6.1.6.3.1.1.5.3、 接口up是1.3.6.1.6.3.1.1.5.4，判断条件都储存在alarm_trap_rule_new表中。那么把表中的接口up、down替换为其他值，就不会触发接口up、down的判断，那么主机就不会耗费资源去处理告警。

配置过程

比如都替换成温度超温复位告警恢复

保存后将db文件在上传至inc-emb中

就不会再有端口up、down相关的告警了