Alex Williams for TechCrunch:

Boundary‘s application performance monitoring technology is now integrated into Splunk‘s enterprise platform, providing a window into apps that increasingly are distributed across cloud and on-premise virtualized environments.

At first I thought this means Boundary will use Splunk as the backend for the data. But Boundary is a service so that’s not the case. Plus Splunk can already be used for network management and monitoring.

According to the post, “Splunk real-time alerts are tagged as annotations in Boundary’s time-series graphs. Customers can then correlate alerts against application flow and performance data.” So basically this is monitoring your monitoring system, right?

Original title and link: Boundary for Splunk app for correlating alerts (NoSQL database©myNoSQL)

via: http://techcrunch.com/2013/04/25/new-boundary-app-for-splunk-predicts-root-cause-of-app-brownouts/

Speaking about networks, the company monitoring networks, Boundary, is investigating an issue with their historical data storage solution built on top of Riak:

Kobayashi is the name we’ve bestowed upon a new historical data store for streaming data yet to be integrated into the Boundary stack. Every few seconds, a small chunk of the most recent data for each “stream” is remitted to kobayashi for longer-term storage. There are roughly 15-20 of these streams per customer to cover the necessary dimensionality and aggregation periods required by the Boundary dashboard. Kobayashi runs on 9 nodes paired with a riak cluster running on those same 9 nodes.

These days, everytime I’m seeing an investigative monitoring dashboard, I’m thinking of Brendan Gregg’s great system visualizations.

Original title and link: Kobayashi: Historical Data Store with Riak (NoSQL database©myNoSQL)

via: http://blog.boundary.com/2012/04/19/hungry-kobayashi-pt1/

After posting about the proposal of adding a 128-bit K-Order unique id generator to Redis, I’ve realized I haven’t linked to Boundary’s post about Flake, their decentralized k-ordered unique id generator project:

All that is required to construct such an id is a monotonically increasing clock and a location 3. K-ordering dictates that the most-significant bits of the id be the timestamp. UUID-1 contains this information, but arranges the pieces in such a way that k-ordering is lost. Still other schemes offer k-ordering with either a questionable representation of ‘location’ or one that requires coordination among nodes.

Original title and link: Flake: An Erlang Decentralized, K-Ordered Unique ID Generator by Boundary (NoSQL database©myNoSQL)

via: http://blog.boundary.com/2012/01/12/Flake-A-decentralized-k-ordered-id-generation-service-in-Erlang.html