Impact Charts

Impact charts enable you see at a glance the impact of an outage, performance issues, or security issue on a data center object. Impact charts are available from the view mode for any building, rack, room, device or application component.

Device42’s powerful and agentless auto-discovery tool uses WMI and SSH to find out the services, listening ports and relationships between services and ports or executable and ports. This gives you a good picture of what services/executables are listening on what ports on that machine. Device42 captures a point in time snapshot of what other IP addresses are connected to ech listening port. If these IP address exist in Device42 and are mapped to devices, the system automatically shows the device when drawing the dynamic impact charts.

Impact Charts for Buildings, Rooms, and Racks

bldg-impact-1.png

The image above shows an impact chart for a building.
It’s a little hard to read so let’s zoom in on just the top part of the chart.

bldg-impact-1b.png

To zoom, move the zoom slider in the left panel a little and you will see a red rectangle. Drag the red rectangle around the portion of the graph you want to view….

bldg-impact-2.png

At the top of the graph is the building we selected (the “New Haven DC”). This building has one room (“nh-room1”) which has 3 racks. The first rack has a blade host device (nhdc-bhost-0003) and a virtual host (nhdc-vhost-0029). The blade host has 3 blades.

The image below shows the bottom portion of the left-hand panel…

bldg-impact-3.png

Here you can see we’ve selected the bottom portion of the graph (which we’ll show below).

Next, there is a “Download Image” button that you can use to download an image of the graph.

Next, you see two layout options: The Directed Acyclic Layout will produce a graph in which all the dependency arrows point down. The Force Directed Layout option will try to conserve space at the cost of having dependency arrow pointing in multiple directions.

Next, you will see a Find box. Here, you can search for objects in the graph. (Very useful if you have a complex graph like the one below for a device).

Last, you will see a legend that is self-explanatory. One note, however, is that a device impact graph will have a different legend (see below).

Here is the view of the bottom half of the graph…

bldg-impact-4.png

Here you can see the 3 blade devices. The first blade device is also a virtual host with 2 virtual machines. One of vm’s (“nhdc-vhost-0022”) is part of a clustered web farm. The cluster device (“webfram-0009”) is a Device42 construct with no physical counterpart. It is created as a grouping mechanism to hold the three devices that are part of the web farm (i.e. “nhdc-vm-0022” which is in the New Haven DC and two other vm’s that are in a remote data center). The Application Component (webfarm-0009) is also shown inside the cluster.

Topology Charts for Devices

Topology Charts for Devices have more detail than for other objects like buildings, rooms, and racks. In particular device topology charts show Services, Executables, and Ports.

Below is the topology chart for a device. (Don’t try to read the details. We’ll zoom in below.)

webserver Toplogy Chart

A device topology chart shows three types of information:

First, you can see what Services, Executables, and Application Components are running on this device. Services and Executables are detected automatically. You have to enter information about Application Components. Application Components will be explained below.

Second, you can see what ports are being accessed and which Services and Executables are providing information over those ports. You can also see which Services and Executables on remote devices that are accessing each port.

Third, you can get a full picture of what would be impacted were there to exist a performance or security issue on the device, or if you just need to take the device out of service. You can see which Services, Executables, and Applications will be affected on the device itself but more importantly, you can see Services, Executables, and Application Components on other devices that depend on this device. For example, if the device is a blade chassis or a virtual host, all the blades and/or virtual machines are dependent on this device and you will see those dependencies. Similarly, if Device42 discovers that a remote device is connecting to a port on the device, you will also see the remote device (and its Services, Executables, and Application Components) in the topology chart. Finally, you can define which Application Components depend on which other Application Component manually (see below) and you will see these dependencies in the chart also.

If you look at the bottom left of the screen shot above, you will see the legend for the chart. As you can see devices are green, services are light blue, executables are dark blue, service ports are purple, and application components are yellow.

Just above the legend are a set of display options. For example if you check “Hide services with no listening ports”, the diagram will be simplified as follows:

device-impact-2.png

Impact List

An Impact List is a list version of an Impact Graph. An example of an Impact List for the building “New Haven DC” is shown below…

impact-list.png

Dependency Graph

A Dependency Graph can also be generated for any Application Component showing all the devices, services, executables, and application components that it requires to function properly. A Dependency Graph for the CEO Dashboard application is shown below…

dependency-graph.png

How Are Dependencies Created in Device42?

One question we get in almost every demo is how are all these dependencies created. Actually, nearly all the dependencies you saw in the above charts were automatically created via autodiscovery and internal Device42 correlation processes.

It should be fairly obvious how all the physical dependencies are created. Buildings have rooms which have racks which have devices. The blades in a chassis are dependent on the blade host. Virtual machines are dependent on the virtual host.

Software and Services that are discovered on a virtual or physical machine are dependent on that machine. Many of the dependencies that exist between a service and other services and/or software are auto-discovered.

Only some Application Components need to be manually entered. If a service is defined to be application component, then the application component dependencies are all known.

However, you may want to define application components that are not tied to a service. Or, you may want to define an application component that is composed of multiple services. These application components and their dependencies can be defined through form, spreadsheets imports, and/or api calls.

The Device42 Windows Auto-Discovery Client does the actual discovery. In this tool, you will see button named “service port exclusions”. You can exclude the following to reduce the noise:

windows listening ports: example will be something like RDP port. 3389 is excluded by default.

windows remote ports – any remote ports you want to exclude

linux listening ports: example will be something like ssh. 22 is excluded by default.

linux remote ports – any remote ports you want to exclude

Remote IP Addresses – Remote IPs to exclude. Example will be your monitoring server IPs.