运维监控指导手册

1.1 版本

1.2 应用场景

针对常见的运维监控诉求场景，给出现有的运维监控功能方案介绍，帮助客户快速实现对于 FineReport 和 FineBI 应用的运维监控。

方案适用于已经完成部署的帆软系统，将会展开介绍帆软应用的日常维护、管理和监控方式。

1.3 功能简介

帆软应用对系统有一定的配置要求，如果配置不符合要求可能出现使用异常、宕机等风险，因此需要定期对环境及应用的配置情况进行检测，以确保应用的健康运行。

同时管理员需要关注应用的运行状况，及时通过运维手段规避风险或在问题发生后定位并进行排除，实现应用的持续高可用。

本文方案将从以下几个方面展开介绍帆软应用的具体运维方式：

注：鉴于服务器情况不同，没有完全通用的解决方案。部分检查项仅提供推荐配置值，请自行百度修改方案。

本章主要介绍帆软应用内的主要配置文件信息及其详细说明。

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文件。

2.2 平台配置信息

平台中有些配置信息记录在 FineDB 的 fine_conf_entity 表中，只能通过修改表字段来进行更改。

用户可通过「fine_conf_entity可视化配置插件」安全地修改相关配置。

注：请勿使用该插件以外的方法修改 FineDB 文件，有可能造成不可修复的 BUG，需自行承担后果。

可修改的配置内容及修改方式请参见：FINE_CONF_ENTITY可视化配置

建议管理员对系统进行定期巡检，确保应用所在的环境及应用内配置合理，以保证应用的正常运行。

巡检内容包括端口检查、网络服务检查、存储服务检查、环境配置检查以及业务配置检查。

3.1 端口检查

帆软应用正常使用过程中，需要服务器开放一些端口，因此需要对这些端口进行检查是否开放，避免出现系统功能异常。

<Connector port="8081" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" />

3.2 网络服务检查

检查一下文件服务器、外接数据库、状态服务器和应用之间通信是否正常，是否能够ping通，是否存在丢包情况。

3.3 存储服务检查

3.3.1 磁盘性能检查

检查原因：

磁盘读取性能及磁盘写入性能会对帆软的业务产生影响，因此需要关注磁盘的性能和使用情况。

• 若系统使用了 FineBI 抽取服务，那么对于磁盘的读写性能有一定的要求，建议磁盘的写入速度需要在100M/s以上，否则可能影响业务的正常运行。

• 若系统未使用 FineBI 抽取服务，帆软应用通常对于磁盘读取性能没有严格要求，但日常运维中需要关注磁盘的IO情况，并依此判断磁盘性能是否足够。

检查方法：

1）FineBI 功能

管理员登录数据决策系统，点击「BI工具>磁盘空间管理>磁盘性能」，点击「测试磁盘」，即可进行磁盘写入性能检测。

若磁盘写入速度在100M/s以下，建议提升磁盘性能，避免影响业务的正常运行。

2）iostat工具

以 Linux 系统为例。

3.3.2 磁盘剩余空间检查

随着帆软应用的运行，可能会产生越来越多的日志、备份、缓存文件等，对于磁盘空间的占用也会渐渐变大，如果不关注磁盘剩余空间可能出现磁盘空间不足导致系统运行受影响，严重时甚至会导致宕机。

管理员需要关注root根目录、db更新目录、temp目录、schedule目录、备份目录、logs目录、工程目录、polors缓存目录所在磁盘的剩余空间情况，如以上几个目录所在磁盘剩余空间较小时，建议进行磁盘清理或扩容，确保有充足的空间保证帆软应用的正常运行。

定期清理帆软应用中的过期或无效内容，保持磁盘空间的健康。

3.4 内存配置检查

注：如何通过帆软功能快捷运维

帆软提供系统检查功能，管理员登录数据决策系统，点击「管理系统>智能运维>系统检查」

「系统检查」中将根据系统使用情况对内存配置进行检查，当前配置不合理时将给出修改建议，并支持直接「查看建议配置」并对相应内存配置进行修改。

3.4.1 物理内存及堆内内存

1）建议值

说明：

• 注册用户数：系统注册了的用户。

