search

ruuvi / ruuvi.gateway_esp.c

Ruuvi Gateway ESP32 code
BSD 3-Clause "New" or "Revised" License
24 stars 15 forks source link

report startup and config via syslog - improvement #230

Open DG12 opened 3 years ago

DG12 commented 3 years ago

syslog should be uset to report version, initalization and configuration of both the nRF and esp modules

It is very important, especially during development and initial deployment, for a system to announce its version. This indicates the not only has the process has sucessfully started but also which version has been started.

Syslog is a trival means developed for just this type of information. If the UDP (User Datagram Protocol) is used it is non blocking and (nearly) infalible (from the point of viewn of the initating proess). The syslog server reported to can be a static IP address, a static hostname, retrieved from the DCHP information (currently providing the systems IP address, gateway, DNS serve)r or it can be provided during setup similar to the definiton of the host server for the Ruuvi server(less). It could even be set to a Ruuvi syslog server temporarily during initial deployment and if there were a problem! While LOG message to the USB port are important for initial development, syslog messasages suggested can be very important during deployment to confirm that the expected configuration is actually in use and that basic functionalality is working. For example upstream network is alive and packets are being sent. The syslog messages can be stored at the syslog server and/or forwarded to another system. These message can be important in fault detection and isolation. Even coordinating previous faults with other events. Printers, Routers use this (even my remote swamp and retirement home monitors use it)

This information is already available for LOG and should be sent via syslog as well. Gateway SETTINGS: (details supressed if using=0, minimal length string i.e. few syntactical elements i.e. not JSON) using eth:0; dhcp:1; static ip:NA; netmask:NA; gw:NA; dns1:NA; dns2: NA using mqtt:0; server:NA; port:0; prefix:NA; user: mqtt using http:1; url:https://network.ruuvi.com/record ; user:NA coordinates: ???? company id filter: 1; id: 0x0499 scan coded phy: 0; scan 1mbit/phy: 1; extended payload: 1 channel 37: 1 38: 1 39: 1 My hostname:RuuviGatewayD828

ojousima commented 3 years ago

We're going to implement a system status page anyway, this might be related.

Is there some kind of a standard we could refer to?

DG12 commented 3 years ago

Syslog messages can be freeform and can include, but to necessarily , keyword=value portions. See https://www.rsyslog.com for a large amount of good information if you want but it is not necessary to understand any of that super capable system.

The reason to use syslog is 2 fold: 1 During development and, more importantly, initial customer install, progress and problems, especially intermittent ones, can be reported directly to support staff without customer involvement and even before the customer is aware.

2 After the system is installed a local OR remote monitoring system ( which may already be in place for other devices/systems) can push messages if a problem is detected OR if no status reports are received from the gateway indicating that it is dead.

As I described above this code need not be removed if it is not used.

Both the implementation in the gateway and the basic setup of syslog collector are very simple. I have an old raspberry pi that collects data from several of my remote RuuviTags.

This capability can not be provided with a status page.

ojousima commented 3 years ago

Syslog messages can be freeform and can include, but to necessarily , keyword=value portions. See https://www.rsyslog.com for a large amount of good information if you want but it is not necessary to understand any of that super capable system.

Thank you for the details.

We'll consider it, we already have "gateway first online" and "gateway last seen" fields in database. Having more refined implementation to know e.g. which versions our user base has installed would be useful

ojousima commented 3 years ago

Marking this as a 2.0 feature for now.

ojousima commented 3 years ago

Related, #342

Scrin commented 2 years ago

Having the logs available remotely would be a very great addition. For example especially #449 took a lot of time to figure out why it wasn't working, while if the gateway was sending logs externally I could had simply checked the logs and (hopefully) see an error of some sorts, rather than having to tcpdump on my network to realize the gateway didn't even talk. #452 also took a few moments to figure out in a "black box situation", though in that particular case I don't think there would be any useful logs, other than constant rebooting.