ExData Logger 是一种高级日志机制，它实现了集中式、 全系统范围的日志 功能。
这意味着，数据连接（数据集消息路由器）中的系统资源--在 AR 和 Linux 中，以及用户程序都可以在多个级别上以不同的冗长输出写入该日志。信息过滤在源头（日志进程）进行，以防止不必要的流量。有关数据连接日志记录器背后功能的更多信息，请参阅开发部分的 [日志记录][dev_logging]。
使用 exOS 中的任何记录仪时，建议始终选择 "默认排序模式"，因为某些记录仪条目可能具有相同的时间戳（即发生在同一时间）。使用 "默认排序模式 "后，这些条目将按照正确的顺序排列。
默认情况下， exostarget的日志级别 配置为 "成功"。这也是推荐的，因为它会显示所有错误和警告，以及系统是否总体上成功完成了配置任务。
日志级别 "成功 "还能显示系统是否从非致命错误中恢复。 同步从属设备不同步！- 重试中"的 警告（如果 时间同步 的精度 设置得过于 "精确" ， 可能会出现这种警告 ）。这个问题可能是间歇性的（由 Linux 系统上突然出现的高负载引起），因此 只有当级别设置为 "成功 "或更高时，日志记录器才会捕捉到 随后的 "Sync Slave Synchronized! "。
下图显示了 在 双方都启动gWaterTank_0 应用程序时数据连接的输出 情况。
将日志记录器级别设置为 "Info"（信息）或 "Debug"（调试），可以从 AR 和 Linux 中的gWaterTank_0 应用程序中获取更多详细资料 。
下图显示了使用记录仪级别 "Info "连接 gWaterTank_0的输出结果 ：
默认情况下，只有来自系统的最重要信息才会输入 ExData 记录器。同步状态就是一个例子。如果需要系统提供更多信息， 可在 外部目标 配置 的高级视图中激活 数据集消息路由器消息 类型（过滤器） 。
这将在当前日志级别上转发所有系统事件。与之前的示例相同， 在 "成功 "级别启用了DMR 消息：
无论是否 启用 DMR 信息，系统内部发生的数据连接错误都会报告 。 不过， 如果发生错误 ， 激活 DMR 消息有时会很有帮助 。这也可以在运行时使用 ExLogConfig 功能块来完成 。
如果在建立连接或运行时发生错误， ExDataConnectionInfo 和 ExDatamodelInfo 将显示这些错误的一般指示。这足以让应用程序意识到 "出了问题"，但并不清楚到底发生了什么。
例如，共享内存配置错误会导致在 AR 和 Linux 之间建立连接时出错。
In the following example, the ExDataConnectionInfo is showing that an error occured on a datamodel in Linux.
这里 会 报告DMR的错误信息 ，检查初始错误（与编译一样）通常可以找到错误的根源--在本例中，共享内存的大小太小。
默认情况下，所有日志条目都会转发到 Linux 中的日志系统，可通过以下命令跟踪日志系统：
sudo journalctl -u exos-data.0.runtime.exos.service --output=cat -f
The ExData Logger is an advanced logging mechanism, which implements a centralized, system-wide logging functionality.
This means, system resources in the Data connection (Dataset Message Router) - in AR and Linux, as well as User programs can write to this log on several levels and with different levels of verbose output. Filtering of messages takes place at the source (the logging process) to prevent unneccesary traffic. For more info regarding the functionality behind the data connection logger, see the [Logging][dev_logging] in the development section.
When using any of the loggers in exOS, it is recommended to always select the "Default Sort Mode", as some of the logger entries can have the same timestamp (i.e. take place at the same time). With the "Default Sort Mode", these entries are placed in the correct order.
By default, the log level in exostarget is configured to "Success". This is also recommended, because it will show all errors and warnings, and if the system in overall was successful with completing the configured tasks.
Logger level "Success" also shows if the system recovered from a non-fatal error. One example of this is the "Sync Slave out of sync! - retry in progress" warning (which might come if the Precision is set too "precise" for the time synchronization). This problem could be intermittent (caused by a sudden high load on the Linux system), and so a following "Sync Slave Synchronized!" is only captured in the logger if the level is set to "Success" or higher.
The following picture shows the output from the data connection, when a gWaterTank_0 application is started up on both sides.
Setting the logger level to "Info" or "Debug" will enable more verbose information from the gWaterTank_0 applications in AR and Linux.
The following picture shows the output of connecting the gWaterTank_0 using logger level "Info":
Data connection system logger (Dataset Message Router)
By default, only the most significant information from the system is entered in the ExData logger. One example is the synchronization state. In case more information is needed from the system, the Dataset Message Router message type (filter) can be activated in the advanced view of the extarget configuration.
This will forward all system events on the current log level. Same example as before, with DMR messages enabled on "Success" Level:
Data connection errors that occur inside the system are always reported, regardless if DMR messages are enabled or not. Many times however, it is helpful to activate DMR messages, should an error occur. This can also be done during runtime using the ExLogConfig function block.
In case errors occur during establishing the connection or during runtime, the ExDataConnectionInfo and ExDatamodelInfo will show general indications for these errors. This is enough for applications to register that "something is wrong", but not exactly what has happened.
For example, a wrongly configured shared memory will produce an error establishing the connection between AR and Linux.
In the following example, the ExDataConnectionInfo is showing that an error occured on a datamodel in Linux.
Here the error messages of the DMR are reported, and checking the initial error (as with compiling) can often lead to the source of the error - in this case, the shared memory size was too small.
By default, all logging entries are also forwarded to the journalling system in Linux, that can be traced via the following command:
sudo journalctl -u exos-data.0.runtime.exos.service --output=cat -f