Jeremy

This is awesome. This is likely to be an interim plan for me while I write something more custom tailored for me. I would suggest you return a unique value for maintenance mode, rather than the same as a failure to run. The reason for this is many people will need to error on a failed polling the same as if the script returned bad stuff, but we would not want to do the same if its in maintenance mode. Looking at the code it doesn't look to hard to change since you already checking separately, but if i'm understanding the code correctly you would only need to return something other than false, and then change your if/else logic and maybe internal documentation. (And then we could use pulseway alerting for say a scheduled task more easily to alert on a poll failure) One question, is there a way (this could be more pulseway app 101) to make it so that if we failed to receive data within a period of time, that an alert will be sent? (say the machine is removed from the network and the pulseway client is not operable) Another question, when sent alerts this way, what do we really have for historical record keeping?

Understood. I'm looking deeper into the links provided. Those didn't seem ideal, as the client seems tied to a single host and I wanted to instead monitor the environment with redundancy. It seems pulseway lacks any good way to do many-to-one relationships, such as what you might see with clustering or VIPs. Out of curiosity, where does a developer go to learn how to then use this system publish? (Does the regular client not publish on its own? aka this is for essentially custom) Let me give you an idea of what i'm looking for system1: service1, service2 system2: service3, service4 For example. And my RPC will connect to an RPC service on either system1 or system2, and return status for all 4 services. If I report per-system, i'll need to parse the output down to only the services installed on that system, and it will require me to have the RPC component installed on all systems which have application services. This means if the local RPC fails, status for components locally cannot be polled (and thus fail) and if I want to status the environment I have to group systems within pulseway. Alternatively I could forgot monitoring redundancy and just pick one system to monitor the entire environment, but this is inferior to the custom monitoring and alerting I already do which I was trying to get Pulseway to replace. I was thinking the Rest API would be the way, but the documentation doesn't seem to indicate how to publish monitoring data. In what case would it be useful to "Publish a system" without ever publishing monitoring data? (again, I believe the client will automatically publish it-self if configured correctly)

This may not be an Rest API thing, but in reading the documentation, it sounds like it MAY be. I have a distributed, multi-system, multi-service application, of which I want to monitor the status via running an RPC status binary I have which outputs XML containing a system, service, and status. Some assumptions I'd like confirmed System Publish can be used to publish custom status More than one system could publish into the same instance (assuming they don't run at the same time) Rest API is a good way to do this (there isn't a better way) If this is a bad choice or the wrong place to ask, please point me in the correct direction. At this point I can be language agnostic. My preferred language would be powershell, but I can run any of the languages supplied as examples for the API documentation.