全流程实操数字档案馆系统登录日志不完整排查修复指南

一、前置准备:明确3类核心前提,避免无效操作

在正式动手前,请先确认以下3项信息,否则可能做无用功:

  • 确认系统架构:是单体应用(单服务器部署)还是分布式应用(微服务/集群),这会直接决定排查的路径
  • 获取完整操作权限:拿到系统管理员账号+系统部署服务器的SSH/远程桌面权限+数据库root/对应读写权限
  • 备份现有文件:远程备份系统配置文件(conf/config/目录下所有内容)、数据库中的登录日志表(一般命名为sys_login_log或类似)、日志存储文件(一般在logs/var/log/下)

二、单体应用场景:从内到外4步排查修复

2.1 第一步:检查系统端日志采集开关配置

这是最常见的原因,大部分系统都有登录日志的级联/独立开关,需打开配置文件验证:

  • 找到配置文件位置
    • Java系统(Spring/SpringBoot为主):application.yml/application.properties(在部署目录根目录或conf/子目录)
    • PHP系统(ThinkPHP/Laravel为主):.env/config/logging.php(部署根目录或config/子目录)
    • .NET系统(ASP.NET Core为主):appsettings.json(部署根目录)
  • 验证并修改配置

    Java SpringBoot 通用配置(可直接复制覆盖对应部分,注意修改级别的值,INFO及以上必须开启):

     SpringBoot日志配置
    logging:
    level:
    root: INFO
    数字档案馆登录模块的包名(可在部署根目录lib/下找核心jar包的manifest或搜索Controller获取)
    com.digitalarchives.controller: DEBUG
    com.digitalarchives.service: DEBUG
    file:
    name: /var/log/digital-archives/sys-login.log  自定义日志存储路径,确保可写
    pattern:
    console: "%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n"
    file: "%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n"
    系统内置登录日志采集开关(通用字段,不同系统可能不同,需搜索log.enable.login类似关键词)
    sys:
    log:
    enable: true
    enable-login: true
    record-fields:  需记录的字段,至少保留用户ID、IP、时间、状态
    - userId
    - username
    - loginIp
    - loginTime
    - loginStatus
    - loginDevice

    ThinkPHP6.0 通用配置(修改config/logging.php):

    全流程实操数字档案馆系统登录日志不完整排查修复指南

     env('log.channel', 'file'),
    'channels' => [
    'file' => [
    'type' => 'File',
    'path' => '',
    'level' => ['info', 'notice', 'warning', 'error'], // 必须包含info
    'file_size' => 20971520,
    'json' => false,
    ],
    // 新增独立登录日志通道(可选但推荐)
    'login' => [
    'type' => 'File',
    'path' => runtime_path() . 'login/',
    'level' => ['info'],
    'file_size' => 20971520,
    'json' => false,
    ],
    ],
    ];
  • 修改后重启系统
    • Java SpringBoot jar包部署:kill -9 $(ps aux | grep digital-archives.jar | grep -v grep | awk '{print $2}') 强制停止旧进程 → nohup java -jar digital-archives.jar > /dev/null 2>&1 & 后台启动新进程
    • PHP系统:重启Nginx/Apache+PHP-FPM(Linux Nginx+PHP-FPM命令:systemctl restart nginx && systemctl restart php-fpm
    • .NET Core系统:重启对应的systemd服务(systemctl restart digital-archives.service)或IIS应用池

2.2 第二步:检查服务器端日志存储权限

系统开关打开但没权限写文件,也会导致日志丢失:

  • Linux系统权限检查修复
    • 找到2.1中配置的日志存储目录,比如/var/log/digital-archives/,执行:ls -ld /var/log/digital-archives/,查看用户组和权限
    • 修改权限为系统运行用户可写:假设系统运行用户是www,用户组是www,执行:chown -R www:www /var/log/digital-archives/ && chmod -R 755 /var/log/digital-archives/
  • Windows系统权限检查修复
    • 右键日志存储文件夹 → 【属性】→ 【安全】
    • 查看系统运行用户(IIS是IIS_IUSRS和AppPool\应用池名;.NET Core服务是服务指定的Local System或自定义用户)是否有“写入”权限,没有则勾选并应用

2.3 第三步:检查数据库端日志表结构/写入权限

大部分数字档案馆系统会将日志同步存入数据库,方便后续查询,需验证:

  • 验证表结构完整性
    • 登录MySQL/PostgreSQL/Oracle数据库,执行通用SQL查看登录日志表结构:DESC sys_login_log;(不同数据库略有不同,SQL Server用EXEC sp_columns sys_login_log;
    • 确认是否有必填字段缺失(比如loginTime没有默认值导致写入失败),若有缺失,执行补全SQL(以MySQL为例):ALTER TABLE sys_login_log MODIFY COLUMN loginTime DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '登录时间';
  • 验证数据库写入权限
    • 用系统配置的数据库账号登录,执行测试插入SQL:INSERT INTO sys_login_log (userId, username, loginIp, loginStatus) VALUES (1, 'admin_test', '192.168.1.1', 1);
    • 如果插入失败,联系数据库管理员给该账号授予INSERT权限(MySQL命令:GRANT INSERT ON digital_archives_db.sys_login_log TO 'archives_user'@'%';

2.4 第四步:检查日志过滤规则(进阶但易漏)

部分高级系统有登录IP白名单/黑名单过滤、测试环境过滤等规则,会导致部分日志不记录:

  • 在数据库配置表(一般为sys_configsetting)中搜索logloginfilter相关关键词
  • 如果有白名单只记录内网IP,而当前测试用的是外网IP,或者黑名单屏蔽了某个IP,可临时修改规则,或者用符合规则的IP测试

三、分布式应用场景:核心补充2步(单体应用场景步骤也要做)

3.1 补充步骤1:检查日志收集组件(ELK/Filebeat/Loki)

分布式系统一般会用ELK(Elasticsearch+Logstash+Kibana)、Loki+Promtail等组件收集日志:

  • Filebeat(最常用的日志收集代理)检查修复
    • 确认Filebeat在所有应用服务器上都已启动:systemctl status filebeat(Linux)或查看Windows服务
    • 查看Filebeat配置文件/etc/filebeat/filebeat.yml(Linux),确认是否正确配置了2.1中指定的登录日志文件路径:
    • filebeat.inputs:
      - type: log
      enabled: true
      paths:
      - /var/log/digital-archives/sys-login.log  必须完全匹配路径
      fields:
      service: digital-archives
      log_type: login
    • 修改配置后重启Filebeat:systemctl restart filebeat

3.2 补充步骤2:检查分布式ID生成/负载均衡配置

微服务场景下,登录服务可能被负载均衡到多台服务器,需确认:

  • 检查每台登录服务的配置是否一致(开关、权限、日志表等)
  • 如果日志中有ID重复或冲突的问题,更新分布式ID生成组件(比如Snowflake算法的workerId配置,确保每台服务器不同)
AI咨询
热线电话

028-85154420

15388110056

全国售前咨询电话

扫码咨询
安答联动微信公众号二维码

微信扫码关注安答联动

申请试用
热线电话
申请试用

安答联动档案管理系统