一、基础配置排查 #

• 确认数据库请求日志功能是否启用：
  不同数据库的日志开关配置位置不同，举例：
  • MySQL：检查my.cnf/my.ini中的general_log（全量请求日志）或slow_query_log（慢查询日志）参数，确保值为ON；
  • PostgreSQL：查看postgresql.conf里的log_statement参数，若设置为none则不会生成请求日志，需改为all或指定语句类型（如mod记录修改类语句）；
  • MongoDB：检查mongod.conf中的systemLog.destination和systemLog.logAppend，同时确保operationProfiling.mode开启对应日志级别。
• 核对日志文件路径：确认配置中指定的日志路径与你查找的区域一致，比如MySQL的general_log_file、PostgreSQL的log_directory参数，避免因路径配置错误找错位置。

二、文件系统权限检查 #

• 验证数据库进程的读写权限：
  1. 用ps aux | grep <数据库进程名>（如ps aux | grep mysql）确认数据库运行用户；
  2. 用ls -ld <日志目录路径>查看目录权限，确保运行用户拥有该目录的读写权限；
  3. 可手动切换到数据库运行用户，尝试在日志目录创建测试文件，验证权限是否正常。
• 排查日志轮转影响：若服务器启用了logrotate等日志轮转工具，旧日志可能被压缩或移动到子目录，检查日志路径下的.gz压缩文件，或查看/etc/logrotate.d下对应数据库的轮转配置。

三、数据库高级过滤规则检查 #

• 日志存储方式配置：部分数据库支持将日志写入数据表而非文件，比如MySQL的log_tables参数若为ON，请求日志会存入mysql.general_log表，而非指定的日志文件；
• 语句过滤规则：检查是否配置了日志过滤参数，比如MySQL的log_slow_filter、PostgreSQL的log_min_duration_statement，若设置了严格的过滤条件（如只记录超过10秒的查询），普通请求不会生成日志。

四、应用层配置排查 #

• 检查应用数据库连接配置：部分应用框架或驱动自带日志控制选项，比如JDBC驱动的logLevel参数若设置为OFF，会禁用请求日志；连接池工具（如Druid）也可能有日志屏蔽配置，需确认应用未禁用数据库请求日志。

五、配置生效验证 #

• 重启数据库服务：多数数据库修改日志配置后需要重启才能生效，执行对应重启命令（如systemctl restart mysql、pg_ctl restart -D <数据目录>）；
• 触发测试请求：执行一条简单的数据库查询（如SELECT 1;），然后查看指定日志路径是否生成新条目，验证配置是否正常工作。

内容的提问来源于stack exchange，提问作者marklogic_coder