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

1. System Publish can be used to publish custom status
2. More than one system could publish into the same instance (assuming they don't run at the same time)
3. 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. 

 

Hi @Jeremy,

The System Publish is used to register the instance with your Pulseway account.

In your case I believe that this is more like a single system with multiple services. And I think that it is better to use the client API to send these events to the Pulseway under one system.

.Net version

Java version 

Please let us know if you have any further questions regarding this.

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)

 

 

Hey Jeremy,

I'd recommend that you build another service that does the monitoring bits, I'll refer to that system as "Heartbeat" in the rest of the post. The Heartbeat service will be configured to make the RPC calls to the services in it's configuration and will register as a dedicated Pulseway monitored system using the Cloud API. This allows you to send real-time information about your services to the mobile apps and webapp whenever you are looking at that system, send commands from those clients back to the Heartbeat service and have the possibility of sending notifications through the Pulseway ecosystem.

Keep in mind that while the Heartbeat service will become a single point of failure unless you build a master-slave system which identifies which instance is currently master using a witness. If you don't really care about it being a single point of failure you can still know when something is not working as expected by informing the Pulseway server that you want to be informed when the Heartbeat instance is offline, similarly how you receive offline notifications for the rest of your monitored systems. You do so when you call the Configure method (last bool parameter).

-Paul