Re: [Nut-upsuser] How to handle flags as status?
On Tue, 29 Dec 2020, Charles Lepple via Nut-upsuser wrote: On Dec 29, 2020, at 9:54 AM, Shakil Shaikh via Nut-upsuser wrote: Are clients therefore supposed to list all possibilities, or split on space to get the flags back? Clients should split on space. I remember we had a better description of this from the protocol perspective, but that description does not seem to be in the current documentation (which has a description aimed at driver developers). I don't know Prometheus, but if you are going to have it talk to upsd directly, then you will need to 1. Maintain in Prometheus the current state of the UPS. 2. Every 5 seconds, read the new status and charge from upsd. 3. Compare the new status with the previous status to detect events. E.g. OL->OB or nil->LB or charge falls below some limit. Based on these events you issue messages, and perhaps call for a system shutdown. Does Prometheus provide scripting support? If Prometheus talks to upsd over some network, then you will need to think about network security. Roger ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] How to handle flags as status?
On Dec 29, 2020, at 9:54 AM, Shakil Shaikh via Nut-upsuser wrote: > > Are clients therefore supposed to list all possibilities, or split on space > to get the flags back? > Clients should split on space. I remember we had a better description of this from the protocol perspective, but that description does not seem to be in the current documentation (which has a description aimed at driver developers). This is the code that builds ups.status for the drivers: https://github.com/networkupstools/nut/blob/v2.7.4/drivers/dstate.c#L850 as suggested in the developer guide: https://networkupstools.org/docs/developer-guide.chunked/ar01s04.html#_manipulating_the_data As Roger indicated, upsmon is the canonical example for parsing ups.status. https://github.com/networkupstools/nut/blob/v2.7.4/clients/upsmon.c#L1474 ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] How to handle flags as status?
Because (in this case at least) monitoring doesn't imply key events occurring. To flesh out the question, the intention here is to send results to something like Prometheus. But if the answer is "do what upsmon does" then that's fair enough too! From: Nut-upsuser on behalf of Roger Price Sent: Tuesday, December 29, 2020 3:45:51 PM To: Shakil Shaikh via Nut-upsuser Subject: Re: [Nut-upsuser] How to handle flags as status? On Tue, 29 Dec 2020, Shakil Shaikh via Nut-upsuser wrote: > I'm looking into the best way to handle the ups status that gets returned by > NUT. I've had a brief look at the source and it appears that this status is > actually a composite of flags, some of which cannot co-exist. > > In particular I have a UPS that returns both OL and OL TRIM, which seem like > reasonable statuses, but encode multiple states. A monitoring client has to > know that OL TRIM implies online. > > I assume that not all combinations of flags exist, but I also understand that > the combinations that do are defined by the drivers. To that end it becomes > difficult to enumerate them. > > Are clients therefore supposed to list all possibilities, or split on space > to get the flags back? > > Thoughts appreciated Why not let a program like upsmon do this for you? Then all you have to do is say in configuration file upsmon.conf what is to be done for the key events. Roger ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
Re: [Nut-upsuser] How to handle flags as status?
On Tue, 29 Dec 2020, Shakil Shaikh via Nut-upsuser wrote: I'm looking into the best way to handle the ups status that gets returned by NUT. I've had a brief look at the source and it appears that this status is actually a composite of flags, some of which cannot co-exist. In particular I have a UPS that returns both OL and OL TRIM, which seem like reasonable statuses, but encode multiple states. A monitoring client has to know that OL TRIM implies online. I assume that not all combinations of flags exist, but I also understand that the combinations that do are defined by the drivers. To that end it becomes difficult to enumerate them. Are clients therefore supposed to list all possibilities, or split on space to get the flags back? Thoughts appreciated Why not let a program like upsmon do this for you? Then all you have to do is say in configuration file upsmon.conf what is to be done for the key events. Roger ___ Nut-upsuser mailing list Nut-upsuser@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