• 在线用户数：用户同时在一定时间段的在线数量（一般注册人数的 5％ - 20％ 之间）。

• 并发用户数：同时向服务器发送请求的用户数（一般是在线人数的 10% - 25% 左右)。
  

• 推荐配置时：70% 场景的平均响应时间低于 3s。

• 最低配置时：70% 场景的平均响应时间低于 5s。

2）修改方式

堆内内存的修改方法，请参见下方表格文档：

3.4.2 堆外内存

1）建议值

建议堆外内存设置为2GB。

2）修改方式

堆外内存由-XX:MaxDirectMemorySize这个参数来设置。本文以工程部署在 Tomcat 上为例介绍修改方法。

• Windows：修改%Tomcat%/bin目录下的 catalina.bat 文件，增加配置，配置完成后重启工程。

set JAVA_OPTS=%JAVA_OPTS% -XX:MaxDirectMemorySize=2g

• Linux/Unix：修改%Tomcat%/bin目录下的 catalina.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%/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"

3.4.4 fineIO写内存

1）建议值

建议JVM fineIO写内存使用堆外内存设置为1G。

2）修改方式

fineIO 写内存由-Dfineio.write_mem_limit这个参数来设置。请根据自身工程部署情况选择修改方法。本节展示 Tomcat 环境下设置 fineIO写内存 的步骤。

写内存的默认单位为 GB，支持小数，但不支持使用 g、m 等。建议读内存为写内存的2-3倍，缓存大小建议与写内存大小一致。

• Windows：在%Tomcat%/bin目录下的catalina.bat文件中新增配置，配置完成后重启工程。

set JAVA_OPTS=%JAVA_OPTS% -Dfineio.write_mem_limit=1

• Linux：在%Tomcat%/bin目录下的catalina.sh文件中新增配置，配置完成后重启工程。

JAVA_OPTS="$JAVA_OPTS -Dfineio.write_mem_limit=1"

3.5 其他环境配置检查

注：如何通过帆软功能快捷运维

帆软提供系统检查功能，管理员登录数据决策系统，点击「管理系统>智能运维>系统检查」

「系统检查」中将根据系统使用情况对内存配置进行检查，当前配置不合理时将给出修改建议，并支持直接「查看建议配置」并对相应内存配置进行修改。

3.5.1 垃圾回收器

1）建议值

建议 JVM 使用垃圾回收器类型为 ParallelScavenge

2）修改方式

本节以工程部署在 Tomcat 上为例， 介绍设置垃圾收集器为Parallel Scavenge（并行收集器）的方法。

• Windows 系统：打开%Tomcat%/bin目录下的catalina.bat文件进行配置，配置完成后重启工程即可生效。

set JAVA_OPTS= -XX:+UseParallelGC

• Linux：打开%Tomcat%/bin目录下的catalina.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%/bin目录下的catalina.bat文件中新增配置，配置完成后重启工程。

set JAVA_OPTS= -Xms512M -Xmx1024M -XX:NewRatio=2

• Linux：在%Tomcat%/bin目录下的catalina.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%/bin目录下的catalina.bat文件中新增配置，配置完成后重启工程。

set JAVA_OPTS= -Xms512M -Xmx1024M -Xss1024K

• Linux 系统：在%Tomcat%/bin目录下的catalina.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文件中新增配置，配置完成后重启工程。

set JAVA_OPTS=%JAVA_OPTS% -XX:+DisableExplicitGC

• 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文件中新增配置，配置完成后重启工程。

set JAVA_OPTS=%JAVA_OPTS% -Djava.awt.headless=true

• 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文件中删除-agentlib:jdwp 和 -Xrunjdwp参数，配置完成后重启工程。

• Linux：在%Tomcat%/bin目录下的catalina.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 环境下设置 recompilationCutoff 参数的步骤。

• Windows：在%Tomcat%/bin目录下的catalina.bat文件中新增配置，配置完成后重启工程。

set JAVA_OPTS=%JAVA_OPTS% -XX:+HeapDumpOnOutOfMemoryError  -XX:HeapDumpPath=${目录}

• Linux：在%Tomcat%/bin目录下的catalina.sh文件中新增配置，配置完成后重启工程。

