反馈已提交
网络繁忙
针对常见的运维监控诉求场景,给出现有的运维监控功能方案介绍,帮助客户快速实现对于 FineReport 和 FineBI 应用的运维监控。
方案适用于已经完成部署的帆软系统,将会展开介绍帆软应用的日常维护、管理和监控方式。
帆软应用对系统有一定的配置要求,如果配置不符合要求可能出现使用异常、宕机等风险,因此需要定期对环境及应用的配置情况进行检测,以确保应用的健康运行。
同时管理员需要关注应用的运行状况,及时通过运维手段规避风险或在问题发生后定位并进行排除,实现应用的持续高可用。
本文方案将从以下几个方面展开介绍帆软应用的具体运维方式:
注:鉴于服务器情况不同,没有完全通用的解决方案。部分检查项仅提供推荐配置值,请自行百度修改方案。
1)关注磁盘的性能和使用情况,防止影响业务的正常运行
2)关注磁盘剩余空间,防止出现磁盘空间不足导致系统运行受影响
当应用出现异常时,宕机可能会随之发生
1)快速恢复应用
2)记录宕机日志,进行问题定位和排查
本章主要介绍帆软应用内的主要配置文件信息及其详细说明。
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文件。
2:Read Commited 可读已提交
1:Read Uncommited 可读未提交
平台中有些配置信息记录在 FineDB 的 fine_conf_entity 表中,只能通过修改表字段来进行更改。
用户可通过「fine_conf_entity可视化配置插件」安全地修改相关配置。
注:请勿使用该插件以外的方法修改 FineDB 文件,有可能造成不可修复的 BUG,需自行承担后果。
可修改的配置内容及修改方式请参见:FINE_CONF_ENTITY可视化配置
建议管理员使用「系统检查」功能,对系统进行定期巡检,确保应用所在的环境及应用内配置合理,以保证应用的正常运行。
巡检内容包括系统检查、系统运行状态、端口检查、网络检查、服务联通性检查、业务检查、环境检查、磁盘检查、非容器化部署检查、虚拟机检查。
系统检查的检测项包括:
仅输出信息
系统运行状态的检测项包括:
包括:插件名、插件版本、插件是否启用
包括:工程是否注册
检查工程WEB-INF下一层的每个文件夹大小
健康:不存在大于5G的文件夹
不健康:存在大于5G的文件夹,建议检查确认对应文件夹的内容并进行清理
注:仅检测本地,不检测文件服务器。
包括:目录路径、目录剩余可用空间
包括:目录路径
包括:是/否
包括:工程各个模块的版本和JAR包日期
端口检查的检测项包括:
管理员登录工程,点击「管理系统>智能运维>宕机处理」。
可查看宕机自动处理工具使用的端口。默认端口为12100。
可修改端口,点击「保存」即可。
可点击「测试」,测试端口可用性。
管理员登录数据决策平台,点击「管理系统>智能运维>集群配置」。
可查看集群各个节点的端口,无法使用的节点飘红。
可编辑节点端口,鼠标悬浮即可出现编辑按钮。
WebSocket 主要用于刷新 token、用户被踢出、平台消息、内存和 CPU 显示、平台日志处当前系统在线人数、数据连接编辑状态的确定。
WebSocket 不开放影响 socket 通信,访问可能异常断开。
用户可根据自己的工程情况选择合适的 WebSocket 端口配置方法,详情请参见下表:
只需用户环境满足生效条件,则自动使用该方案
若用户环境不满足生效条件,则可考虑自行配置socket.io方案
帆软的 Web 端对外开放的端口,不开放将无法正常访问页面
默认端口支持修改,使用文本编辑工具打开文件:%tomcat_home%\conf\server.xml
比如我们想将端口号改为 8081,则将 server.xml 的代码中的 connector port 作如下修改,并保存文件。
<Connector port="8081" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
修改完成后,需要重启 Tomcat 服务器。
检查文件服务器、外接数据库、状态服务器和应用之间通信是否正常,是否能够ping通,是否存在丢包情况。
服务联通性检查的检测项包括:
业务检查的检测项包括:
检测finedb数据库的类型
建议配置外接数据库,将finedb迁移至外接数据库中
外接数据库迁移请参见:配置外接数据库
检测「管理系统>智能运维>平台日志>全局设置」中的「系统日志级别」
建议设置日志级别为 ERROR
日志级别设置请参见:日志简介
检测「管理系统>智能运维>平台日志>全局设置」中「自动清理」周期
健康:配置了自动清理,自动清理超过三个月的日志
不健康:未配置自动清理
操作日志自动清理设置请参见:日志简介
检测「管理系统>智能运维>备份还原>全局设置」中设置的自动备份可占用磁盘大小
备份还原设置请参见:备份还原
检测「管理系统>智能运维>备份还原>全局设置」中设置的自动备份保留数量
建议自动备份默认保存不超过5份
检测定时调度任务>调度对象中,文件处理方式的设置
健康:仅保留最近一次或任务结束即清理
不健康:其他文件处理方式
定时调度任务设置请参见:定时调度任务设置
检测「管理系统>智能运维>负载管理>模板限制>通用限制」中的单模板单元格限制
健康:开启了单模板单元格限制
不健康:未开启单模板单元格限制
模板限制请参见:模板限制
检测系统是否配置二级缓存
二级缓存开启及配置请参见:指定ehcache缓存路径
检测「管理系统>智能运维>负载管理>模板限制>通用限制」中的导入Excel单元格限制
健康:开启了导入Excel单元格限制
不健康:未开启导入Excel单元格限制
检测「管理系统>智能运维>负载管理>负载监控」中是否开启「智能预警」
详情请参见:负载管理
检测「管理系统>智能运维>负载管理>模板限制>通用限制」中的单数据集行数限制
健康:开启了单数据集行数限制
不健康:未开启单数据集行数限制
检测「管理系统>智能运维>负载管理>模板限制>通用限制」中的sql执行时长限制
健康:开启了sql执行时长限制
不健康:未开启sql执行时长限制
检测「管理系统>智能运维>集群配置>参数配置」中的内部转发参数
集群参数配置请参见:集群参数配置
检测finedb外接数据库的数据库编码/字符集
外接数据库配置步骤请参见:配置外接数据库
检测「管理系统>系统管理>常规>BI参数」 中的「数据访问量」参数
健康:不超过100w
不健康:超过100w
BI参数配置请参见:BI/Spider参数
检测系统的spider_fast_compute_limit_unit参数值
健康:DistributedOptimizationConfig.spiderConfig.spider_fast_compute_limit_unit参数值不超过10000000
不健康:DistributedOptimizationConfig.spiderConfig.spider_fast_compute_limit_unit参数值超过10000000
参数值修改方法请参考:FINE_CONF_ENTITY可视化配置
检测系统的spider_fast_compute_limit_row参数值
健康:DistributedOptimizationConfig.spiderConfig.spider_fast_compute_limit_row参数值不超过10000000
不健康:DistributedOptimizationConfig.spiderConfig.spider_fast_compute_limit_row参数值超过10000000
检测系统的spider_update_fast_compute_limit_cell参数值
健康:DistributedOptimizationConfig.spiderConfig.spider_update_fast_compute_limit_cell参数值不超过10000
不健康:DistributedOptimizationConfig.spiderConfig.spider_update_fast_compute_limit_cell参数值超过10000
检测系统的spider_fast_compute_limit_memory参数值
健康:DistributedOptimizationConfig.spiderConfig.spider_fast_compute_limit_memory参数值不超过500000000
不健康:DistributedOptimizationConfig.spiderConfig.spider_fast_compute_limit_memory参数值超过500000000
检测系统的spiderConfig.spark_driver_maxResultSize参数值
健康:DistributedOptimizationConfig.spiderConfig.spark_driver_maxResultSize参数值不超过10000000
不健康:DistributedOptimizationConfig.spiderConfig.spark_driver_maxResultSize参数值超过10000000
检测「管理系统>系统管理>常规>抽取参数」 中的「更新高性能时间区间」参数
环境检查的检测项包括:
检测vm.max_map_count参数值
max_map_count文件包含限制一个进程可以拥有的VMA(虚拟内存区域)的数量
健康:vm.max_map_count≥262144
不健康:vm.max_map_count<262144
建议配置 vm.max_map_count 参数为 262144
Linux 环境下设置 vm.max_map_count 参数的语句为:
vim /etc/sysctl.conf
vm.max_map_count=262144
sysctl -p
检测open_files参数值
仅Linux系统需要关注该参数
健康:open_files≥65536
不健康:open_files<65536
建议open_files参数配置不低于65536
修改Linux的软硬件限制文件/etc/security/limits.conf,在文件尾部添加如下代码, 配置完成后重启工程即可生效
* soft nofile 65536* hard nofile 65536
检测/etc/profile 文件是否配置了export MALLOC_ARENA_MAX参数
健康:export MALLOC_ARENA_MAX=1
不健康:未配置/配置其他值
磁盘检查的检测项包括:
包括:磁盘所有空间大小
包括:已使用的磁盘空间大小
包括:磁盘未使用的空间大小
包括:顺序读取的速度
包括:顺序写的速度
包括:随机读的速度
包括:每秒创建小文件个数
包括:每秒删除小文件个数
检查原因:
磁盘读取性能及磁盘写入性能会对帆软的业务产生影响,因此需要关注磁盘的性能和使用情况。
若系统使用了 FineBI 抽取服务,那么对于磁盘的读写性能有一定的要求,建议磁盘的写入速度需要在100M/s以上,否则可能影响业务的正常运行。
若系统未使用 FineBI 抽取服务,帆软应用通常对于磁盘读取性能没有严格要求,但日常运维中需要关注磁盘的IO情况,并依此判断磁盘性能是否足够。
检查方法:
以 Linux 系统为例。
以M为单位展示详细的磁盘读取负载情况
需要特别关注以下四个参数:
w_await:平均每次写I/O操作的等待时间
r_await:平均每次读I/O操作的等待时间
%util: 一秒中有百分之多少的时间用于 I/O 操作,即被io消耗的cpu百分比
%iowait:CPU等待输入输出完成时间的百分比
w_await和r_await这两个值越高,说明写入/读取需要等待的时间越长
%util和%iowait这两个值越高,说明当前系统的磁盘使用率非常高,且cpu大部分时间处于等I/O的状态
这个时候,往往说明I/O遇到了瓶颈,此时建议提升磁盘性能
随着帆软应用的运行,可能会产生越来越多的日志、备份、缓存文件等,对于磁盘空间的占用也会渐渐变大,如果不关注磁盘剩余空间可能出现磁盘空间不足导致系统运行受影响,严重时甚至会导致宕机。
管理员需要关注root根目录、db更新目录、temp目录、schedule目录、备份目录、logs目录、工程目录、polors缓存目录所在磁盘的剩余空间情况,如以上几个目录所在磁盘剩余空间较小时,建议进行磁盘清理或扩容,确保有充足的空间保证帆软应用的正常运行。
定期清理帆软应用中的过期或无效内容,保持磁盘空间的健康。
FineReport11.0.4 /FineBI 5.1.22 及之后版本的工程,新增「磁盘运维」功能。用户可以安全便捷的清理磁盘,不造成业务文件丢失风险,预防磁盘问题带来的宕机问题。
对工程中的每个目录进行梳理,明确可以清理的内容以及可以清理的范围
对工程中不同目录中的内容进行说明(包括文件用处说明、占用空间大小等),并给出清理建议
对磁盘常用目录的增减情况进行监控,用于做磁盘异常预警
对磁盘使用过程进行监控,发现增长异常及时预警
非容器化部署的检测项包括:
包括:用户名称
包括:缓存文件夹、resources、assets、assist、finedb的权限
Java虚拟机的检测项包括:
建议取消debug模式,删除两个参数 -agentlib:jdwp 和 -Xrunjdwp
1)建议值
单机
CPU:8 核 16 线程 2GHZ
JVM 内存:16GB
物理内存:32G
JVM 内存:8GB
物理内存:16G
JVM 内存:24GB
物理内存:48G
双节点
三节点
JVM 内存:32GB
物理内存:64G
说明:
注册用户数:系统注册了的用户。
在线用户数:用户同时在一定时间段的在线数量(一般注册人数的 5% - 20% 之间)。
并发用户数:同时向服务器发送请求的用户数(一般是在线人数的 10% - 25% 左右)。
推荐配置时:70% 场景的平均响应时间低于 3s。
最低配置时:70% 场景的平均响应时间低于 5s。
2)修改方式
堆内内存的修改方法,请参见下方表格文档:
-Xmx 参数:最大堆内内存
-Xms 参数:初始化内存大小
注1:Xmx/Xms 与数字之间不要有空格
注2:建议配置Xms=Xmx,以防止内存扩容失败情况
建议JVM fineIO读内存使用堆外内存设置为2G。
fineIO 读内存由-Dfineio.read_mem_limit这个参数来设置。请根据自身工程部署情况选择修改方法。本节展示 Tomcat 环境下设置 fineIO读内存 的步骤。
读内存的默认单位为 GB,支持小数,但不支持使用 g、m 等。建议读内存为写内存的2-3倍,缓存大小建议与写内存大小一致。
Windows:在%Tomcat%/bin目录下的catalina.bat文件中新增配置,配置完成后重启工程。
set JAVA_OPTS=%JAVA_OPTS% -Dfineio.read_mem_limit=2
Linux:在%Tomcat%/bin目录下的catalina.sh文件中新增配置,配置完成后重启工程。
JAVA_OPTS="$JAVA_OPTS -Dfineio.read_mem_limit=2"
建议JVM fineIO写内存使用堆外内存设置为1G。
fineIO 写内存由-Dfineio.write_mem_limit这个参数来设置。请根据自身工程部署情况选择修改方法。本节展示 Tomcat 环境下设置 fineIO写内存 的步骤。
写内存的默认单位为 GB,支持小数,但不支持使用 g、m 等。建议读内存为写内存的2-3倍,缓存大小建议与写内存大小一致。
set JAVA_OPTS=%JAVA_OPTS% -Dfineio.write_mem_limit=1
JAVA_OPTS="$JAVA_OPTS -Dfineio.write_mem_limit=1"
建议配置 -Djava.awt.headless=true 以启用 headless 模式
headless 模式是系统的一种工作模式,如果系统属性 java.awt.headless被设置true,那么headless工具包就会被使用。
本节展示 Tomcat 环境下启用 headless 模式的步骤。
set JAVA_OPTS=%JAVA_OPTS% -Djava.awt.headless=true
JAVA_OPTS="$JAVA_OPTS -Djava.awt.headless=true"
建议配置HeapDumpOnOutOfMemoryError 及 HeapDumpPath以保证正常导出dump
1)-XX:+HeapDumpOnOutOfMemoryError参数表示当JVM发生OOM时,自动生成DUMP文件。
2)-XX:HeapDumpPath=${目录}参数表示生成dump文件的路径,也可以指定文件名称,例如:-XX:HeapDumpPath=${目录}/java_heapdump.hprof。
如果不指定文件名,默认为:java_<pid>_<date>_<time>_heapDump.hprof。
本节展示 Tomcat 环境下设置dump导出的步骤。
set JAVA_OPTS=%JAVA_OPTS% -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${目录}
JAVA_OPTS="$JAVA_OPTS -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${目录}"
建议不对 DisableExplicitGC 参数进行配置,此项配置会导致 System.gc()被禁用,影响系统稳定性。
-XX:+DisableExplicitGC参数的作用是禁用 System.gc()。System.gc() 是一种保护机制,例如堆外内存满时清理它的堆内引用对象.
用户需要根据实际情况选择是否使用该参数,建议删除该参数(删除下文设置的配置即可)。
本节展示 Tomcat 环境下设置 DisableExplicitGC 参数的步骤。
set JAVA_OPTS=%JAVA_OPTS% -XX:+DisableExplicitGC
JAVA_OPTS="$JAVA_OPTS -XX:+DisableExplicitGC"
建议使用「JDK8」中 1.8.0_181 及以上版本
2)检查方式
cmd 命令行进入%Tomcat_home%\bin路径下,输入version,即可查看 JDK 版本。如下图所示:
建议单线程使用栈空间不超过1024KB
建议单线程使用栈空间不超过1024KB,即 -Xss 的值不超过 1024 。
在设置-Xmx、-Xms参数的位置,添加 -Xss 的值即可,本节展示 Tomcat 环境下设置 -Xss 的步骤。
set JAVA_OPTS= -Xms512M -Xmx1024M -Xss1024K
Linux 系统:在%Tomcat%/bin目录下的catalina.sh文件中新增配置,配置完成后重启工程。
JAVA_OPTS="$JAVA_OPTS -Xms2048M -Xmx8196M -Xss1024K"
建议 JVM 使用垃圾回收器类型为 ParallelScavenge
本节以工程部署在 Tomcat 上为例, 介绍设置垃圾收集器为Parallel Scavenge(并行收集器)的方法。
Windows 系统:打开%Tomcat%/bin目录下的catalina.bat文件进行配置,配置完成后重启工程即可生效。
set JAVA_OPTS= -XX:+UseParallelGC
Linux:打开%Tomcat%/bin目录下的catalina.sh文件进行配置,配置完成后重启工程即可生效。
JAVA_OPTS="$JAVA_OPTS -XX:+UseParallelGC"
建议 JVM 老年代与新生代大小比例设置为 2
堆内老年代与新生代大小比例建议为 2(-XX:NewRatio=2,JVM的默认值);NewRatio 大小正常生效需要用户不限制新生代大小。
在设置-Xmx、-Xms参数的位置,添加 NewRatio 的值即可,本节展示 Tomcat 环境下设置 NewRatio 的步骤。
set JAVA_OPTS= -Xms512M -Xmx1024M -XX:NewRatio=2
JAVA_OPTS="$JAVA_OPTS -Xms2048M -Xmx8196M -XX:NewRatio=2"
建议recompilationCutoff相关参数配置值为-1
没有配置 RecompilationCutoff 参数/配置的 RecompilationCutoff 参数太小,可能会导致 spider 引擎数据更新缓慢。
本节展示 Tomcat 环境下设置 recompilationCutoff 参数的步骤。
set JAVA_OPTS=%JAVA_OPTS% -XX:PerMethodRecompilationCutoff=-1 -XX:PerBytecodeRecompilationCutoff=-1
JAVA_OPTS="$JAVA_OPTS -XX:PerMethodRecompilationCutoff=-1 -XX:PerBytecodeRecompilationCutoff=-1"
建议取消debug模式
debug模式由两个参数控制:-agentlib:jdwp 和 -Xrunjdwp,删除这两个参数即可取消debug模式
Windows:在%Tomcat%/bin目录下的catalina.bat文件中删除-agentlib:jdwp 和 -Xrunjdwp参数,配置完成后重启工程。
Linux:在%Tomcat%/bin目录下的catalina.sh文件中删除-agentlib:jdwp 和 -Xrunjdwp参数,配置完成后重启工程。
建议配置-Dsun.zip.disableMemoryMapping=true
配置该参数,可预防 jvm crash
set JAVA_OPTS=%JAVA_OPTS% -Dsun.zip.disableMemoryMapping=true
JAVA_OPTS="$JAVA_OPTS -Dsun.zip.disableMemoryMapping=true"
建议配置-Duser.country=CN、-Duser.language=zh
为了防止中文出现乱码现象,要配置好Tomcat 的语言编码
set JAVA_OPTS=%JAVA_OPTS% -Duser.country=CN -Duser.language=zh
JAVA_OPTS="$JAVA_OPTS -Duser.country=CN -Duser.language=zh"
建议配置-XX:ReservedCodeCacheSize=250m
ReservedCodeCacheSize参数是调整内存大小的一个设置参数,值的大小设置直接影响到Code Cache的大小。
如果Code Cache的空间不足,可能会导致JVM无法正常运行,导致性能持续降低。
set JAVA_OPTS=%JAVA_OPTS% -XX:ReservedCodeCacheSize=250m
JAVA_OPTS="$JAVA_OPTS -XX:ReservedCodeCacheSize=250m"
在应用日常的正常运行过程中,维护事务相对简单,在有需要的时候能够查看应用的运行日志,或查看应用的各项监控指标是否存在异常即可
应用日常的维护工作中,经常会需要对应用进行启停重启等操作。
单机环境依赖较少,无严格顺序需求。
集群环境相关组件较多,为尽量降低应用使用的风险,请尽量按以下顺序进行启停
由于应用的正常运行对组件有依赖,因此需要先启动相关组件,再启动应用。顺序为:
1)负载均衡组件(Nginx)
2)状态服务器组件(Redis)
3)文件服务器组件(FTP)
4)外接数据库组件(Mysql)
5)帆软应用(集群依次启动各节点即可)
各组件和应用可以配置开机自启动,便于在重启服务器后自动启动恢复服务:
Redis集群开机自启动
Redis单机开机自启动
Nginx 开机自启动脚本
Linux下Tomcat开机自启动
Windows下Tomcat开机自启动
对于应用的停止顺序没有严格要求,但由于组件的关闭会直接导致应用不可用,因此建议先关闭帆软应用(kill命令避免进程残留),再关闭各个组件
1)内容说明
帆软应用通常涉及以下几类日志:
默认存储在%FR_HOME%\logs\fanruan.log
设计器端允许修改日志存储位置
服务器端不允许修改日志存储位置
存储在%FR_HOME%\webapps\webroot\logs\cubes
允许修改日志存储位置
FineReport11.0.4/FineBI5.1.22及之后版本支持实时备份
存储在%FR_HOME%\bin\error.txt
不允许修改日志存储位置
Tomcat部署情况下存在
默认存储在%FR_HOME%/logs
2)如何通过帆软功能快捷运维
帆软提供下载日志功能,管理员登录数据决策系统,点击「管理系统>智能运维>平台日志」,其中「下载日志」Tab提供相应功能。
通过此功能可实现下载指定时间的指定日志,并支持查看日志存储位置。
1)指标说明
日常运行中,运维人员主要需要关注以下各指标是否存在异常:
帆软提供内存管理页面,点击「管理系统>智能运维>负载管理」,其中「负载监控」Tab提供相应功能(11.0.3及之前版本叫「内存管理」及「内存监控」)
通过此功能可实现可视化查看帆软应用而非整个服务器的近期「负载曲线」、「内存曲线」和「CPU曲线」,快速了解帆软应用运行及压力状况。
帆软提供磁盘运维功能,点击「管理系统>智能运维>磁盘运维」,其中「磁盘使用情况分析」Tab提供相应功能(11.0.3及之前版本暂不支持)
通过此功能可实现可视化查看帆软应用重点相关磁盘目录的使用情况,及时避免出现磁盘不足。
如需对帆软应用的异常及时感知,需实现对帆软应用各项指标的监控告警,实现的方案有以下几点建议:
1)如使用的是云服务器(如阿里云、华为云等),可使用云服务厂商提供的监控类云服务,对服务器的资源异常进行监控
2)自行开发实现对于帆软应用的监控,如基于promthues组件等
3)针对系统负载过高的场景,帆软提供智能预警功能,检测到负载状态过高时将提醒运维人员。
管理员登录数据决策系统,点击「管理系统>智能运维>负载管理」,其中「负载监控」内可进行智能预警配置。
4)针对系统出现宕机的场景,帆软提供宕机通知功能,检测到系统宕机时将提醒运维人员。
管理员登录数据决策系统,点击「管理系统>智能运维>宕机处理」,其中「宕机处理」内可进行宕机通知配置。
5)针对系统磁盘空间不足的场景,帆软提供磁盘预警功能,检测到应用相关磁盘空间不足时,将提醒运维人员。
管理员登录数据决策系统,点击「管理系统>智能运维>磁盘运维」,其中「磁盘预警设置」tab页内可进行磁盘预警配置。
当应用出现异常时,宕机可能会随之发生,此时为了业务的可用,需要快速恢复应用,同时应尽量保存宕机时刻的日志信息,方便进行宕机原因定位及风险排除,避免再次出现类似异常。对于宕机,应进行以下运维动作:
1)保证系统环境有jdk工具,当应用发生宕机时,及时导出dump文件
进入到对应的jdk的bin目录
以linux+tomcat为例,查看pid的方式为使用ps -ef|grep tomcat管道过滤命令,查看对应的服务器进行pid。
使用命令jmap -dump:format=b,file=文件名 [pid]来生成dump。
2)自行开发对帆软应用是否存活的监控,并在发现其不可用时告知到运维人员,并通过自动化脚本重启应用,或人工进行监控及应用重启
重启或停止应用时需确保完全关闭工程相关进程,详情请参见:关闭或重启FineReport工程
3)在宕机发生后自行通过dump分析宕机原因或联系技术支持协助定位,并尽快排除宕机风险。
4)针对宕机场景,帆软提供应用存活监控功能,管理员登录数据决策系统,点击「管理系统>智能运维>宕机处理」。
通过「宕机处理」可以实现宕机消息通知,宕机日志自动导出,及宕机后自动重启恢复。
5)针对宕机定位,帆软提供宕机自助处理功能,管理员登录数据决策系统,点击「管理系统>智能运维>宕机处理」。
通过「宕机自助向导」可以对大多数的宕机原因给出分析结果并提供改进建议。
帆软系统需要定期进行备份,以确保在用户误操作、版本回退等场景下能够及时恢复,备份及还原方式如下:
1)自行备份:
定期将完整工程拷贝并压缩后,放在磁盘空间充足的目录或其他服务器上,并定期备份工程的外接配置数据库
2)通过帆软功能进行备份还原:
帆软平台提供备份还原的功能,支持对「平台配置」、「报表模板」、「BI模板」、「JAR 包」、「插件」进行备份还原。
默认备份路径为../backup,备份文件存储在工程的%FR_HOME%/webapps/webroot/backup文件夹下,支持修改为其他备份路径,在「全局设置」中进行配置
备份方式分为自动及手动,手动备份即手动创建一份备份,自动备份则按照设置的自动备份「备份频率」、「份数上限」、「备份容量」、「备份失败提醒」进行定期自动备份
备份内容如下:
备份%FineBI%\webapps\webroot\WEB-INF\dashboards文件夹中的模板
选择手动备份/自动备份下备份的文件,点击「还原按钮」,「确认」后即可进行还原,还原后重启服务器即可生效
不同内容还原生效的方式略有部分,详情如下表所示:
重启工程后,还原生效
注:平台配置处,不支持 2019-11-08 到 2020-07-17 的
无需重启,立即生效
当前工程下没有、备份中有的模板会新增
当前工程下有、备份中有的模板会覆盖更新
当前工程下有、备份中没有的模板会保留
无需重启,立即生效。但需同时还原「平台配置」,方可恢复仪表板
还原后,当前工程下的所有仪表板都会被删除,替换为备份的仪表板
帆软产品会持续不断的迭代更新,可能增加新的功能或针对历史版本存在的问题进行修复,为了能获得更好的功能体验,客户往往也要跟随更新版本,本章仅介绍小版本升级方式,大版本升级请联系帆软技术人员进行协助,具体更新升级方式如下:
1)决策平台管理升级(不适用于BI):
打开数据决策系统,在「管理系统>智能运维>备份还原>更新升级」点击「立刻更新」按钮,等待更新 JAR,成功后重启 Web 服务器即可。
2)升级前需确保已进行备份操作,保证升级过程或升级后出现异常可以及时恢复可用状态不至于造成损失,备份方法可参考上一节
3)人工更新 JAR 包:用户可以获取 JAR 包后手动替换更新, linux 系统和 windows 系统下操作方式一致。
4)用户可以向帆软技术人员索要升级jar包,获取后,替换服务器工程 %TOMCAT_HOME%/webapps/webroot/WEB-INF/lib下的老jar包,重启服务器即可完成升级。
5)BI更新升级前请先运行升级工具,在决策平台中点击「BI升级」进行检测,按指导处理完成升级风险项后进行人工更新。
售前咨询电话
400-811-8890转1
在线技术支持
请前往「服务平台」,选择「在线支持」
热线电话:400-811-8890转2
总裁办24H投诉
热线电话:173-1278-1526
文 档反 馈
鼠标选中内容,快速反馈问题
鼠标选中存在疑惑的内容,即可快速反馈问题,我们将会跟进处理。
不再提示
10s后关闭