StarRocks社区版当前会将所有的审计日志保存在本地fe/log/fe.audit.log里,并没有保存在数据库中。社区不时有同学反馈希望将审计日志也保存在StarRocks本地库表中一份,以方便后面的管理和维护。
研究这块时发现Apache Doris提供的有审计日志插件,StarRocks从Doris fork出后重写了七成多的代码,对比研究了下两个产品审计日志这块的逻辑,发现这里是变化不大的,于是参考Apache Doris的审计插件代码,简单改造了一版适用于StarRocks的审计日志插件,本质上还是获取审计信息攒批后基于Stream Load的方式导入至StarRocks表中。
插件已在github开源,地址:GitHub - WuMenglong/fe-plugins-auditloader
历史版本审计插件下载见评论区度盘,大家可以参考下面的步骤安装使用。
注意:随着StarRocks的迭代升级,审计日志fe.audit.log中的字段个数也在逐渐增多,所以不同的StarRocks版本需要使用对应版本的插件,同时在StarRocks中存放审计日志的表的创建语句也要随之调整(除此之外的其他操作在各个版本通用)。下面演示所用的建表语句适用于StarRocks 2.1版本,其他版本的建表语句也见度盘。
我们首先在本地创建一个动态分区表,来保存审计日志中的数据。为了规范使用,建议为其单独创建一个数据库。
创建存放审计日志的数据库starrocks_audit_db__:
mysql> create database starrocks_audit_db__;
在starrocks_audit_db__库创建starrocks_audit_tbl__表:
mysql> create table starrocks_audit_db__.starrocks_audit_tbl__
(
query_id varchar(48) comment "查询唯一ID",
time datetime not null comment "查询开始时间",
client_ip varchar(32) comment "客户端IP",
user varchar(64) comment "查询用户名",
db varchar(96) comment "查询所在数据库",
state varchar(8) comment "查询状态:EOF,ERR,OK",
query_time bigint comment "查询执行时间(毫秒)",
scan_bytes bigint comment "查询扫描的字节数",
scan_rows bigint comment "查询扫描的记录行数",
return_rows bigint comment "查询返回的结果行数",
stmt_id int comment "SQL语句的增量ID",
is_query tinyint comment "SQL是否为查询. 1或0",
frontend_ip varchar(32) comment "执行该语句的FE IP",
stmt string comment "SQL原始语句",
digest varchar(32) comment "SQL指纹"
) engine=OLAP
duplicate key(query_id, time, client_ip)
partition by range(time) ()
distributed by hash(query_id) buckets 3
properties(
"dynamic_partition.time_unit" = "DAY",
"dynamic_partition.start" = "-30",
"dynamic_partition.end" = "3",
"dynamic_partition.prefix" = "p",
"dynamic_partition.buckets" = "3",
"dynamic_partition.enable" = "true",
"replication_num" = "3"
);
starrocks_audit_tbl__是动态分区表,我们在建表时没有直接创建分区,所以建表后需要等待后台动态分区调度进程调度后才会生成当天及后三天的分区。动态分区调度进程默认10分钟调度一次,我们可以先观察分区是否已经被创建,再进行后续操作,分区查看语句为:
mysql> show partitions from starrocks_audit_db__.starrocks_audit_tbl__;
度盘中的审计插件名称为auditloader.zip,解压插件:
[root@node01 ~]# unzip auditloader.zip
Archive: auditloader.zip
inflating: auditloader.jar
inflating: plugin.conf
inflating: plugin.properties
这句命令会把zip里面的文件直接解压到当前目录,解压后可以得到插件中的三个文件:
auditloader.jar:插件代码打包的核心jar包
plugin.conf:插件配置文件,需根据集群信息修改
plugin.properties:插件属性文件,无需修改
根据我们实际的集群信息,修改配置文件plugin.conf:
### plugin configuration
# The max size of a batch, default is 50MB
max_batch_size=52428800
# The max interval of batch loaded, default is 60 seconds
max_batch_interval_sec=60
# the max stmt length to be loaded in audit table, default is 4096
max_stmt_length=4096
# StarRocks FE host for loading the audit, default is 127.0.0.1:8030.
# this should be the host port for stream load
frontend_host_port=127.0.0.1:8030
# Database of the audit table
database=starrocks_audit_db__
# Audit table name, to save the audit data.
table=starrocks_audit_tbl__
# StarRocks user. This user must have LOAD_PRIV to the audit table.
user=root
# StarRocks user's password
password=root
修改完成后,再将上面的三个文件重新打包为zip包备用:
[root@node01 ~]# zip -q -m -r auditloader.zip auditloader.jar plugin.conf plugin.properties
注意:这句命令会将需要打包的文件移动到auditloader.zip中,并覆盖该目录下原有的auditloader.zip文件。也即执行完打包命令后,该目录下只会保留一个最新的auditloader.zip插件包文件。
将auditloader.zip分发至集群所有FE节点,各节点分发路径需要一致。例如我们都分发至StarRocks部署目录/opt/module/starrocks/下,也即auditloader.zip文件在集群所有FE节点的路径都为:
/opt/module/starrocks/auditloader.zip
StarRocks安装本地插件的语法为:
INSTALL PLUGIN FROM "/location/plugindemo.zip";
根据我们分发文件的路径修改命令后执行:
mysql> INSTALL PLUGIN FROM "/opt/module/starrocks/auditloader.zip";
安装完成后,查看当前已安装插件信息:
mysql> SHOW PLUGINS\G
*************************** 1. row ***************************
Name: __builtin_AuditLogBuilder
Type: AUDIT
Description: builtin audit logger
Version: 0.12.0
JavaVersion: 1.8.31
ClassName: com.starrocks.qe.AuditLogBuilder
SoName: NULL
Sources: Builtin
Status: INSTALLED
Properties: {}
*************************** 2. row ***************************
Name: AuditLoader
Type: AUDIT
Description: load audit log to olap load, and user can view the statistic of queries
Version: 1.0.1
JavaVersion: 1.8.0
ClassName: com.starrocks.plugin.audit.AuditLoaderPlugin
SoName: NULL
Sources: /opt/module/starrocks/auditloader.zip
Status: INSTALLED
Properties: {}
我们可以看到当前有两个插件,其中Name属性为AuditLoader的插件即为我们刚才安装的审计日志插件,其状态为INSTALLED,表示已安装成功。
Name为__builtin_AuditLogBuilder的插件为StarRocks自己的日志插件,是用来打印审计日志到本地日志目录生成fe.audit.log的。
StarRocks自带的__builtin_AuditLogBuilder插件我们千万不要动它,咱们自己安装的插件则可以视需求随意卸载,卸载命令语法为:
UNINSTALL PLUGIN plugin_name;
--plugin_name即SHOW PLUGINS命令查到的插件Name信息。
AuditLoader日志审计插件安装完成后,我们可以观察到fe/plugins/目录下生成了一个AuditLoader文件夹,这个文件夹相当于是StarRocks加载auditloader.zip插件后存放的临时目录。每次重启FE,StarRcoks都会重新从我们安装插件时指定的路径中重新加载auditloader.zip文件。也是因此,前面分发至各FE节点的auditloader.zip文件我们千万不要移动或删除。
AuditLoader插件安装完成后,审计日志文件中的数据并不是实时的入库。StarRocks后台会按照我们配置文件plugin.conf中配置的参数,攒批60秒或50M执行一次Stream Load导入。等待期间,我们可以简单执行几条SQL语句,看对应的审计数据是否能够正常入库,例如执行:
mysql> CREATE TABLE starrocks.audit_test(c1 int,c2 int,c3 int,c4 date,c5 bigint) Distributed BY hash(c1) properties("replication_num" = "1");
mysql> insert into starrocks.audit_test values(211014001,10001,13,'2021-10-14',1999),(211014002,10002,13,'2021-10-14',6999),(211015098,16573,19,'2021-10-15',3999);
等待1分钟左右,查看审计表数据:
mysql> select * from starrocks_audit_db__.starrocks_audit_tbl__;
正常来说数据都可以成功入库,如果表内始终没有数据,可以检查配置文件plugin.conf中信息配置是否正确,如果有误,可以参考前面的步骤修改配置文件,卸载插件后重新安装。或者我们也可以查看fe.log,用排查Stream Load任务的方式来定位问题。