Looks like having a central point to gather the information and construct them according to RFC then passing these to "sinks" that does the further processing i.e. output to text stream and/or output to network? You could then just enable/disable or add more sinks when necessary?
Tomek On Sat, Jun 7, 2025 at 10:51 PM Matteo Golin <matteo.go...@gmail.com> wrote: > > 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 > > >> > > > >> > > -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
