Definition
Log Collection refers to the platform remotely pulling device operation logs (system logs, application logs, debug logs, etc.) for Remote Diagnosis, Fault Diagnosis, and auditing. It supports on-demand triggering or scheduled reporting and is a fundamental capability of Remote Maintenance.
Collection Methods and Protocols
Log collection supports active pull by the platform (triggered through Downstream Command) or proactive reporting by the device. Transmission can be over MQTT, HTTP, CoAP, etc.; it supports filtering by log level, time range, and module. The device side needs to implement log buffering, compression, and segmentation to avoid excessively large single transfers; resource-constrained devices may collect only critical logs or snapshot logs at abnormal times. Collected logs must be transmitted and stored securely, and sensitive information should be desensitized to meet Audit Log auditing and compliance requirements.
Integration with DMP
The Device Management Platform embeds log collection capabilities in Remote Diagnosis and Work Order processing workflows. Operation personnel can initiate collection tasks for a single device or a batch of devices, specifying log types and time ranges; collection results can be associated with work orders and pushed to the Fault Knowledge Base for pattern matching. The platform should provide log storage, retrieval, and export functions and support collaboration with RCA root cause analysis tools.
Use Cases
Suitable for fault localization after device anomalies, remote troubleshooting of software defects, security incident auditing, etc. Log collection is a key capability of Remote Maintenance and can significantly shorten MTTR (Mean Time to Repair).
A remote pull versus a serial print on site
Log collection means taking runtime records the device has already produced and bringing an agreed range back to the platform for later search. It is not a person watching a serial console on site the whole time. The records may come from the system, an application, or debug output of a module, but what enters the platform should be one bounded task: which device, which time window, which level, and whether a crash dump is included. Transfer has to be able to split and resume, because a field link often drops before the transfer finishes. The device needs a ring buffer that holds the important lines until they are pulled. After new logs overwrite that buffer, the platform cannot bring the scene back. The result is evidence. It should be tied to the alarm or the work order that triggered it, not left as a file that cannot be searched. The event stream says what happened. The log says which step the program was on. The two times have to line up. Telemetry is still a structured measurement. Do not split measurements into text lines and call that log collection.
When a pull is worth starting
A pull is worth starting when the device can still answer the management channel and the local buffer still holds the content from around the fault. It is most useful just after the anomaly, before a reboot overwrites the buffer. A device that has already rebooted, and did not persist the log, will only return the new lines from after startup. The range should stay near the moment of the fault and the modules involved. Moving several days of debug log in one go uses the bandwidth and carries sensitive information off the device. A scheduled collection fits a few diagnostic devices, or a stated audit item. It does not fit leaving the highest level on for every device all the time. A very small endpoint can write one summary line on the error branch, rather than leaving detailed logging on continuously. For safety, the transfer should use a channel that is already authenticated, and storage should have a retention limit. Passwords, keys, location, and user identifiers have to be redacted before they leave the device. What an audit needs is who pulled which stretch from which device, and when. It is not the log body kept with no end date.
Buffers overwritten, and sensitive fields leaving the device
The most common miss is waiting until a person notices the fault, logs in, and then sends the pull. By then the ring buffer has already been filled with heartbeat lines, and the real error line is gone. The most detailed level, with no capacity cap, lets normal running push the error lines out. A time window taken from the platform clock, while the device clock is off by hours, brings back a different and irrelevant stretch. Chunk numbers that start over on retry make the platform assemble interleaved text, and a reader judges from that. Sharing the full log as a public download link spreads device keys or internal addresses that were inside it. A collection that only captures the word "error," with no module and no context, cannot be matched to a knowledge-base entry. A bulk pull sent to offline devices with no expiry runs, days later, when they come online. That wastes battery and fetches a window that no longer means anything. If success is only "the task ended," and not "non-empty content whose time matches was actually retrieved," an empty file is recorded as diagnosis already finished.