监控目标、监控目标分组、监控模板、资产

对于hosts表（存储host主机，template模板，proxy，host prototype），host名称，name可读名，status来表明该项的类型和状态，flags自动发现标志，inventory_mode资产模式，templateid？？四种接口的状态信息，错误信息，host页面ipmi菜单页的相关配置，加密菜单页的内容，停机维护信息，proxy_hostid在host页面指定proxy，proxy_address在proxy页面，autocompress proxy与server之间数据是否自动压缩？？

host_tag表，tag信息

interface表，存储四种接口的信息

interface_snmp，关于snmp接口的一个子表

hstgrp主机组以及模板组，只存储名称，自动发现flags，是否内部internal，这里不清楚，有些组一开始就存在，称为内部组

hosts_groups主机和主机组关系，模板和模板组的关系

hosts_templates主机和模板的关系，模板和模板的模板的关系

host_inventory即host的inventory菜单页的内容

监控项，触发器，图表

对于items表，type，hostid（主机或模板id），interfaceid（接口id）可为空，params参数（可存formula计算式，还有？），value_type数据类型，valuemapid，units，delay（默认间隔），history，trends，flags（自动发现标志，即是发现的还是原生的还是什么的），inventory_link（Populates host inventory field），templateid（生成本记录的模板的item ID，这里有点绕，主机级的item，如果有原型，这个item并不会存储原型的id，这个原型会存储它的上一级模板的itemid，一直到最原始的itemid），trapper_hosts（该指标允许哪些设备（IP地址）主动回传，相当于认证，在http agent和trapper类型里都有该选项），logtimefmt（日志型item的日志时间格式），master_itemid，authtype（SSH，HTTP有），output_format（httpitem的采集数据形式Store raw，Convert to JSON），lifetime（lld的属性，发现的设备消失后，原本的数据保留的时间），evaltype（用在discovery rule的filter里），discover（自动发现模型状态，是原型的属性，表示发现后是否生成，文档详细），formula（这里的公式指的是discovery rule里的filter里的条件公式）

首先，item并非host专属，template也有

template和host都有lld，其中的item prototype也在表中

在items表中，有item和item prototype，还有discovery rule，snmp类型的discovery rule在表里的snmp_oid还会存储所拥有的原型的oid

item_rtdata生效监控项运行时最新状态表，state最新状态（normal，not support），最新日志文件的大小、修改时间，最新的错误信息（这几个顺带就采集了）

item_preproc表，step，type（就是预处理的类型），params，error_handler（是否自定义处理错误，以及处理类型），error_handler_params

自然不止item的预处理，包括原型和自动发现规则的预处理

applications表，hostid（MUL），name，flags（自动发现标志，注意所有flags的类型都一样，只不过表并不包含所有flags）

items_applications表，applicationid，itemid

application_template表，applicationid，templateid

application及生成它的模板的application之间的关系

triggers表，opdata带扩展变量的运行时数据（就是Operational data），value（表达式求值的结果ok，problem），priority（severity），comments描述，recovery_mode（expression，recovery_expression，none），type事件生成方式（单个，多重），correlation_mode（关闭所有问题，关闭所有满足标签值的问题），templateid（生成本记录的监控模板的trigger ID），flags（数据来源），status（启用状态），state（可用状态），url，discover（发现原型状态）

trigger表为啥没有hostid，expression中存了hostid，是吗？

functions表，itemid（函数操作的itemid），triggerid（函数所属的triggerid），name（function的类型，在trigger里的表达式编辑中），parameter（参数组合）

trigger_depends表，triggerid_down（依赖的），triggerid_up（被依赖的）

trigger_tag表，triggerid，tag，value

graphs表，templateid（生成本记录的模板图表id），flags（自动发现标志， a plain graph，a discovered graph.），discover（图表原型的属性）

graphs_items表，graphid，itemid，drawtype（绘制类型，点，直线），type（图表指标项类型，默认simple，只有在pie和exploded类型图表可选graph sum？图形总数？），calc_fnc（显示的指标值类型，min，max，avg）

设备与服务主动探测、设备主动连接

对于drules设备自动发现规则表，proxy_hostid（执行本规则的网关ID），iprange（ip发现范围），nextcheck

dchecks自动发现内容表，druleid，type（检测的协议类型），ports（检测的端口列表），key_（snmp和agent的key或oid），uniq（设备唯一性规则），host_source（取值来源，dns，ip，检测所得值，这里界面上是zabbix agent system.username，是否能自行修改？？），name_source（取值来源，不特定？这里界面上是主机名称，dns，ip，检测所得值）

dhosts自动发现设备表，dhostid（探测到的设备ID），druleid，lastup（最近正常的时间），lastdown（最近异常的时间）

dservices自动发现服务表，dserviceid，dhostid，value（返回值），dcheckid

autoreg_host自动注册设备表，autoreg_hostid（设备id），proxy_hostid，host（设备名称），listen_ip，listen_port，listen_dns，host_metadata（设备元数据？），flags（连接地址标志），tls_accepted（允许的主动连接入站连接方式）

监控指标自动探测

