Remote logging can have an impact on your device RAM/Flash resources and security.
syslogd can log over socket (see the -R parameter mentioned on https://busybox.net/BusyBox.html#syslogd):
- but Sierra Wireless Linux is not configuring syslogd this way: see “cat /etc/init.d/syslog” output
- and, as underlined on https://linux.die.net/man/8/syslogd, this could decrease the security level of your devices.
So, here is a proposed alternative:
To avoid transferring too large logs, run such command:
# logread -f | gzip > $TimeStamp.log
To care about the Flash device life expectancy: log to RAM (/tmp/*).
If already few RAM-space left: log to Flash, but have this logging OFF by default (exceptions: if and when power-on or power-off sequences needs inspection).
Whatever Flash or RAM storage, the most recent log should replace the oldest one.
If the mobile data connection cannot be established yet, then keep logs in RAM or Flash. Once logs have been uploaded to any cloud, delete them from the device.
As your logs will be large data, protocols like LWM2M/CoAP/MQTT seem not suitable here. Instead, you should HTTPS-transfer them to any server.
If needed, tune your devices firewall (iptables/ip6tables). curl is probably present inside your embedded Linux image.
For remote logging control, SMS delivery is not 100% reliable. You should use Sierra Wireless cloud platform instead:
Medium-size-and-secured data transfers are supported. You can easily operate on N-devices fleet. You could define 1 own small device data/resource, string-typed, that you will use as a cloud-to-device command, with such possible values: