*Formerly vRealize Operations
This post was authored by Tim George
The wait for the new Management Pack Builder is over! Management Pack Builder has gone live so now you can create your very own management packs for VMware Aria Operations (formerly vRealize Operations) MP Builder: Build your integration into VMware Aria Operations with ZERO code using no code. The team that has been building management packs for the last 12 years or so has condensed their expertise to make building management packs simple and quick. In this post, we will walk through the necessary steps to get up and running in no time.
The biggest use case for the Management Pack Builder would be creating a management pack for a technology that doesn’t already have one. This could be technologies with a REST API like Cisco ACI, Brocade, Veeam, or Rubrik. With only a little bit of API knowledge and a bit of knowledge around the specific target API, a management pack can be built in less than an hour (this process used to take a team of trained developers up to six weeks so it’s really quite a feat)!
Let’s walk through an example to see how the product works and get a feel for some of the features that have been implemented.
From our home screen, we can see we have several tabs for Designs, Management Packs, and VMware Aria Operations Connections (formerly vRealize Operations). Under Designs is where we can find all of the management packs we are currently working on. The Management Packs tab contains all the finished products along with their corresponding version numbers. The VMware Aria Operations Connections tab contains all of the connections we have made to our external VMware Aria Operations instances (This will come into play when we start talking about sample collection and building relationships to our created objects). We can then create new management packs, export or import existing designs to share with other users, or delete designs we no longer have a use for.
To begin, we are going to create a new design and use Rubrik as our example endpoint. Once we have clicked on “Create New” we can start to look at our navigation pane on the left.
These are the steps we need to take in order to create our management pack. The first three: Source, Requests, and Objects are required with Relationships and Events being optional. Let’s talk about the Source first.
Source
This is the point we can create a test connection to make sure our source is reachable and that we are using the correct credentials for future requests. We need to enter a hostname, port and SSL information, and an optional base API path that all requests will follow.[MA2] It’s worth pointing out that the “hostname” field in the actual created management pack will be configurable with any system that has the same endpoints; this is merely for testing in Management Pack Builder.
The next step is authentication. We can use basic auth, session auth, or our own custom authentication. Basic authentication creates a base64 encoded token from the provided username and password and sets the basic authorization header. Custom authentication lets you use your own credentials to use in the request. If your API requires you to specify a username and password in the body of the authentication request, you will need to use custom authentication. Another scenario for custom authentication is when an API expects an API token to be included in a header.
If you have any global request setting that need to be set, such as headers or additional query parameters, these can be set in the optional Step 3.
The last step in connecting our Source is to define our request. We need to determine the HTTP method and add the path to our test call. I have put in the information for our sample Rubrik host, the credentials, port information, and a base API path. The test request path can be any endpoint for the API. After this information is input, we can see a preview of the URL that we are about to test.
Clicking “TEST” will bring up a bar at the top of the screen that lets us know the request is in progress or has completed.
I can also click “check response” to find the outcome of the request. From here we can check our response to see the status code, the body of the response, the headers we used, or look at the logs of the request.
Requests
Once our Source has been set, the next major step is to make our actual requests that will eventually create the objects we want to be added to our management pack and ultimately VMware Aria Operations. We can make as many requests as we need in order to get the objects and metrics that we are going to want to add into our pack. Although we are actually creating the objects in the next step, I usually recommend thinking about what sort of objects we want to be created as that would help determine the requests that are going to need to be made.
After we click to add a new request, we can see the steps we need to make, both required and optional, in order to start bringing in the objects we require. The first part is to optionally chain together requests if we need pieces from another request in the current request. We will skip this for now and come back to it once we have further understanding of how these requests work.
The next step is to input a resource path. We can use any endpoint here, but since we want to collect information around the Rubrik Cluster, we can use the “cluster/me” path.
Step 3 is where we can also add additional setting for the request including a body, setting additional parameters, and paging, if required.
Under step 4, we can, again, see the HTTP method and the preview of the request we are about to make. Once we click “Request”, MP builder will make the call and get back any resources that are available at the endpoint we specified. Just like before, we will see the status and can check the response for codes, headers, logs, etc…
We can repeat this process for as many requests as we would like and bring back all the resources we would like, but what happens when I need a resource from a previous request in the current request I am trying to build? A great example would be if I want to request snapshot information. I need to have VM IDs in each request for snapshots that I make. In this case, once I have grabbed the resources for VM’s, I can then use that in subsequent requests. I can open up step 1 here and tell MP Builder that I need to chain together requests and use a variable in place of the VM ID from the VM request. The management pack will then go through each VM ID it receives and gather the snapshot information about each one.
Once we have specified the resource we need to chain, we can use it in our resource path. In order to collect snapshot information about each VM, we can add the ${param} variable to the path. Looking at the full URL preview, we see that the variable has now been added and we can complete our request.
Objects
Once we have made all the requests we want to make, we can start creating the actual objects and pulling in the properties or metrics we want to have in the final management pack. We have two options for this section. We can either create new objects that we can relate to our vCenter objects[MA3] [MA4] , leave them as unrelated objects, or we can extend the vCenter objects that are already being sent to VMware Aria Operations.
To Create New Objects:
There are two steps here to complete the Objects section. We first need to decide what metrics and/or properties we want the management pack to collect once we have it installed in VMware Aria Operations. We can look through each of our requests and choose the relevant pieces we want to incorporate. We can select all, some, or none of the resources listed. If we only want to be able to relate an object to another, we could not select any of the resources and still create the object.
As we select our resources from the list for each object, they will appear in a list below the chart. Here we can choose what we want the label to be in VMware Aria Operations, the unit type, the data type (string or decimal), and whether this will be a property or metric. We also see the origin of the resource as well as an example of what each will look like. It is worth mentioning here that collecting string metrics could have an impact on performance in VMware Aria Operations, so it is important whether we choose “string” or “decimal” to represent our resources. In addition, it should be noted that there are differences between metrics and properties that should be taken into consideration. VMware Aria Operations expects metrics to represent data that changes over time whereas properties represent attributes that the describe the monitored resource and remain relatively static. Some examples of string metrics that could be collected are “state” which returns up, down, in error, etc…. Examples of string properties could be “model”, which returns a model supplied by the vendor, or “software version”, which would return a string of the software being run. If an attribute changes frequently and does not have a limited number of options, it’s recommended to not be collected.
The second step in this section would be where we would set the name of the object instance, the object identifiers in VMware Aria Operations, and the object icon. There are many stock options we can choose from when selecting an icon for an object, with more to be added in future releases.
To extend existing Objects:
We can also extend existing objects in VMware Aria Operations. This means that if we simply want to add metrics from our created management pack to a Virtual Machine, for instance, we can simply append them onto that object. In order to add metrics or properties we must first have a connection to VMware Aria Operations (I’ll say it again because I haven’t said it in a while… formerly vRealize Operations) so that we can use the resources from our instance. If I click on “Add existing object”, we get the option to either connect to a previous instance or create a new connection. If this is already populated, we can connect and select the resource we wish to extend.
Much like adding new objects, the options to choose which request we would like to use as well as the attributes within each request are presented for us. We can continue adding metrics and attributes to each object or add multiple attributes from different requests to the same object. The only step we would not need to take is to add an icon. Since VMware Aria Operations already has these set up for us, there is no need to add one here.
Adding VMware Aria Operations Connections
As was mentioned before, we can set up a connection to VMware Aria Operations in order to pull objects to extend or to help us create relationships with objects outside of Management Pack Builder. This can either be done on the fly like the screenshot above or set up prior to the start of designing any management pack. This does not have to be the VMware Aria Operations instance that you will eventually deploy the finished management pack, but only a starting point for telling management pack which objects you would like to extend or relate to other objects. This is merely setting up the framework for the design. From the home screen or during the design of a management pack, to create a new connection, simply click “create” and a window for the hostname and credentials is displayed.
Once entered you can manage these connections to either delete them or change the information contained.
Relationships
The first of the optional sections is creating relationships for the objects that you have created. If you would like to create objects and corresponding attributes and send to VMware Aria Operations without relating them to each other or vCenter objects this is perfectly acceptable. If, however, you would like to relate objects to each other and other vCenter objects, we can certainly do this, as well. Clicking “Add Relationship” will present us with a few options. We need to have a bit of knowledge around what object is to be the parent and which is to be the child first. Once we have decided this, we can simply choose our objects from a drop-down and move on to pick the properties that will match these two together. In our example, I am relating the Rubrik Cluster to the Rubrik VM. I choose the Cluster as the parent and the VM as the child and find some properties that will tie these two together.
When choosing the matching properties, an example is used to help decide which property to use. These examples in parentheses don’t have to match exactly; it is only the format of the example we are looking to compare with.
These example happen to be the same ID for the Cluster and PrimaryClusterID for the VM, but not all examples will be the same. If we look at the next relationship we are setting up between the Rubrik VM and the vCenter VM, we first used our existing VMware Aria Operations Connection to pull in an existing resource from VMware Aria Operations, namely the virtual machine.
In this case we need to choose the “moid” from the Rubrik VM and the “VMEntityObjectID” from VMware Aria Operations virtual machine. As we can see, the examples for each don’t match up, but the overall format does.
We can use this structure to set up as many relationships as we would like using the objects we have created or objects within VMware Aria Operations.
Events
Pulling events from requests in Management Pack Builder will allow us to send these events as alerts into VMware Aria Operations. We could either set up a separate object for events like we did with other requests above or use the event feature from the navigation pane. This is the last optional step to create our management pack. We still need to set up a request for events that we can use in this step, which we can choose from a drop-down. We then need to choose the location of events within the API response from another drop-down. We then choose if we want to pull all “basic” information (which we can filter with REGEX) or “advanced” to further customize the responses.
The next step is to choose how we would like to map the severity levels between our specified API and the level in VMware Aria Operations. These will vary depending on the API that has been chosen.
Step 3 is to match our events to the objects they are related to. We can choose to match an event to the first matching object or all matching objects that the alert is related to. We could also make these matches ourselves in order to map the events to more objects.
The last step would be to optionally define our alert definitions here in Management Pack Builder. We can set the Type, Subtype, Impact, Wait Cycle, Cancel Cycle, and set a recommendation to remediate the alert.
We could also build these definitions out in VMware Aria Operations at a later time. If more granularity is required, such as symptoms that look for specific text in the event message or alerts based on multiple symptoms, set this option to ‘No’ and create alert definitions directly in VMware Aria Operations.
Configuration
The last section of any design is the configuration options. These are options to change the name of the management pack, change the author, version number if versioning is necessary, and the collection interval of the finished pack.
We can also set the default advanced settings for the management pack. These will be the defaults but can certainly be changed within VMware Aria Operations at a later time, if needed. These will merely be the starting point for the management pack.
Building the Finished Design
Once everything in the design is completed to the specification that you are looking for, it’s time to build the management pack from the design. In the top right corner of a design are buttons to “Save” or “Build”. Next to this is a check mark with a circle that will let you know if the last save contained a valid design. If this check is not green, it means that the design isn’t valid and is clickable to uncover the potential errors to fix to make the design valid.
If we click the “Build” option, we are taken to a preview of the design. We can see the objects that were created, the relationships we made, both external and internal to the pack, and the events we have specified.
Clicking “Next” will bring us to an optional Sample Collection. We can use existing connections to VMware Aria Operations here to make sure that our objects and relationships were done correctly and can be sent to VMware Aria Operations. If we perform this sample collection, a summary will come back to us that will tell us how many resources, metrics, properties, and events were collected, as well as how many relationships were found.
We can look at the logs here to find specific objects, the names of the objects, and the metrics or properties that were added. This sample collection is validating that we have connection to our specified API, VMware Aria Operations (one last time, just for fun – formerly vRealize Operations), verifying that our credentials are all still working properly, and validating the design once more to make sure we haven’t made any cyclical relationships or other errors in our design.
Clicking “Next” one more time will build the design into a management pack and allow us to download the .pak file. We can download right from this screen or go to our management pack builds and download from there.
That was the last step of building your own management pack from scratch with no code! From here we can go to the “Management Packs” section from the home screen to see all of the possible management packs and their versions and build times.
Hopefully this blog inspires you to create your own packs and share them with the community at the official Management Pack Builder Community Page. Management Pack Builder can be downloaded from Customer Connect (at the bottom of the page). The official documentation is available to peruse, along with the Release Notes.
As always, Thanks for reading!
