Searching through your Inventory

With New Relic Infrastructure, you can identify problem packages and configurations across your infrastructure in seconds.

Today, a serious zero-day vulnerability emerges with a fancy name and a fancier splash page (ex. Heartbleed, pictured right). They've identified the package responsible along with a number of dependencies. How do you deal with this?

The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library
Heartbleed: A vulnerability with a logo

The truly unlucky may have to ssh into every applicable machine and grep for applicable packages. If you are using an infrastructure configuration management tool (like Ansible, Chef, or Puppet) to provision your infrastructure, you might search your configuration files for the problematic packages. But remember, processes fail and configurations do not necessarily reflect reality. Make sure that the packages installed on your systems actually match your configuration!

In this tutorial you will learn how to:

  • Filter and Search through your Inventory

  • Identify Inventory item details and variants

  • Understand a real-world use case with a Heartbleed bug scenario

Filtering and Searching through your Inventory

As you learned in Using Filter Sets and Groups in New Relic Infrastructure, your inventory, event, and other data is all first organized through any applied filters on the host filter sidebar.

You can further filter within these resources by selecting the filter icon () next to the search bar. Selecting individual data source checkboxes here will change the available items in the adjacent inventory list. Learn more about inventory item and source naming at

Highlighted: Selectable inventory filter sources are made available via the filter function left of the search bar

Typing into the searchbar dynamically updates the inventory list by matching to the inventory item category, source, or label.

Identifying Inventory item details and variants

After identifying an inventory item of interest, you may select an item to view its attribute details and variants. Inventory items are grouped first by their data source and further by any applicable variant hosts. Resources with a number of variants will have a tag (ie. ) next to the inventory item name. Clicking on a host grouping will reveal any applicable hosts in that resource variant grouping.

Item detail attributes are key/value pairs determined by each source. For example, rpm, the Red Hat package manager, will send different attributes than dpkg, the Debian package manager. Source attributes are generally stable but can change depending on the source. This data is real-time, however, if a host stops reporting it's attribute data may persist for up to 24 hours.

Scenario: Heartbleed vulnerability

This short video walks you through the following scenario steps:

The Heartbleed vulnerability, discovered in 2014, affected the widely used open-source cryptographic software library OpenSSL. The following Heartbleed scenario will give you a good idea of how quickly you can identify problematic packages.

Step 1: Determine affected package versions and/or dependencies
In the case of Heartbleed, the affected versions included OpenSSL version 1.01 through 1.01f, so, these are the packages we will be trying to identify in our discovery.

Step 2: Search Inventory
Simply type in the affected package name; openssl, in this case. The inventory list will dynamically narrow down the results based on this search.

Step 3: Select an inventory item and identify host groupings using the affected versions
In this case, we've identified two separate data sources that include the openssl package, dpkg and rpm (Debian and Red Hat package managers, respectively). Clicking on each opens up the inventory item detail view. We see that our dpkg/openssl source has two variant hosts, both unaffected by our bug.

​Highlighted: Clicking on packages/dpkg/openssl reveals two host groupings NOT affected by the Heartbleed vulnerability

Clicking on rpm/openssl reveals four variant host groupings across four different releases, two of which are affected! We see that release 51.el7_2.5 and 60.el7 both use openssl package version 1.01e, an affected package. We can drill down into each host grouping by clicking the associated link, revealing the hosts affected.

​Highlighted: Clicking on packages/rpm/openssl reveals two host groupings affected by the Heartbleed vulnerability

Now you can identify problem packages and configurations across your infrastructure!