lld_macro_path宏路径表，itemid（lld_rule在item里），lld_macro，path（lld返回结果中的位置定义，JSONPath）

item_condition探测过滤条件表（就是lld的filter），itemid（lld_rule id），macro，value

group_prototype 不要了 host_prototype也不要了

存储两类数据

主机组模型：由主机prototype发现新主机后，创建主机组。有效的字段为name组名称，hostid主机原型，templateid？？

主机模型与创建的主机组的关系：有效字段为groupid新建组id，hostid原型，templateid关系id？？

application_prototype表，name，itemid（lld_rule id），templateid？？

item_application_prototype表，item原型和application原型的关系，itemid（lld_rule id），application_prototypeid

lld_override已探测对象重定义表，itemid（lld_rule id），name，step，evaltype，formula，stop（条件满足后是否停止后续重定义步骤）

lld_override_condition

lld_override_operation

lld_override_opstatus启用状态

lld_override_opdiscover是否继续探测

lld_override_opperiod更新周期，在override里的operation里的update interval

lld_override_ophistory重定义已探测item监控结果留存时长

lld_override_optrends

lld_override_opseverity严重级别

lld_override_optag

lld_override_optemplate重定义已探测host对应的模板

lld_override_opinventory重定义已探测host资产连接模式，inventory_mode

item_discovery

lld_rule和item_prototype的关系：itemid（原型id），parent_itemid（lld_rule id）

item原型和发现的item的关系：itemid（就是item），parent_itemid（原型id）

application_discovery已发现并自动生成的application表，applicationid，application_prototypeid

trigger_discovery已发现并自动生成的trigger表，基本信息已经存入trigger表，发现flags字段设置为4了，这里额外记录是为了：1.表示trigger和trigger prototype的关系 2.已发现的trigger的生命周期管理lastcheck，ts_delete（删除时间）

group_discovery已发现并自动生成的设备分组表，基本信息已存入group表，作用同上

host_discovery已发现并自动生成的设备表

lld_rule和host原型的关系：hostid（原型id），parent_itemid（lld_rule id）

host原型和生成的主机的关系：hostid（就是主机id），parent_hostid（主机原型id）

interface_discovery已发现并自动生成的设备接口表，interfaceid，parent_interfaceid

graph_discovery已发现并制动生成的监控数据图表表，graphid，parent_graphid，

事件响应

对于alerts警告，不同的alert可以使用相同的action（MUL），且必须有action（一个action）；响应的事件event和出发该告警的事件p_event是不同的event，event不能为空，p_event可以为空；alerts表里acknowledge是对发出该告警的事件的确认，alert本身是一个动作？？？

MUL：action，clock，eventid？？，mediatypeid，status，userid，p_eventid，acknowledgeid

告警alert和故障problem的关系？

对于event事件，会指定source事件来源（trigger，discovery，autoregistration，internal），以及来源的对象的种类object（trigger，discovered host，discovered service，auto-registrated host，item，lld rule）？？？事件值value？？（对problem进行确认，会改变event的acknowledge）

对于actions动作，有一个eventsource（时间来源），conditions条件表里actionid是MUL，一个action可有多个condition，condition有conditiontype，这里的定义很多，指定条件类型，后有operator运算符和两个value；一个action可以有多个operation，对于operation操作表里actionid是MUL，recovery指定响应动作类型（异常处理，异常恢复，变更确认），operationtype指定操作类型（发送信息，执行命令。。。）operation的detail在哪里，一部分在operation表里（步骤，类型），另外的以情况分布：opconditions表的operationid是MUL，opcondition与condition不是一个表；opmessage表的主键同时也是外键：operationid，表包含通知的主题和内容，以及是否使用默认通知（默认使用），mediatypeid；opmessage_usr/_grp存储发送信息到的用户或用户组；opcommand三张表同理，opcommand表包含命令类型和内容，scriptid是MUL，且可为空（opcommand_hst的hostid为啥可为空？？？测试一下？）；opgroup，optemplate，opinventory，

operations表中动作条件计算类型evaltype是什么

Key passphrase是指用于保护加密密钥的密码短语或密码短语，存储在password里

media_type媒介类型表，对应media type页面，exec_path，exec_paramscontent_type就是Message format，消息格式

webhook类型Include event menu entry，Menu entry name，Menu entry URL，process tag

media_type_message消息模板表，一个media_type可有多个模板，有主题和内容的同时，还存储了时间来源eventsource，事件响应动作模式recovery

media_type_param表存储的是webhook类型配置的参数

media表，userid和mediatypeid都是MUL，存储发送地址，状态，severity，period，看着像媒体的一个汇总表，哪里用到了

escalation升级执行表？？？，这个好像不是普通的升级，存储了actionid，triggerid，eventid异常事件，r_eventid恢复事件，nextcheck下次检查时间，步骤，itemid，状态（有4种），acknowledgeid

事件生成与合并

对于event事件，会指定source事件来源（trigger，discovery，autoregistration，internal），以及来源的对象的种类object（trigger，discovered host，discovered service，auto-registrated host，item，lld rule）？？？以及objectid？？事件值value？？（对problem进行确认，会改变event的acknowledge）

