Event Monitoring

Confluent
PROJECT

Packet Monitoring

Confluent

Visualize the health of billions of messages (data packets) as the flow between endpoints your database.

Confluent Audit tool

OVERVIEW

Confluent is building a real-time stream data management platform on top of Apache Kafka which the Founders invented.  Kafka, and the tools from Confluent that support it, handle over 1.2 trillion messages a day from LinkedIn alone.  More and more companies are adopting this technology and Confluent will soon be releasing, as its first offering, an Audit Application to give its users some much needed visibility into the health of all this data.

PROBLEM

Provide users a way to visualize the "health" of trillions of messages being sent and received between various endpoints

RESPONSIBILITIES

Product Designer
Including: Information Architecture, User Research, Visual Design, Interaction Design, Prototyping

RESULT

NA

STATUS

NA

REQUIREMENTS

PROJECT PROFILE

Confluent Audit tool

LANDING PAGE

Confluent Audit tool

LANDING PAGE

The main UI zones of the mockup are:

  1. The 4 "pulse" metrics at the top the explicitly communicate "completeness" (duplicates, losses, latency, and overall) of the messages that are flowing through a Kafka cluster.
  2. The heat map at the bottom which attenuates a color (in this case orange/red) to visually communicate when any of the above metrics exceeds a threshold set by the user (ie  red=bad).  The User is able to see all the Kafka cluster's consumer groups, related topics, possibly brokers, and producers in this area which could be on the order of thousands of entries.
  3. Control panel drawer on the right (slides in/out per user control) which allows the User to cull the results of the heat map down to a targeted query.

10 FT UI

10FT UI

Some of our users, like Executives or Network Operations Center Engineers need a high level view of their clusters or system.  Some of their display contexts are tv monitors with no way to manage what they see easily ore frequently - a passive "stock-ticker" type of experience.  This is an early idea of how to reduce the information to it's bare minimum to be understood at-a-glance or at distance (20 feet or so).

I've taken the metric text information from the full UI and isolated it in the center of the screen.  The thought here was that A) it looks simple.  There's not much going on so what was once maybe a intimidating or confusing experience to visually weed through all the noise is greatly simplified and maybe even peaceful experience.  B) By directly leveraging existing UI,  I am making the transition between this dashboard and the full app a bit more forgiving and coherent.  The alternative is to create unique elements here and then a potentially complex (morphing) or jarring (tabs) transition which I believe negatively effects the experience.

PREFERENCES PAGE

PREFERENCES PAGE

Part of the User experience that will need some definition is how they configure the application for permissions, user information, customized alerts, and data "completeness."  These are some simple mockups for how the User Preferences might look.

SEVERITY
The main purpose of the Audit Application is to show the "health" of the data that moves through a Kafka cluster.  For this product, health is seen as "Completeness" which is a combination of the individual metrics, data loss, data duplication, and latency.  The rate at which the data is not complete we cast to "Severity."  The more severe the deviation from Complete data, the more Severe the data is displayed in the UI.  This dialog allows the User to adjust each of the 3 metrics so that they can calibrate their UI and the desired target health of their data.