对于更难发现的问题，rsyslog具有集成的调试支持。通常，这不是发现配置问题所必需的，而是用来寻找程序或插件错误的。但是，在许多情况下，事实证明调试日志对于发现配置问题很有帮助。
一个快速指南可以在这里找到。
支持的信号
SIGUSR1-打开和关闭调试消息。请注意，要使此信号起作用，rsyslogd必须通过-d命令行开关或以下指定的环境选项在启用调试的情况下运行。它不要求rsyslog现在带调试启用（但根据设定的不同，这可能导致更好的调试信息）。
注意：此信号在以后的发行版中可能会消失，并可能被其他内容代替。
环境变量
有两个环境变量可设置多个调试设置：
-
除了标准输出外，“ RSYSLOG_DEBUGLOG”（示例：RSYSLOG_DEBUGLOG =“ / path / to / debuglog / debug.log”）会将（几乎）所有调试消息写入（指定）日志文件。某些系统消息（例如segfault或中止消息）未写入文件，因为我们无法捕获它们。
-
运行时调试支持由“ RSYSLOG_DEBUG”控制。
“ RSYSLOG_DEBUG”环境变量包含一个选项字符串，其中可能包含以下选项（均不区分大小写）：
- LogFuncFlow-打印出功能的逻辑流程（输入和退出它们）
- FileTrace-指定要跟踪LogFuncFlow的文件。如果未设置（默认设置），则为所有文件提供LogFuncFlow跟踪。设置为将其限制为指定的文件。可以多次指定FileTrace，每个文件指定一个（例如，导出RSYSLOG_DEBUG =“ LogFuncFlow FileTrace = vm.c FileTrace = expr.c”
- PrintFuncDB-打印调试信息时（例如中止情况），打印调试功能数据库的内容！
- PrintAllDebugInfoOnExit-在rsyslogd退出之前立即打印所有调试信息（当前未实现！）
- PrintMutexAction-在发生互斥操作时将其打印出来。查找僵局等有用。
- NoLogTimeStamp-不为日志行添加时间戳（默认是这样做的）。
- NoStdOut-不向标准输出发出调试消息。如果未设置RSYSLOG_DEBUGLOG，则意味着将完全不显示任何消息。
- 调试 -如果存在，则打开调试系统并启用调试输出
- DebugOnDemand-如果存在，则打开调试系统，但本身不会启用调试输出。您需要发送SIGUSR1以在需要时将其打开。
- OutputTidToStderr-如果存在，则使rsyslog将有关新创建进程的线程ID（tid）的信息输出到stderr。注意不一定报告所有新线程（取决于代码，例如插件的代码）。仅在Linux下可用。当特权被丢弃时，这通常不起作用（这不是错误，而是错误的方式）。
- 帮助 -显示非常简短的命令列表-如果您无法访问文档，希望可以节省生命…
各个选项之间用空格隔开。
其中DebugOnDemand比较适用于在线调试.
为什么要使用环境变量？
您可能会问为什么我们将环境变量用于调试系统参数，而不是通常的rsyslog.conf配置命令。毕竟，环境变量迫使人们更改发行版特定的配置文件，而常规配置指令恰好适合一个中央rsyslog.conf。
历史上，环境变量对于初始化所谓的“ rtinst”模式是必需的。随着OS工具的改进，此模式不再存在。使用环境变量仍然具有rsyslogd初始化就可以正常工作的好处。最重要的是，这是在读取rsyslog.conf之前。
如果没问题，则可以使用rsyslog.conf全局语句来启用调试模式并提供一些设置。
但是，如果您很难使用环境变量来设置调试指令，则可以使用一种解决方法，将在下一段中进行介绍。
通过rsyslog.conf启用调试
如前一段所述，通过rsyslog.conf启用调试可能无法满足某些调试需求，但是基本的调试输出将起作用-这是最常需要的。可用的选项有限，但是这些选项涵盖了最重要的用例。
调试处理是通过旧版配置语句完成的。当前尚无计划将其移至v6 +配置系统。可用的设置是
- $DebugFile <文件名>-设置调试文件名
- $DebugLevel <0 | 1 | 2>-设置各自的调试级别，其中0表示调试关闭，1是按需激活的调试（但调试模式已关闭），2是完全调试模式。
请注意，从理论上讲，禁止多次指定这些参数。但是，我们不强制执行此操作，如果发生这种情况，则结果不确定。
从正在运行的实例获取调试信息
可以从正在运行的实例中获取调试信息，但这需要进行一些设置。我们假定实例在后台运行，因此不希望将调试输出输出到stdout。这样，所有调试信息都需要放入日志文件中。
要创建此设置，您需要
- 将RSYSLOG_DEBUGLOG环境变量指向在while运行时可以访问的文件（强烈建议在本地文件系统中使用该文件！）
- 将RSYSLOG_DEBUG至少设置为“ DebugOnDeman NoStdOut”
- 如果不以交互方式运行rsyslogd，请确保在正确的（特定于发行版的）启动脚本中设置了这些环境变量
这些设置使您能够对SIGUSR1做出反应。收到后，该信号将切换调试状态。因此，发送一次以打开调试日志记录，然后再次发送以再次关闭调试日志记录。第三次，它将再次打开……等等。
在典型的系统上，可以向rsyslogd发送以下信号：
kill -USR1 $（cat /var/run/rsyslogd.pid）
调试日志将显示调试日志记录是打开还是关闭。没有其他状态指示。
注意：实际上，使用DebugOnDemand本身运行不会带来任何性能损失。但是，打开调试日志记录会严重影响性能。此外，调试日志记录将同步许多代码，从而消除了很多并发性，从而消除了潜在的竞争条件。因此，打开和关闭调试日志记录时，同一运行实例的行为可能会大不相同。按需调试日志功能被认为对分析仅在长时间运行后才发现的难以发现的错误非常有价值。在失败的实例上打开调试日志记录可能会揭示失败的原因。但是，取决于失败，调试日志记录甚至可能无法成功打开。另请注意，使用此rsyslog版本，我们无法获取有关之前发生的事件的任何调试信息。 调试日志记录已打开。
分析日志
调试日志主要用于rsyslog开发人员。但是它们仍然可以为用户提供有价值的信息。请注意，日志有时包含看起来像错误的信息，但实际上没有。我们在日志中添加了很多额外的信息，并且在某些情况下发生错误是可以的，我们只是想将其记录在日志中。该代码自动处理许多情况。因此，简而言之，该日志对您可能没有意义，但（希望）对开发人员来说有意义。请注意，我们的开发人员经常需要日志文件的许多行，仅通过查看几个（一百个）日志记录就可以诊断出问题，这一点相对很少见。
安全风险
调试日志将向任何能够读取日志文件的人透露潜在的明智信息，包括用户帐户和密码。因此，建议适当保护对日志文件的访问。而且，启用了调试日志的实例的运行速度比没有实例运行的实例要慢得多。攻击者可能使用此工具进行拒绝服务攻击或尝试从日志文件中隐藏某些信息。因此，建议仅出于某种原因启用DebugOnDemand模式。请注意，当未启用任何调试模式时，SIGUSR1将被完全忽略。
当以任何调试模式（包括按需模式）运行时，可以通过按ctl-c中止rsyslogd的交互式实例。
持续调试输出
在rsyslog.conf文件的开头添加以下权限。这将确保在启动rsyslog服务时首先启用调试支持：
$DebugFile /var/log/rsyslog.debug
$DebugLevel 2
如果需要，可以更改实际的文件路径和名称。
完成上述设置后，重新启动rsyslog时，它将产生一个连续的调试文件。
按需调试
为了使rsyslog准备创建调试日志（又名Debug on Demand），设置有所不同。
$DebugFile /var/log/rsyslog.debug
$DebugLevel 1
现在，rsyslog不会在重新启动时创建调试日志，而是等待对pid的USR信号。发送后，将触发调试输出。再次发送时，调试输出将停止。
kill -USR1`cat / var / run / rsyslogd.pid`
注意事项
- 启用调试输出后，调试文件将快速增长。确保没有永久启用它。该文件最终将填满磁盘。
- 调试模式不应在生产环境中用作永久设置。它将影响处理和性能。
参考:
https://www.rsyslog.com/doc/v8-stable/troubleshooting/debug.html#signals-supported