event_tag表，存储eventid，tag，value

event_recovery表，eventid，恢复事件id，关联id，关联事件id，关闭本事件的用户id

event_suppress表，eventid，maintenanceid，suppress_until抑制到的时间

对于problem问题表，主键eventid也是外键，同样有事件来源source，来源对象种类，来源对象id，是否已确认，恢复事件的id和时间，关闭该problem的用户id，correlationid关联id

问题页面中的action存在哪里？？

problem_tag表，存储eventid，tag和value

和event_tag表的关系？

对于acknowledges确认表，对应problem页面的确认配置，userid对应当前操作用户，存储操作的动作的和（unacknowledge event是在确认后再次修改为未确认），一次确认中可有多种操作，action列存储操作的和，更新前的严重级和更新后的

确认页面有各用户对该问题的操作记录history，存在哪里的？？

对于correlation关联表，名称（unique），描述，evaltype条件的组合计算类型，定制条件表达式formula，status

corr_operation表，correlationid，type就两种

corr_condition表，correlationid，type有6种，只存了各个condition的type

corr_condition_group表，operator（等或不等），groupid

corr_condition_tag表，因为condition里可以限制tag名等于指定值，只存这个tag指定值

corr_condition_tagvalue表，限制指定tag的值符合指定条件，存tag，value，operator（4种）

corr_condition_tagpair表，新旧标签对，就存新旧标签名

监测结果

对于history表，只存储监控项id，采集值，采集时间（这个表存的float类型）

history_log表，存log类型？？itemid，logeventid？？source，value指标值，日志时间戳，采集时间，严重等级

history_str表，itemid，采集时间，值

history_text表，同上

history_uint表，同上

以上表都没有主键

对于trends表，itemid，时间，数据条数，该计时段最小最大平均值

trends_uint表，同上

这两个表主键都为itemid，clock

停机维护

对于maintenances表，name（unique），maintenancetype（两种），描述，开始，结束，这里的开始结束是指开始和结束执行维护周期的时间，tags_evaltype（and/or，or）

maintenances_groups表，maintenanceid，groupid主机组

maintenances_hosts表，maintenanceid，hostid

maintenances_tag表，maintenanceid，tag，operator，value

maintenances_windows表，维护周期，maintenanceid，timeperiodid（用了timeperiods表）

正则，扩展变量

对于regexps表，name，test_string测试字符串

expressions表，regexpid，expression表达式字符串，expression_type（5种类型），exp_delimiter分隔符，case_sensitive是否区分大小写

对于globalmacro表，macro，value，描述，type（text macro，secret macro前台显示为几个点）

对于hostmacro表，hostid，macro，value，描述，type同上

对于globalvars表，snmp_lastsize上次已处理的文件长度？？？

用户及权限

对于users表，存储了别名alias，name，surname姓，密码，url？？自动登录，自动登出，用户语言，refresh刷新啥？type（3种），主题，最近登陆失败次数，最近登陆失败ip，最近登陆失败时间，每页显示记录行数？？

对于usrgrp表，name，gui_access（4种），status（0，1），debug_mode（0，1是否启用）

user_groups表，usrgrpid，userid

对于rights权限表，groupid用户组id，id主机分组？，permission（禁止，只读，读写）

对于profiles配置表，存储用户运行时配置和用户偏好信息。

userid，idx配置分组名称，idx2具体配置索引？？？value_id配置值id类型？？value_int配置值int类型？？value_str配置值string类型？？source？？type（id，int，string）

对于tag_filter表，存储用户分组的基于标签的访问权限。用来使用户组查看满足等值标签条件的故障信息（故障标签与表中标签同名等值）？？

若标签值为null，则查看主机组的同名标签故障信息

usrgrpid，groupid，tag，value

其他

对于timeperiods时间周期表，timeperiod_type（一次，每天，每周，每月），day只用于以月为周期的period，dayofweek一周中的第几天（二进制，周1是1，周二是10，周三是100），month（二进制或计算后的二进制，1月和3月生效，则为1+100 =101 = 5），every（type=0时，every固定1？type=2，3时，自定义，每几天或每几周，type=4时，如果date是day of month则为1，date是day of week则1为第一周，2为第二周，5为最后一周），start_date是一次性维护的开始时间，period是停机维护持续时间，start_time日，周，月维护的开始时间（0代表00:00）

对于config通用配置表，没法读

对于config_autoreg_tls设备自动注册tls配置表，the_psk_indentity，the_psk

对于housekeeper数据清理配置表？？，tablename表名，filed字段名，value

对于ids表id的表，table_name表名，field_name字段名，nextid下一个id

记录各个表当前最大的id，以确保多用户插入数据时保持id正确自增

对于valuemaps值映射表，name

mappings值映射内容表，valuemapid（MUL），value名称，newvalue值

对于scripts脚本表，name，command（varchar255），host_access执行脚本所需主机访问权限（2读，3读写），usrgrpid允许运行该脚本的用户组id（0为全部），groupid主机组id，comfirmation在console前端运行时弹出的确认信息？？type（0script，1IPMI），execute_on