It appears that a whole protocol description exists for syslog messages and the implementation of syslog "originators", "relays" and "collectors". It's RFC <https://www.rfc-editor.org/rfc/rfc5424#section-6>5424 <https://www.rfc-editor.org/rfc/rfc5424#section-6>. I read through it today to see how involved it would be to set up.
It appears that most of the information the RFC asks to be included are things that NuttX already includes in its syslog messages (i.e. we have all the LOG levels (debug, info, emerg, etc) and all the facilities (auth, kernel, etc. left blank as 0), there is timestamping, PID inclusion, etc.). The RFC also includes a structured data section so for NuttX devices that have a system clock that is not synchronized, you can indicate that. The RFC also allows many of these fields to be marked NIL, which works well with NuttX's very configurable syslog options (so users can exclude PID for instance, and the field can be marked NIL). What I'm now struggling with is setting up these structured messages with the way syslog is implemented. Right now I am able to read the RAMLOG output from the syslog character device just fine, and send the text as UDP packets (very simply). I want to get at the information included in the syslog calls to construct one of these messages from the RFC, but the only way I can think to do that would be to actually parse the text in the syslog output to re-extract the information (i.e. if the message says [INFO], it is of severity LOG_INFO, etc.). There are two problems with this approach: 1) Slow and tedious, especially on embedded systems with already limited resources if they are generating many logs 2) Some information is excluded from the log text. Ex: the user can choose to hide the severity. The `syslog` call may be aware it was called with LOG_INFO, but the generated text gives no indication what the severity was, so it cannot be parsed and included in the syslog packet Any ideas on what might be the best way to go about implementing this RFC? I was thinking there could also be another syslog sink which logs some kind of structured binary data including the severity, timestamp, message, etc. but not sure that would work overly well since the lower-half syslog drivers aren't given anything besides characters <https://nuttx.apache.org/docs/latest/components/drivers/special/syslog.html#syslog-channels> (from what I can tell anyways). Best, Matteo On Wed, Jun 4, 2025 at 9:58 PM Gregory Nutt <spudan...@gmail.com> wrote: > > > Get BlueMail for Android > > On Jun 4, 2025, 12:29 PM, at 12:29 PM, Matteo Golin < > matteo.go...@gmail.com> wrote: > >I like the idea of doing a syslogd implementation, since I agree that > >it > >would probably be simpler to implement in userspace. Looking even at > >the > >ramlog implementation, I'm not sure how using networking operations for > >something like a low-level `putc` would be achieved easily. I might > >read > >into netconsole a bit further just to get an idea though. > > > >Thank you for the pointers everyone! > >Matteo > > > >On Tue, Jun 3, 2025 at 9:46 PM Xiang Xiao <xiaoxiang781...@gmail.com> > >wrote: > > > >> Two approach could achieve the goal: > >> > >> 1. Utilize ramlog and implement all network stuff in userspace, > >like > >> syslogd(https://linux.die.net/man/8/syslogd). You can even > >implement > >> the > >> same protocol as syslogd, so PC tools can be reused directly. > >> 2. Do all network stuff inside the kernel directly like Linux > >> netconsole( > >> https://docs.kernel.org/networking/netconsole.html) > >> > >> The first approach is simple, but consumes more memory and can't send > >out > >> the final panic log. On the other hand, the second needs to improve > >the > >> netdev driver model and NIC driver adaptation, but fix all > >shortcomings in > >> the first one. > >> > >> On Wed, Jun 4, 2025 at 5:01 AM Matteo Golin <matteo.go...@gmail.com> > >> wrote: > >> > >> > Hello everyone, > >> > > >> > I was taking a look at the different syslog output options, and I > >noticed > >> > that there are a variety of different sinks > >> > (character devices, CDCACM, RAM, etc). However, I was thinking that > >it > >> > would be useful to have a network sink for > >> > syslog, so that logs could be sent over a network interface and > >collected > >> > elsewhere. This might be useful for systems > >> > that have small amounts of physical storage but are network > >connected, or > >> > have a very long up-time. > >> > > >> > What do you think about an implementation of syslog for network > >capable > >> > devices that achieves this? Are there any big > >> > hurdles I might not be considering (like setting up a connection, > >using > >> > UDP/TCP, etc)? There would probably have to be a > >> > decently large buffer to avoid slowing down code with blocking send > >> calls. > >> > > >> > What do you think? > >> > > >> > -- > >> > Matteo Golin > >> > > >> >
