Skip navigation
All Places > CA Infrastructure Management > Blog > Authors jason_normandin

Last time on Batman  A Quick Recap

 

In my last blog post (First Light: Part 1 - Questions & Answers) I talked about simplicity and our approach to have users "just ask your question". That simplicity is founded in the logical, relational schema within our OData abstraction layer. We expose relationships between objects much as you would in an SQL join on multiple tables. The nice part is that you don't have to worry about the semantics of those "joins" and which key should match on which tables. Kind of like a DB "view" but more flexible. We can add new relationships without DB schema changes and can enable a more flexible layer above a typically ridged core "data structure".

 

Overview of schema and basic architectural principals

 

Our OpenAPI OData implementation is the abstraction layer that provides the link between our in-memory Item Repository (IRep) and our disk-based Vertica Data Repository. The configuration aspects of the question are handled by IRep without the need for Disk I/O while the data fetches are managed through Vertica's "big-data" architecture. The best of both worlds and a great foundation for our scale and performance aspirations.

 

We also simplify the process by providing the relationships available to the user dynamically. As you build out your question we can provide the available logical associations. Basically "what's next". For example, in our CA Performance Manager QueryBuilder once the user defines the endpoint (group, device, etc) the options available to continue to build out the question are presented scoped to the initial endpoint. If the user selects Router, then the logical schema associations to Router (Groups, CPUs, etc.) are exposed in the filter mechanism and those which are not associated (Servers, Monitoring Profiles, etc.) are hidden. By ensuring these logical or relational consistencies in the question we add a nice coat of "easy paint" to the QueryBuilder.

 

Questions turned to Queries

 

"QueryBuilder? What's that?" - Great question! QueryBuilder is basically an easy way to turn your question into a valid OData compliant and functional URL. Though a faceted search approach we enable the user to easily understand how to construct their question within the context of our API schema and OData syntax.

 

Let's take a closer look!

 

There are 3 components to the QueryBuilder:

 

1. Search - Provides a way to ask your question in a way that allows QueryBuilder to translate that question into a valid OData URL. That OData URL can then be leveraged to generate the target results set - aka the answer.

 

QueryBox.png

 

 

 

 

 

 

 

 


 

2. Formatting - Allows the refinement of the output method and format. This includes paging (via a top and offset) to enable larger queries which would result very-large result payloads.

format1.png

format2.png





 


 

format3.png








3. Output - Here's we we provide a sneak-peak at the answer.The output is not necessarily provided as the final format but options exist to export CSV results for quicker, ad-hoc type queries. This is a great way to answer configuration only questions. For more complex answers, the sneak peak provides insights into the data-set returned to help you make sure you asked the "right question" before turning that data into content.

Output.png

 

That "Just Right' fit

 

The key to our approach is to ask the "ask the right question". We want to avoid providing too much information or not enough information.  We enable this through our filtering mechanism. We provide advanced filtering capabilities to both refine the configuration results (the devices, interfaces, groups, etc) as well as the data (bytes > 0). This is where QueryBuilder shines! Advanced filters can be rather difficult and prone to error within OData syntax but a couple of clicks and voila! The correct URL is generated.

 

goldilocks_6779.PNG

 

 

Goldilocks was onto  something with her "just right" commentary!

Real simple example, let's say I want to find all of the Cisco gigabit interfaces that have experience 0 traffic (bits-in/out) at any point within by Boston site. Here's how it looks in the QueryBuilder filter UI's:

filter1.pngfilter2.png

 

And here's what the OData syntax looks like:

 

$filter=(substringof( 'CIsco',device/Description ) eq true and SpeedIn ge 1000000000 ) and ( portmfs/im_BitsIn eq 0 or portmfs/im_BitsOut eq 0 )

 

Not impossible to construct but you can imagine this can get pretty tricky pretty fast!

 

Next time: Let's look at some data and begin to answer some "questions"!


Thanks for your time!

-Jason Normandin

"Hello World"


As some of you might be aware, CA Performance Management is unveiling a new API strategy focused on simplicity and ease of use. In this Blog series I am going to spend some time talking about that strategy, how we are building our API to enable content creation, and how you can take advantage of a multitude of technologies freely available to divine insights into key performance characteristics of your infrastructure.

 

Photons and Network Performance Data

 

But first things first, why is this titled "First Light"? Great question! In astronomical circles "First Light" refers to that moment when a telescope gathers it's initial photons of light to present the viewer with the first astronomical image. This is usually a significant moment in the life of a telescope and I feel a connection to this moment in our forthcoming OpenAPI release. My favorite First Light image is of IC1396 included here for

your enjoyment along with a few other gems.

 

firstlight-07-0711-mdn.jpgfirstlight-vlt.jpgfirstlight-lbt.jpgfirstlight-armagh.jpg

 

With our CAPM OpenAPI users will be able to easily query and export configuration and performance data for external consumption. While many tools allow this in some capacity our approach differs in that we are focusing on empowering our users to create content without requiring deep insights into our data models or database schema. We are abstracting our data models to allow for simple and intuitive queries, or as I like to say Questions.

 

What do I mean by questions?

 

Fundamentally data is collected, analyzed, stored, viewed, reported on, and alarmed on to serve a purpose, to answer a question related to the infrastructure. These questions can be as simple as "What is my throughput for interface x?" or more complex such as "which Gigabit (Gbps) interfaces in my Boston site which are experiencing less than 200 Mbps throughput (max) over the past 7 days?". Today a set of data is presented to the user to allow that question to be answered. In some areas this works well while in others it may be a bit more difficult than it should be. Users often have to run multiple reports, examine multiple dashboard views, perform external analysis in tools such as Excel or perform back of the napkin calculations. We feel this process can be easier, much easier.

 

Our goal is to allow those questions to be asked as easily as possible. We want to provide the answers in a meaningful way that will allow users to explore data sets to discern insights both to answer the specific question being asked but to also understand deeper relationships and patterns that ultimately will allow smarter decisions to be made to optimize infrastructure.

 

It's all about simplicity

 

You might now be thinking "sounds good but how is CAPM OpenAPI able to do this?". The answer is a bit more simple than you might imagine. We are presenting our API and the items defined within a logical schema rather than as a disparate set of query-able items. If you have leveraged APIs in the past I'm sure you are aware of the iterative nature of the request/response process. Basically you cast a wide net and then slowly refine the results set by interrogating each data set returned to build the next query to ask a question which is a bit more focused on the answer. Rinse and repeat ...

 

Personally I think this leaves a heck of a lot to be desired both from a simplicity perspective but also from a scale and performance perspective. Why require the user to run a gauntlet of various parsing and matching algorithms to create a simple, focused data set? Typically the answer is that it's easier to develop the API using this approach. Easier for the API creators but certainly not easier for the most important group of individuals, the consumers of the data. We want to expand the typical user profile beyond the most experienced users to those that simply have an idea on how they would like to examine or visualize a certain data set.

 

Or more plainly, get answers to a question.

 

Stay Tuned ...

 

Next up in the First Light series will be a deeper look into the logical schema and how complex queries can easily be created using natural relationships directly available to the user.

 

Oh, and before I forget, this is all possible with a single OpenAPI "query" or question.

 

Feel free to stop by and say hello if you are attending CA World. I will make myself available for demos and other sneak peeks into our upcoming OpenAPI functionality.

 

Until next time,

Jason