This is basically a re-invented syslog(3), with a builtin, (supposedly) ephemeral log aggregation service thrown in. It makes some sense for an embedded device, but depending on how restricted your environment is, sending out a UDP packet might be an order of magnitude easier than completing an HTTP transaction. Otherwise, your operating system already has you covered.
I think the use case is ad-hoc, as described on the page. I think the author may know about syslog, but this ad-hoc approach is useful when something such as syslog is not set up correctly and you can't fix it right there and then. This allows you to investigate and fix some bug over the weekend without having to involve others or other bureaucratic domains.
Yes - basically I encountered all of the example situations on the page and knocked up the initial version in a day or so (originally for the "PHP API" scenario specifically). I did add some extra features like setting your own namespace/logging key and controlling visibility, but in the end they didn't really match the use case - "one person doing ad hoc debugging in an unfamiliar environment" - so I stripped them out.
... for every environment that has a network connection ;-)
Does anybody know a more universal solution where you can have custom transports and that can actually run on any environment? (I'd be targeting an 8-bit microcontroller like a PIC18F25K80, for example, on a CAN bus... and somewhere on the CAN bus there's a custom radio link)
5 comments
[ 8.5 ms ] story [ 122 ms ] threadhttps://man7.org/linux/man-pages/man3/syslog.3.html https://man.openbsd.org/syslog.3 https://learn.microsoft.com/en-us/powershell/module/microsof... and so on.
Does anybody know a more universal solution where you can have custom transports and that can actually run on any environment? (I'd be targeting an 8-bit microcontroller like a PIC18F25K80, for example, on a CAN bus... and somewhere on the CAN bus there's a custom radio link)
I might test it for some personal projects.