1. 概述
1.1 版本
BI服务器版本 |
---|
5.1 |
1.2 应用场景
针对常见的运维监控诉求场景,给出现有的运维监控功能方案介绍,帮助客户快速实现对于 FineReport 和 FineBI 应用的运维监控。
方案适用于已经完成部署的帆软系统,将会展开介绍帆软应用的日常维护、管理和监控方式。
1.3 功能简介
帆软应用对系统有一定的配置要求,如果配置不符合要求可能出现使用异常、宕机等风险,因此需要定期对环境及应用的配置情况进行检测,以确保应用的健康运行。
同时管理员需要关注应用的运行状况,及时通过运维手段规避风险或在问题发生后定位并进行排除,实现应用的持续高可用。
本文方案将从以下几个方面展开介绍帆软应用的具体运维方式:
注:鉴于服务器情况不同,没有完全通用的解决方案。部分检查项仅提供推荐配置值,请自行百度修改方案。
方向 | 分类 | ||
---|---|---|---|
主要配置文件及说明 | 介绍帆软应用内的主要配置文件信息及其详细说明 | 外接数据库信息配置 | - |
平台配置信息 | - | ||
系统巡检 | 建议对系统进行定期巡检,确保应用所在的环境及应用内配置合理,以保证应用的正常运行 | 端口检查 | 帆软应用正常使用过程中,需要服务器开放一些端口,因此需要对这些端口进行检查是否开放,避免出现系统功能异常 |
网络服务检查 | 检测应用各组件通信是否能够ping通,是否存在丢包情况 | ||
存储服务检查 | 1)关注磁盘的性能和使用情况,防止影响业务的正常运行 2)关注磁盘剩余空间,防止出现磁盘空间不足导致系统运行受影响 | ||
内存配置检查 | 提供各个配置的推荐值和修改方法 | ||
其他环境配置检查 | 提供各个配置的推荐值和修改方法 | ||
业务配置检查 | 提供各个配置的推荐值和修改方法 | ||
基本维护 | 在应用日常的正常运行过程中,维护事务相对简单,在有需要的时候能够查看应用的运行日志,或查看应用的各项监控指标是否存在异常即可 | 日志查看 | 了解各类日志文件的存储位置和使用方法 |
监控指标 | 日常运行中,运维人员主要需要关注相关指标是否存在异常 | ||
异常维护 | 当帆软应用出现异常时,要有一些运维手段,实现提前规避风险、快速恢复服务可用等 | 异常警告 | 如需对帆软应用的异常及时感知,需实现对帆软应用各项指标的监控告警 |
宕机处理 | 当应用出现异常时,宕机可能会随之发生 1)快速恢复应用 2)记录宕机日志,进行问题定位和排查 | ||
备份与升级 | 因为新的功能优化或者BUG修复需要进行应用的升级,同时升级前为了避免未知风险的发生,做好系统的备份也是必须的 | 备份还原 | 系统需要定期进行备份,以确保在用户误操作、版本回退等场景下能够及时恢复 |
更新升级 | 为了能获得更好的功能体验,工程尽量跟随官方更新最新版本 |
2. 主要配置文件及说明
本章主要介绍帆软应用内的主要配置文件信息及其详细说明。
2.1 外接数据库信息配置文件
1)文件位置
%FRBI_HOME%\webapps\webroot\WEB-INF\config\db.properties
2)文件内容
数据决策系统中除平台属性配置以外的所有信息,包括目录树设置、模板定时任务信息等,均存储于 FineDB 数据库。
FineReport/FineBI 支持使用内置 FineDB 数据库或启用外接 FineDB 数据库。
工程配置了外接数据库后,方在WEB-INF/config中生成一个db.properties文件。FineDB 数据库是否外接由 db.properties 文件控制。
3)文件关键信息
db.properties文件中,常见配置关键字与其内容对应关系如下。
注:为了防止修改错误导致系统出错,不建议手动修改db.properties文件。
key(id) | 描述 |
---|---|
hibernate.connection.password | 加密过后的数据库的密码 |
hibeinate.maxWait | 最大等待毫秒数(ms), 超过时间会出错误信息 |
hibernate.minEvictableIdleTimeMillis | 连接在池中保持空闲而不被空闲连接回收器线程(如果有)回收的最小时间值(ms) |
hibernate.hbm2ddl.auto | 自动创建|更新|验证数据库表结构。 create:每次加载hibernate时都会删除上一次的生成的表,然后根据你的model类再重新来生成新表。 create-drop :每次加载hibernate时根据model类生成表,但是sessionFactory一关闭,表就自动删除。 update:第一次加载hibernate时根据model类会自动建立起表的结构(前提是先建立好数据库),以后加载hibernate时根据 model类自动更新表结构。 validate :每次加载hibernate时,验证创建数据库表结构,只会和数据库中的表进行比较,不会创建新表,但是会插入新值 |
hibernate.initialSize | 初始化线程数,表示开始自动建立几个与数据库的连接 |
hibernate.default_schema | 连接模式,如设为dbo模式,以指定数据库的创建者 |
hibernate.validationQuery | 验证连接是否成功,value可设为sql语句 |
hibernate.testWhileIdle | 空闲时是否进行验证,检查对象是否有效,默认为 false |
hibernate.connection.username | 数据库用户名 |
hibernate.connection.isolation | 参数配置数据库事务隔离级别 8:Serializable 串行化 4:Repeatable Read 可重复读 2:Read Commited 可读已提交 1:Read Uncommited 可读未提交 |
hibernate.connection.driver_class | 数据库连接驱动 |
hibernate.timeBetweenEvictionRunsMillis | 失效检查线程运行时间间隔,如果小于等于 0,不会启动检查线程 |
hibernate.connection.provider_class | 用以整合阿里的Druid数据库连接池 |
hibernate.testOnBorrow | 取得对象时是否进行验证,检查对象是否有效,默认为 false |
hibernate.testOnReturn | 返回对象时是否进行验证,检查对象是否有效,默认为 false |
hibernate.dialect | 指定数据库方言类 |
hibernate.numTestsPerEvictionRun | 失效检查线程运行次数 |
hibernate.connection.url | 数据库连接url |
hibernate.maxActive | 可以从对象池中取出的对象最大个数,为 0 表示没有限制 |
hibernate.minIdle | 对象池中对象最小个数 |
2.2 平台配置信息
平台中有些配置信息记录在 FineDB 的 fine_conf_entity 表中,只能通过修改表字段来进行更改。
用户可通过「fine_conf_entity可视化配置插件」安全地修改相关配置。
注:请勿使用该插件以外的方法修改 FineDB 文件,有可能造成不可修复的 BUG,需自行承担后果。
可修改的配置内容及修改方式请参见:FINE_CONF_ENTITY可视化配置
3. 系统巡检
建议管理员对系统进行定期巡检,确保应用所在的环境及应用内配置合理,以保证应用的正常运行。
巡检内容包括端口检查、网络服务检查、存储服务检查、环境配置检查以及业务配置检查。
3.1 端口检查
帆软应用正常使用过程中,需要服务器开放一些端口,因此需要对这些端口进行检查是否开放,避免出现系统功能异常。
分类 | 端口 | 说明 |
---|---|---|
http 监听端口 | FR默认:8080 BI默认:37799 | 帆软的 Web 端对外开放的端口,不开放将无法正常访问页面 默认端口支持修改,使用文本编辑工具打开文件:%tomcat_home%\conf\server.xml 比如我们想将端口号改为 8081,则将 server.xml 的代码中的 connector port 作如下修改,并保存文件。
修改完成后,需要重启 Tomcat 服务器。 |
WebSocket 端口 | FR默认:38888/39888 BI默认:48888 | WebSocket 主要用于刷新 token、用户被踢出、平台消息、内存和 CPU 显示、平台日志处当前系统在线人数、数据连接编辑状态的确定。 WebSocket 不开放影响 socket 通信,访问可能异常断开。 用户可根据自己的工程情况选择合适的 WebSocket 端口配置方法,详情请参见: 1)单机环境配置 WebSocket 端口:单机配置WebSocket端口 2)集群环境配置 WebSocket 端口:集群配置WebSocket端口 3)HTTPS 环境配置 Websocket 端口:HTTPS环境配置WebSocket 4)仅对外开放一个端口:不额外给WebSocket对外开放端口 |
3.2 网络服务检查
检查一下文件服务器、外接数据库、状态服务器和应用之间通信是否正常,是否能够ping通,是否存在丢包情况。
3.3 存储服务检查
3.3.1 磁盘性能检查
检查原因:
磁盘读取性能及磁盘写入性能会对帆软的业务产生影响,因此需要关注磁盘的性能和使用情况。
若系统使用了 FineBI 抽取服务,那么对于磁盘的读写性能有一定的要求,建议磁盘的写入速度需要在100M/s以上,否则可能影响业务的正常运行。
若系统未使用 FineBI 抽取服务,帆软应用通常对于磁盘读取性能没有严格要求,但日常运维中需要关注磁盘的IO情况,并依此判断磁盘性能是否足够。
检查方法:
1)FineBI 功能
管理员登录数据决策系统,点击「BI工具>磁盘空间管理>磁盘性能」,点击「测试磁盘」,即可进行磁盘写入性能检测。
若磁盘写入速度在100M/s以下,建议提升磁盘性能,避免影响业务的正常运行。
2)iostat工具
以 Linux 系统为例。
操作步骤 | 命令 | 说明 |
---|---|---|
安装 iostat 工具 | yum install sysstat -y | - |
查询磁盘读取负载情况 | iostat -xm | 以M为单位展示详细的磁盘读取负载情况 需要特别关注以下四个参数:
w_await和r_await这两个值越高,说明写入/读取需要等待的时间越长 %util和%iowait这两个值越高,说明当前系统的磁盘使用率非常高,且cpu大部分时间处于等I/O的状态 这个时候,往往说明I/O遇到了瓶颈,此时建议提升磁盘性能 |
3.3.2 磁盘剩余空间检查
检查原因:
随着帆软应用的运行,可能会产生越来越多的日志、备份、缓存文件等,对于磁盘空间的占用也会渐渐变大,如果不关注磁盘剩余空间可能出现磁盘空间不足导致系统运行受影响,严重时甚至会导致宕机。
管理员需要关注root根目录、db更新目录、temp目录、schedule目录、备份目录、logs目录、工程目录、polors缓存目录所在磁盘的剩余空间情况,如以上几个目录所在磁盘剩余空间较小时,建议进行磁盘清理或扩容,确保有充足的空间保证帆软应用的正常运行。
定期清理帆软应用中的过期或无效内容,保持磁盘空间的健康。
检查方法:
FineReport11.0.4 /FineBI 5.1.22 及之后版本的工程,新增「磁盘运维」功能。用户可以安全便捷的清理磁盘,不造成业务文件丢失风险,预防磁盘问题带来的宕机问题。
功能 | 简介 | 文档 |
---|---|---|
磁盘清理 |
| 磁盘清理 |
磁盘使用情况分析 |
| 磁盘使用情况分析 |
监控预警设置 |
| 监控预警设置 |
3.4 内存配置检查
注:如何通过帆软功能快捷运维
帆软提供系统检查功能,管理员登录数据决策系统,点击「管理系统>智能运维>系统检查」
「系统检查」中将根据系统使用情况对内存配置进行检查,当前配置不合理时将给出修改建议,并支持直接「查看建议配置」并对相应内存配置进行修改。
3.4.1 物理内存及堆内内存
1)建议值
注册用户数 | 在线用户数 | 并发用户数 | 推荐配置 | 最低配置 |
---|---|---|---|---|
2000-5000 | 400-1000 | 0-200 | 单机 CPU:8 核 16 线程 2GHZ JVM 内存:16GB 物理内存:32G | 单机 CPU:8 核 16 线程 2GHZ JVM 内存:8GB 物理内存:16G |
4000-10000 | 800-1500 | 200-300 | 单机 CPU:8 核 16 线程 2GHZ JVM 内存:16GB 物理内存:32G | 单机 CPU:8 核 16 线程 2GHZ JVM 内存:8GB 物理内存:16G |
6000-12000 | 1200-2500 | 300-500 | 单机 CPU:8 核 16 线程 2GHZ JVM 内存:24GB 物理内存:48G | 单机 CPU:8 核 16 线程 2GHZ JVM 内存:16GB 物理内存:32G |
8000-20000 | 1600-4000 | 500-800 | 双节点 CPU:8 核 16 线程 2GHZ JVM 内存:24GB 物理内存:48G | 双节点 CPU:8 核 16 线程 2GHZ JVM 内存:16GB 物理内存:32G |
10000-25000 | 2000-5000 | 800-1000 | 三节点 CPU:8 核 16 线程 2GHZ JVM 内存:32GB 物理内存:64G | 双节点 CPU:8 核 16 线程 2GHZ JVM 内存:24GB 物理内存:48G |
12000-30000 | 2400-6000 | 1000-1200 | 三节点 CPU:8 核 16 线程 2GHZ JVM 内存:32GB 物理内存:64G | 三节点 CPU:8 核 16 线程 2GHZ JVM 内存:24GB 物理内存:48G |
说明:
注册用户数:系统注册了的用户。
在线用户数:用户同时在一定时间段的在线数量(一般注册人数的 5% - 20% 之间)。
并发用户数:同时向服务器发送请求的用户数(一般是在线人数的 10% - 25% 左右)。
推荐配置时:70% 场景的平均响应时间低于 3s。
最低配置时:70% 场景的平均响应时间低于 5s。
2)修改方式
堆内内存的修改方法,请参见下方表格文档:
参数介绍 | 服务器类型 | 参考文档 |
---|---|---|
-Xmx 参数:最大堆内内存 -Xms 参数:初始化内存大小 注1:Xmx/Xms 与数字之间不要有空格 注2:建议配置Xms=Xmx,以防止内存扩容失败情况 | Tomcat 服务器 | Tomcat 服务器内存修改 |
WebLogic 服务器 | WebLogic 服务器内存修改 | |
WebSphere 服务器 | WebSphere 服务器 | |
JBoss 服务器 | JBoss 服务器 | |
Resin 服务器 | Resin 服务器内存修改 |
3.4.2 堆外内存
1)建议值
建议配置JVM NIO占用堆外内存2GB
2)修改方式
NIO由-XX:MaxDirectMemorySize这个参数控制。请根据自身工程部署情况选择修改方法。本节展示 Tomcat 环境下设置 NIO内存 的步骤。
Windows:进入%Tomcat_HOME%\bin目录。寻找名为setenv.bat的文件。如果文件不存在,可以创建一个新的setenv.bat文件。在文件中添加以下行来设置,配置完成后重启工程。
set JAVA_OPTS=%JAVA_OPTS% -XX:MaxDirectMemorySize=2g
Linux:进入%Tomcat_HOME%\bin目录。寻找名为setenv.sh的文件。如果文件不存在,可以创建一个新的setenv.sh文件。在文件中添加以下行来设置,配置完成后重启工程。
JAVA_OPTS="$JAVA_OPTS -XX:MaxDirectMemorySize=2g"
3.4.3 fineIO读内存
1)建议值
建议JVM fineIO读内存使用堆外内存设置为2G。
2)修改方式
fineIO 读内存由-Dfineio.read_mem_limit这个参数来设置。请根据自身工程部署情况选择修改方法。本节展示 Tomcat 环境下设置 fineIO读内存 的步骤。
读内存的默认单位为 GB,支持小数,但不支持使用 g、m 等。建议读内存为写内存的2-3倍,缓存大小建议与写内存大小一致。
Windows:进入%Tomcat_HOME%\bin目录。寻找名为setenv.bat的文件。如果文件不存在,可以创建一个新的setenv.bat文件。在文件中添加以下行来设置,配置完成后重启工程。
set JAVA_OPTS=%JAVA_OPTS% -Dfineio.read_mem_limit=2
Linux:进入%Tomcat_HOME%\bin目录。寻找名为setenv.sh的文件。如果文件不存在,可以创建一个新的setenv.sh文件。在文件中添加以下行来设置,配置完成后重启工程。
JAVA_OPTS="$JAVA_OPTS -Dfineio.read_mem_limit=2"
3.4.4 fineIO写内存
1)建议值
建议JVM fineIO写内存使用堆外内存设置为1G。
2)修改方式
fineIO 写内存由-Dfineio.write_mem_limit这个参数来设置。请根据自身工程部署情况选择修改方法。本节展示 Tomcat 环境下设置 fineIO写内存 的步骤。
写内存的默认单位为 GB,支持小数,但不支持使用 g、m 等。建议读内存为写内存的2-3倍,缓存大小建议与写内存大小一致。
Windows:进入%Tomcat_HOME%\bin目录。寻找名为setenv.bat的文件。如果文件不存在,可以创建一个新的setenv.bat文件。在文件中添加以下行来设置,配置完成后重启工程。
set JAVA_OPTS=%JAVA_OPTS% -Dfineio.write_mem_limit=1
Linux:进入%Tomcat_HOME%\bin目录。寻找名为setenv.sh的文件。如果文件不存在,可以创建一个新的setenv.sh文件。在文件中添加以下行来设置,配置完成后重启工程。
JAVA_OPTS="$JAVA_OPTS -Dfineio.write_mem_limit=1"
3.5 其他环境配置检查
注:如何通过帆软功能快捷运维
帆软提供系统检查功能,管理员登录数据决策系统,点击「管理系统>智能运维>系统检查」
「系统检查」中将根据系统使用情况对内存配置进行检查,当前配置不合理时将给出修改建议,并支持直接「查看建议配置」并对相应内存配置进行修改。
3.5.1 垃圾回收器
1)建议值
建议 JVM 使用垃圾回收器类型为 ParallelScavenge
2)修改方式
本节以工程部署在 Tomcat 上为例, 介绍设置垃圾收集器为Parallel Scavenge(并行收集器)的方法。
Windows:进入%Tomcat_HOME%\bin目录。寻找名为setenv.bat的文件。如果文件不存在,可以创建一个新的setenv.bat文件。在文件中添加以下行来设置,配置完成后重启工程。
set JAVA_OPTS= -XX:+UseParallelGC
Linux:进入%Tomcat_HOME%\bin目录。寻找名为setenv.sh的文件。如果文件不存在,可以创建一个新的setenv.sh文件。在文件中添加以下行来设置,配置完成后重启工程。
JAVA_OPTS="$JAVA_OPTS -XX:+UseParallelGC"
3.5.2 老年代和新生代比例
1)建议值
建议 JVM 老年代与新生代大小比例设置为 2
2)修改方式
堆内老年代与新生代大小比例建议为 2(-XX:NewRatio=2,JVM的默认值);NewRatio 大小正常生效需要用户不限制新生代大小。
在设置-Xmx、-Xms参数的位置,添加 NewRatio 的值即可,本节展示 Tomcat 环境下设置 NewRatio 的步骤。
Windows:进入%Tomcat_HOME%\bin目录。寻找名为setenv.bat的文件。如果文件不存在,可以创建一个新的setenv.bat文件。在文件中添加以下行来设置,配置完成后重启工程。
set JAVA_OPTS= -Xms512M -Xmx1024M -XX:NewRatio=2
Linux:进入%Tomcat_HOME%\bin目录。寻找名为setenv.sh的文件。如果文件不存在,可以创建一个新的setenv.sh文件。在文件中添加以下行来设置,配置完成后重启工程。
JAVA_OPTS="$JAVA_OPTS -Xms2048M -Xmx8196M -XX:NewRatio=2"
3.5.3 栈空间
1)建议值
建议单线程使用栈空间不超过1024KB
2)修改方式
建议单线程使用栈空间不超过1024KB,即 -Xss 的值不超过 1024 。
在设置-Xmx、-Xms参数的位置,添加 -Xss 的值即可,本节展示 Tomcat 环境下设置 -Xss 的步骤。
Windows:进入%Tomcat_HOME%\bin目录。寻找名为setenv.bat的文件。如果文件不存在,可以创建一个新的setenv.bat文件。在文件中添加以下行来设置,配置完成后重启工程。
set JAVA_OPTS= -Xms512M -Xmx1024M -Xss1024K
Linux:进入%Tomcat_HOME%\bin目录。寻找名为setenv.sh的文件。如果文件不存在,可以创建一个新的setenv.sh文件。在文件中添加以下行来设置,配置完成后重启工程。
JAVA_OPTS="$JAVA_OPTS -Xms2048M -Xmx8196M -Xss1024K"
3.5.4 单机多进程
单机使用多个进程存在宕机隐患,建议服务器内仅单独运行一个帆软应用,其他业务迁移到单独服务器中。
3.5.5 JDK版本
1)建议值
建议使用「JDK8」中 1.8.0_181 及以上版本
2)检查方式
cmd 命令行进入%Tomcat_home%\bin路径下,输入version,即可查看 JDK 版本。如下图所示:
3.5.6 finedb是否公用
建议每个工程单独使用自己的配置数据库,杜绝多工程共用一个finedb
3.5.7 DisableExplicitGC 参数
1)建议值
建议不对 DisableExplicitGC 参数进行配置,此项配置会导致 System.gc()被禁用,影响系统稳定性。
2)修改方式
-XX:+DisableExplicitGC参数的作用是禁用 System.gc()。System.gc() 是一种保护机制,例如堆外内存满时清理它的堆内引用对象.
用户需要根据实际情况选择是否使用该参数,建议删除该参数(删除下文设置的配置即可)。
本节展示 Tomcat 环境下设置 DisableExplicitGC 参数的步骤。
Windows:在%Tomcat%/bin目录下的catalina.bat文件中新增配置,配置完成后重启工程。
Linux:在%Tomcat%/bin目录下的catalina.sh文件中新增配置,配置完成后重启工程。
JAVA_OPTS="$JAVA_OPTS -XX:+DisableExplicitGC"
3.5.8 headless 模式
1)建议值
建议配置 -Djava.awt.headless=true 以启用 headless 模式
2)修改方式
headless 模式是系统的一种工作模式,如果系统属性 java.awt.headless被设置true,那么headless工具包就会被使用。
本节展示 Tomcat 环境下启用 headless 模式的步骤。
Windows:在%Tomcat%/bin目录下的catalina.bat文件中新增配置,配置完成后重启工程。
Linux:在%Tomcat%/bin目录下的catalina.sh文件中新增配置,配置完成后重启工程。
JAVA_OPTS="$JAVA_OPTS -Djava.awt.headless=true"
3.5.9 debug模式
1)建议值
建议取消debug模式
2)修改方式
debug模式由两个参数控制:-agentlib:jdwp 和 -Xrunjdwp,删除这两个参数即可取消debug模式
Windows:在%Tomcat%/bin目录下的catalina.bat和setenv.bat文件中删除-agentlib:jdwp 和 -Xrunjdwp参数,配置完成后重启工程。
Linux:在%Tomcat%/bin目录下的catalina.sh和setenv.sh文件中删除-agentlib:jdwp 和 -Xrunjdwp参数,配置完成后重启工程。
3.5.10 dump导出
1)建议值
建议配置HeapDumpOnOutOfMemoryError 及 HeapDumpPath以保证正常导出dump
2)修改方式
1)-XX:+HeapDumpOnOutOfMemoryError参数表示当JVM发生OOM时,自动生成DUMP文件。
2)-XX:HeapDumpPath=${目录}参数表示生成dump文件的路径,也可以指定文件名称,例如:-XX:HeapDumpPath=${目录}/java_heapdump.hprof。
如果不指定文件名,默认为:java_<pid>_<date>_<time>_heapDump.hprof。
本节展示 Tomcat 环境下设置dump导出的步骤。
Windows:进入%Tomcat_HOME%\bin目录。寻找名为setenv.bat的文件。如果文件不存在,可以创建一个新的setenv.bat文件。在文件中添加以下行来设置,配置完成后重启工程。
set JAVA_OPTS=%JAVA_OPTS% -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${目录}
Linux:进入%Tomcat_HOME%\bin目录。寻找名为setenv.sh的文件。如果文件不存在,可以创建一个新的setenv.sh文件。在文件中添加以下行来设置,配置完成后重启工程。
JAVA_OPTS="$JAVA_OPTS -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${目录}"
3.5.11 vm.max_map_count
1)参数简介:
vm.max_map_count是一个Linux系统内核参数,用于控制在一个进程中允许mmap映射内存区域的最大数量。
如果该参数的值太小,那么在使用一些应用程序时,可能会出现内存映射错误。
2)建议配置:
建议配置 vm.max_map_count 参数为 262144
3)修改方式:
在/etc/sysctl.conf文件中添加/修改参数值
vm.max_map_count=262144
运行以下命令使更改生效
sysctl -p
3.5.12 最大文件打开数(仅Linux系统关注)
1)参数简介:
open_files是指一个进程可以同时打开的文件描述符的最大数量。
文件描述符是Unix系统中用于访问文件(包括管道、套接字和其他文件操作)的唯一标识符。
2)建议配置:
建议FineReport工程的open_files参数配置不低于65536
建议FineBI工程的open_files参数配置不低于131070
3)修改方式:
修改参数配置
打开Linux的软硬件限制文件/etc/security/limits.conf,在文件尾部添加如下代码:
* soft nofile 65536
* hard nofile 65536
上述命令中,hard表示系统的硬限制,soft表示用户的软限制。
重启工程并重新登录
配置完成后,终端用户重新登录,并重启Tomcat工程,配置方可生效。
可使用ulimit -n命令,根据返回值确认是否修改成功。
3.5.13 recompilationCutoff(仅FineBI关注)
1)建议值
建议recompilationCutoff相关参数配置值为-1
2)修改方式
没有配置 RecompilationCutoff 参数/配置的 RecompilationCutoff 参数太小,可能会导致 spider 引擎数据更新缓慢。
本节展示 Tomcat 环境下设置 recompilationCutoff 参数的步骤。
Windows:进入%Tomcat_HOME%\bin目录。寻找名为setenv.bat的文件。如果文件不存在,可以创建一个新的setenv.bat文件。在文件中添加以下行来设置,配置完成后重启工程。
set JAVA_OPTS=%JAVA_OPTS% -XX:PerMethodRecompilationCutoff=-1 -XX:PerBytecodeRecompilationCutoff=-1
Linux:进入%Tomcat_HOME%\bin目录。寻找名为setenv.sh的文件。如果文件不存在,可以创建一个新的setenv.sh文件。在文件中添加以下行来设置,配置完成后重启工程。
JAVA_OPTS="$JAVA_OPTS -XX:PerMethodRecompilationCutoff=-1 -XX:PerBytecodeRecompilationCutoff=-1"
3.6 业务配置检查
检查项 | 建议值 | 修改方式 |
---|---|---|
finedb是否迁移 | 建议配置外接数据库,将finedb迁移至外接数据库中 | finedb迁移方法:配置外接数据库 |
日志清理周期 | 建议自动清理超过三个月的日志 | 在数据决策系统的「管理系统>智能运维>平台日志>全局设置」中「自动清理」周期设置为3个月,或手动清理超过3个月的日志 |
日志级别 | 建议设置日志级别为 ERROR | 在数据决策系统的「管理系统>智能运维>平台日志>全局设置」中,将日志级别设置为「INFO」 |
自动备份配置 | 建议自动备份默认保存不超过5份 | 在数据决策系统的「管理系统>智能运维>备份还原>全局设置」中,将份数上限设置为保留5份 |
定时调度任务清理配置 | 建议定时调度任务文件处理配置为「仅保留最近1次」或「任务结束即清理」 | 在数据决策系统的「定时调度>调度对象>文件处理」中,配置为「仅保留最近1次」或「任务结束即清理」 |
spark_memory_fracrtion | 建议spark_memory_fraction 参数设置不超过0.3*堆内内存的1/8且最大不超过0.6 | 若jvm堆内设置为32g,则spark_memory_fracrtion为0.6 若jvm堆内设置为8g,则spark_memory_fracrtion为0.3 |
resultSetRowLimit | 建议resultSetRowLimit配置不超过100w | 在BI数据决策系统的「管理系统>系统管理>常规>BI参数」 中设置「数据访问量」参数即可 |
spider_update_fast_compute_limit_cell | 建议spider_update_fast_compute_limit_cell 配置不超过10000 | 修改DistributedOptimizationConfig.spiderConfig.spider_update_fast_compute_limit_cell参数值不超过10000 修改方法请参考:FINE_CONF_ENTITY可视化配置 |
spark_driver_maxResultSize | 建议spark_driver_maxResultSize配置不超过1g | 修改DistributedOptimizationConfig.spiderConfig.spark_driver_maxResultSize参数值不超过1g 修改方法请参考:FINE_CONF_ENTITY可视化配置 |
spider_fast_compute_limit_row | 建议spider_fast_compute_limit_row配置不超过10000000 | 修改DistributedOptimizationConfig.spiderConfig.spider_fast_compute_limit_row参数值不超过10000000 修改方法请参考:FINE_CONF_ENTITY可视化配置 |
spider_fast_compute_limit_unit | 建议spider_fast_compute_limit_unit配置不超过10000000 | 修改DistributedOptimizationConfig.spiderConfig.spider_fast_compute_limit_unit参数值不超过10000000 修改方法请参考:FINE_CONF_ENTITY可视化配置 |
spider_fast_compute_limit_memory | 建议spider_fast_compute_limit_memory配置不超过500000000 | 修改DistributedOptimizationConfig.spiderConfig.spider_fast_compute_limit_memory参数值不超过500000000 修改方法请参考:FINE_CONF_ENTITY可视化配置 |
4. 基本维护
在应用日常的正常运行过程中,维护事务相对简单,在有需要的时候能够查看应用的运行日志,或查看应用的各项监控指标是否存在异常即可
4.1 日志查看
1)内容说明
帆软应用通常涉及以下几类日志:
日志类型 | 日志存储 | 日志内容 |
---|---|---|
系统日志 | 默认存储在%FR_HOME%\logs\fanruan.log 设计器端允许修改日志存储位置 服务器端不允许修改日志存储位置 | 记录系统运行过程中的一些信息 |
操作日志 | 存储在%FR_HOME%\webapps\webroot\logs\cubes 允许修改日志存储位置 FineReport11.0.4/FineBI5.1.22及之后版本支持实时备份 | 记录普通用户和管理员的使用动作 |
补充日志 | 存储在%FR_HOME%\bin\error.txt 不允许修改日志存储位置 | 记录设计器预期外的报错 |
gc.log | 默认存储在%FR_HOME%/logs/gclogs | 用来分析服务器gc(垃圾回收)的情况 |
catalina.out | Tomcat部署情况下存在 默认存储在%FR_HOME%/logs | tomcat及应用运行日志 |
catalina.log | Tomcat部署情况下存在 默认存储在%FR_HOME%/logs | tomcat自身运行日志 |
access.log | Tomcat部署情况下存在 默认存储在%FR_HOME%/logs | tomcat及应用访问日志,记录访问请求详情 |
2)如何通过帆软功能快捷运维
帆软提供下载日志功能,管理员登录数据决策系统,点击「管理系统>智能运维>平台日志」,其中「下载日志」Tab提供相应功能。
通过此功能可实现下载指定时间的指定日志,并支持查看日志存储位置。
4.2 监控指标
1)指标说明
日常运行中,运维人员主要需要关注以下各指标是否存在异常:
指标 | 监控内容 |
---|---|
内存 | 通过命令行或可视化查看服务器的内存使用情况,是否出现内存占用过高(80%及以上) |
CPU | 通过命令行或可视化查看服务器的CPU使用情况,是否出现CPU占用过高(80%及以上) |
磁盘空间 | 通过命令行或可视化查看帆软应用所在磁盘目录的磁盘空余情况,是否磁盘剩余空间过小(不足10GB) |
2)如何通过帆软功能快捷运维
帆软提供内存管理页面,点击「管理系统>智能运维>负载管理」,其中「负载监控」Tab提供相应功能(11.0.3及之前版本叫「内存管理」及「内存监控」)
通过此功能可实现可视化查看帆软应用而非整个服务器的近期「负载曲线」、「内存曲线」和「CPU曲线」,快速了解帆软应用运行及压力状况。
帆软提供磁盘运维功能,点击「管理系统>智能运维>磁盘运维」,其中「磁盘使用情况分析」Tab提供相应功能(11.0.3及之前版本暂不支持)
通过此功能可实现可视化查看帆软应用重点相关磁盘目录的使用情况,及时避免出现磁盘不足。
5. 异常维护
5.1 异常警告
如需对帆软应用的异常及时感知,需实现对帆软应用各项指标的监控告警,实现的方案有以下几点建议:
1)如使用的是云服务器(如阿里云、华为云等),可使用云服务厂商提供的监控类云服务,对服务器的资源异常进行监控
2)自行开发实现对于帆软应用的监控,如基于promthues组件等
3)针对系统负载过高的场景,帆软提供智能预警功能,检测到负载状态过高时将提醒运维人员。
管理员登录数据决策系统,点击「管理系统>智能运维>负载管理」,其中「负载监控」内可进行智能预警配置。
4)针对系统出现宕机的场景,帆软提供宕机通知功能,检测到系统宕机时将提醒运维人员。
管理员登录数据决策系统,点击「管理系统>智能运维>宕机处理」,其中「宕机处理」内可进行宕机通知配置。
5)针对系统磁盘空间不足的场景,帆软提供磁盘预警功能,检测到应用相关磁盘空间不足时,将提醒运维人员。
管理员登录数据决策系统,点击「管理系统>智能运维>磁盘运维」,其中「监控预警设置」tab页内可进行磁盘预警配置。
5.2 宕机处理
当应用出现异常时,宕机可能会随之发生,此时为了业务的可用,需要快速恢复应用,同时应尽量保存宕机时刻的日志信息,方便进行宕机原因定位及风险排除,避免再次出现类似异常。对于宕机,应进行以下运维动作:
1)保证系统环境有jdk工具,当应用发生宕机时,及时导出dump文件
进入到对应的jdk的bin目录
以linux+tomcat为例,查看pid的方式为使用ps -ef|grep tomcat管道过滤命令,查看对应的服务器进行pid。
使用命令jmap -dump:format=b,file=文件名 [pid]来生成dump。
2)自行开发对帆软应用是否存活的监控,并在发现其不可用时告知到运维人员,并通过自动化脚本重启应用,或人工进行监控及应用重启
重启或停止应用时需确保完全关闭工程相关进程,详情请参见:关闭或重启FineBI工程
3)在宕机发生后自行通过dump分析宕机原因或联系技术支持协助定位,并尽快排除宕机风险。
4)针对宕机场景,帆软提供应用存活监控功能,管理员登录数据决策系统,点击「管理系统>智能运维>宕机处理」。
通过「宕机处理」可以实现宕机消息通知,宕机日志自动导出,及宕机后自动重启恢复。
5)针对宕机定位,帆软提供宕机自助处理功能,管理员登录数据决策系统,点击「管理系统>智能运维>宕机处理」。
通过「宕机自助向导」可以对大多数的宕机原因给出分析结果并提供改进建议。
6. 备份与升级
6.1 备份还原
帆软系统需要定期进行备份,以确保在用户误操作、版本回退等场景下能够及时恢复,备份及还原方式如下:
1)自行备份:
定期将完整工程拷贝并压缩后,放在磁盘空间充足的目录或其他服务器上,并定期备份工程的外接配置数据库
2)通过帆软功能进行备份还原:
帆软平台提供备份还原的功能,支持对「平台配置」、「报表模板」、「BI模板」、「JAR 包」、「插件」进行备份还原。
默认备份路径为../backup,备份文件存储在工程的%FR_HOME%/webapps/webroot/backup文件夹下,支持修改为其他备份路径,在「全局设置」中进行配置
备份方式分为自动及手动,手动备份即手动创建一份备份,自动备份则按照设置的自动备份「备份频率」、「份数上限」、「备份容量」、「备份失败提醒」进行定期自动备份
备份内容如下:
备份内容 | 简介 | 备份生成的文件夹 |
---|---|---|
平台配置 | 备份系统的平台设置项 | config |
报表模板 | 备份%FineBI%\webapps\webroot\WEB-INF\reportlets文件夹中的模板 | reportlets |
BI 模板 | 备份%FineBI%\webapps\webroot\WEB-INF\dashboards文件夹中的模板 | dashboards |
JAR 包 | 备份%FineBI%\webapps\webroot\WEB-INF\lib文件夹中的 JAR 包 | jar |
插件 | 备份系统安装的插件 | plugins |
选择手动备份/自动备份下备份的文件,点击「还原按钮」,「确认」后即可进行还原,还原后重启服务器即可生效
不同内容还原生效的方式略有部分,详情如下表所示:
还原内容 | 描述 |
---|---|
平台配置 | 重启工程后,还原生效 注:平台配置处,不支持 2019-11-08 到 2020-07-17 的 |
报表模板 | 无需重启,立即生效
|
BI模板 | 无需重启,立即生效。但需同时还原「平台配置」,方可恢复仪表板 还原后,当前工程下的所有仪表板都会被删除,替换为备份的仪表板 |
JAR 包 | 重启工程后,还原生效 |
插件 | 无需重启,立即生效 |
6.2 更新升级
帆软产品会持续不断的迭代更新,可能增加新的功能或针对历史版本存在的问题进行修复,为了能获得更好的功能体验,客户往往也要跟随更新版本,本章仅介绍小版本升级方式,大版本升级请联系帆软技术人员进行协助,升级前需确保已进行备份操作,保证升级过程或升级后出现异常可以及时恢复可用状态不至于造成损失,备份方法可参考上一节。
1)人工更新 JAR 包:用户可以获取 JAR 包后手动替换更新, linux 系统和 windows 系统下操作方式一致。
2)用户可以向帆软技术人员索要升级jar包,获取后,替换服务器工程 %TOMCAT_HOME%/webapps/webroot/WEB-INF/lib下的老jar包,重启服务器即可完成升级。
3)BI更新升级前请先运行升级工具,在决策平台中点击「BI升级」进行检测,按指导处理完成升级风险项后进行人工更新。