JAVA_OPTS="$JAVA_OPTS -XX:+HeapDumpOnOutOfMemoryError  -XX:HeapDumpPath=${目录}"

3.5.11 vm.max_map_count

1）建议值

建议配置 vm.max_map_count 参数为 262144

2）修改方式

max_map_count文件包含限制一个进程可以拥有的VMA(虚拟内存区域)的数量

建议配置 vm.max_map_count 参数为 262144，本节展示 Linux 环境下设置 vm.max_map_count 参数的步骤。

vim /etc/sysctl.conf

vm.max_map_count=262144

sysctl -p

3.5.12 最大文件打开数（仅Linux系统关注）

1）建议值

建议open_files参数配置不低于65536

2）修改方式

修改linux的软硬件限制文件/etc/security/limits.conf，在文件尾部添加如下代码， 配置完成后重启工程即可生效。

* soft nofile 65536
* hard nofile 65536

3.5.13 recompilationCutoff（仅FineBI关注）

1）建议值

建议recompilationCutoff相关参数配置值为-1

2）修改方式

没有配置 RecompilationCutoff 参数/配置的 RecompilationCutoff 参数太小，可能会导致 spider 引擎数据更新缓慢。

本节展示 Tomcat 环境下设置 recompilationCutoff 参数的步骤。

• Windows：在%Tomcat%/bin目录下的catalina.bat文件中新增配置，配置完成后重启工程。

set JAVA_OPTS=%JAVA_OPTS% -XX:PerMethodRecompilationCutoff=-1 -XX:PerBytecodeRecompilationCutoff=-1

• Linux：在%Tomcat%/bin目录下的catalina.sh文件中新增配置，配置完成后重启工程。

JAVA_OPTS="$JAVA_OPTS -XX:PerMethodRecompilationCutoff=-1 -XX:PerBytecodeRecompilationCutoff=-1"

3.6 业务配置检查

在应用日常的正常运行过程中，维护事务相对简单，在有需要的时候能够查看应用的运行日志，或查看应用的各项监控指标是否存在异常即可

4.1 应用启停

应用日常的维护工作中，经常会需要对应用进行启停重启等操作。

• 单机环境依赖较少，无严格顺序需求。

• 集群环境相关组件较多，为尽量降低应用使用的风险，请尽量按以下顺序进行启停

4.1.1 启动顺序

由于应用的正常运行对组件有依赖，因此需要先启动相关组件，再启动应用。顺序为：

1）负载均衡组件（Nginx）

2）状态服务器组件（Redis）

3）文件服务器组件（FTP）

4）外接数据库组件（Mysql）

5）帆软应用（集群依次启动各节点即可）

各组件和应用可以配置开机自启动，便于在重启服务器后自动启动恢复服务：

• Redis集群开机自启动
  

• Redis单机开机自启动
  

• Nginx 开机自启动脚本
  

• Linux下Tomcat开机自启动

• Windows下Tomcat开机自启动

4.1.2 停止顺序

对于应用的停止顺序没有严格要求，但由于组件的关闭会直接导致应用不可用，因此建议先关闭帆软应用(kill命令避免进程残留)，再关闭各个组件

4.2 日志查看

帆软应用通常涉及以下几类日志：

4.3 监控指标

1）指标说明

日常运行中，运维人员主要需要关注以下各指标是否存在异常：

2）如何通过帆软功能快捷运维

帆软提供内存管理页面，点击「管理系统>智能运维>内存管理」，其中「内存预计」Tab提供相应功能

通过此功能可实现可视化查看帆软应用而非整个服务器的近期「内存曲线」和「CPU曲线」，快速了解帆软应用运行及压力状况。

5.1 异常警告

如需对帆软应用的异常及时感知，需实现对帆软应用各项指标的监控告警，实现的方案有以下几点建议：

1）如使用的是云服务器（如阿里云、华为云等），可使用云服务厂商提供的监控类云服务，对服务器的资源异常进行监控

2）自行开发实现对于帆软应用的监控，如基于promthues组件等

3）针对系统负载过高的场景，帆软提供智能预警功能，检测到负载状态过高时将提醒运维人员。

