Can I link Assimilation monitoring to Flapjack?

[Alan Robertson]

Hi,

I'm finally looking at hooking up the Assimilation project [http://assimilationsystems.com] to Flapjack...

Here are the things that seem like they might potentially be problematic in connecting Assimilation to Flapjack...

• The Assimilation system performs minimal communications - if it's been sent once we never send it again - whether a failure or a repair.
• If something changes, we'll let you know.  No news is good news (or bad, depending...)
• If nothing changes, then we have nothing to say (until it changes).  If nothing changes for 8 hours, then we won't send any messages for 8 hours.
• All monitoring is done through discovery - there is no manual configuration.  If people add new things we will start monitoring them.
• We monitor a wide variety of things, ranging from servers to services to non-compliance with best practices, to a new server showing up, or a new service or port showing up - or services we don't know how to monitor...  We can alert on any of those things.  Again - very little (or nothing) is manually configured.
• If a server goes down, we don't explicitly alert on the services on that server going down.
• On the positive side, our alerting APIs all talk JSON :-).

What kinds of problems do you anticipate in connecting to Flapjack?

Do you have any suggestions on how I should connect to it?

   -- Alan Robertson

[Jesse Reynolds]

G'day Alan,

On Thursday, 8 January 2015 12:20:22 UTC+10:30, Alan Robertson wrote:

Hi,

I'm finally looking at hooking up the Assimilation project [http://assimilationsystems.com] to Flapjack...

Excellent!

 

Here are the things that seem like they might potentially be problematic in connecting Assimilation to Flapjack...

• The Assimilation system performs minimal communications - if it's been sent once we never send it again - whether a failure or a repair.

This will cause problems as Flapjack expects a constant heartbeat. However, if you want to rely solely on Assimilation to determinate failure (including thresholding by duration) you could dumb down Flapjack and set 0 as the failure delay on the checks coming from Assimilation. Or, you could use Flapjack's http broker, which will generate the heartbeat for you, until a TTL is reached when it will start sending UNKNOWN as the state of the check. 

 

• If something changes, we'll let you know.  No news is good news (or bad, depending...)
• If nothing changes, then we have nothing to say (until it changes).  If nothing changes for 8 hours, then we won't send any messages for 8 hours.
• All monitoring is done through discovery - there is no manual configuration.  If people add new things we will start monitoring them.

How you then handle clean up in Flapjack will be interesting. Does Assimilation take note of services which it doesn't see as active anymore? Any hooks for then disabling checks in Flapjack?  

• We monitor a wide variety of things, ranging from servers to services to non-compliance with best practices, to a new server showing up, or a new service or port showing up - or services we don't know how to monitor...  We can alert on any of those things.  Again - very little (or nothing) is manually configured.
• If a server goes down, we don't explicitly alert on the services on that server going down.
• On the positive side, our alerting APIs all talk JSON :-).

What kinds of problems do you anticipate in connecting to Flapjack?

Do you have any suggestions on how I should connect to it?

Give it a go :-) 

At the moment you need to connect to Flapjack's Redis and create events as json blobs in the 'events' list in Redis. Or as mentioned above, you could try running up an instance of Flapjack's http broker instead, and connecting to that as the integration point. 

Cheers,

Jesse