管理员登录数据决策系统，点击「管理系统>智能运维>内存管理」，其中「内存预警」内可进行智能预警配置。

4）针对系统出现宕机的场景，帆软提供宕机通知功能，检测到系统宕机时将提醒运维人员。

管理员登录数据决策系统，点击「管理系统>智能运维>宕机处理」，其中「宕机处理」内可进行宕机通知配置。

5.2 宕机处理

当应用出现异常时，宕机可能会随之发生，此时为了业务的可用，需要快速恢复应用，同时应尽量保存宕机时刻的日志信息，方便进行宕机原因定位及风险排除，避免再次出现类似异常。对于宕机，应进行以下运维动作：

1）保证系统环境有jdk工具，当应用发生宕机时，及时导出dump文件

1. 进入到对应的jdk的bin目录

2. 以linux+tomcat为例，查看pid的方式为使用ps -ef|grep tomcat管道过滤命令，查看对应的服务器进行pid。

3. 使用命令jmap -dump:format=b,file=文件名 [pid]来生成dump。

2）自行开发对帆软应用是否存活的监控，并在发现其不可用时告知到运维人员，并通过自动化脚本重启应用，或人工进行监控及应用重启

重启或停止应用时需确保完全关闭工程相关进程，详情请参见：关闭或重启FineReport工程

3）在宕机发生后自行通过dump分析宕机原因或联系技术支持协助定位，并尽快排除宕机风险。

4）针对宕机场景，帆软提供应用存活监控功能，管理员登录数据决策系统，点击「管理系统>智能运维>宕机处理」。

通过「宕机处理」可以实现宕机消息通知，宕机日志自动导出，及宕机后自动重启恢复。

5）针对宕机定位，帆软提供宕机自助处理功能，管理员登录数据决策系统，点击「管理系统>智能运维>宕机处理」。

通过「宕机自助向导」可以对大多数的宕机原因给出分析结果并提供改进建议。

6.1 备份还原

帆软系统需要定期进行备份，以确保在用户误操作、版本回退等场景下能够及时恢复，备份及还原方式如下：

1）自行备份：

定期将完整工程拷贝并压缩后，放在磁盘空间充足的目录或其他服务器上，并定期备份工程的外接配置数据库

2）通过帆软功能进行备份还原：

• 帆软平台提供备份还原的功能，支持对「平台配置」、「报表模板」、「BI模板」、「JAR 包」、「插件」进行备份还原。

• 默认备份路径为../backup，备份文件存储在工程的%FR_HOME%/webapps/webroot/backup文件夹下，支持修改为其他备份路径，在「全局设置」中进行配置

• 备份方式分为自动及手动，手动备份即手动创建一份备份，自动备份则按照设置的自动备份「备份频率」、「份数上限」、「备份容量」、「备份失败提醒」进行定期自动备份

• 备份内容如下：

• 选择手动备份／自动备份下备份的文件，点击「还原按钮」，「确认」后即可进行还原，还原后重启服务器即可生效
  

• 不同内容还原生效的方式略有部分，详情如下表所示：

6.2 更新升级

帆软产品会持续不断的迭代更新，可能增加新的功能或针对历史版本存在的问题进行修复，为了能获得更好的功能体验，客户往往也要跟随更新版本，本章仅介绍小版本升级方式，大版本升级请联系帆软技术人员进行协助，具体更新升级方式如下：

1）决策平台管理升级（不适用于BI）：

打开数据决策系统，在「管理系统>智能运维>备份还原>更新升级」点击「立刻更新」按钮，等待更新 JAR，成功后重启 Web 服务器即可。

2）升级前需确保已进行备份操作，保证升级过程或升级后出现异常可以及时恢复可用状态不至于造成损失，备份方法可参考上一节

3）人工更新 JAR 包：用户可以获取 JAR 包后手动替换更新， linux 系统和 windows 系统下操作方式一致。

4）用户可以向帆软技术人员索要升级jar包，获取后，替换服务器工程 %TOMCAT_HOME%/webapps/webroot/WEB-INF/lib下的老jar包，重启服务器即可完成升级。

5）BI更新升级前请先运行升级工具，在决策平台中点击「BI升级」进行检测，按指导处理完成升级风险项后进行人工更新。