In this module, you will work with Elements and service monitors, and create Element Groups and Service Groups for them, respectively.
On a practical level, doing these exercises will get you accustomed to using the Uptime Infrastructure Monitor interface to create different types of groups, and assign service monitors to Elements. At a conceptual level, you will learn how inheritance occurs in groups in Uptime Infrastructure Monitor, and gain an understanding about how you can focus on structuring your monitored inventory, while Uptime Infrastructure Monitor takes care of tracking Element-level relationships.
This module consists of the following exercises:
Exercise | Description | Time required |
---|---|---|
Create a Service Monitor and Service Group | Learn about service monitors in Uptime Infrastructure Monitor. Create one as the foundation to a Service Group. Learn how Service Groups work by linking one to all of your Elements in one step. | 1 slice |
Create Element Groups | Begin organizing your monitored inventory by creating an Element Group and a pair of child Element Groups. | 1 slice |
Learn About Inheritance | Create a new Service Group (including a service monitor) and assign it to a top-level Element Group. Examine the services of an Element in a child group to learn about inheritance. | 1 slice |
In the first module, if you followed all three tracks, your inventory should now include a Hyper-V or VMware vCenter Server (along with its inventory of ESX hosts and VMs), a pair of physical servers (one agent-based Linux system, and a WMI-based Windows system), and an SNMP network device. The screenshots used in this module reflect this. For the exercises in this module, the two physical servers are used as examples. If you did not add physical servers to your inventory, you can either just follow along, or consider adding physical servers so that you can do every exercise. |
As a default way to report server uptime, for every server-type Element that is added to Uptime Infrastructure Monitor's inventory, a Ping service monitor is also created and assigned to it, in a one-to-one relationship. In this exercise, we will replicate this functionality, but instead using a single service monitor. We will be able to create a one-to-many relationship between a service monitor and all of your Elements using a Service Group. A Service Group is a group of service monitors that can be assigned to Elements or groups of Elements.
pingTest
, and make it Unassigned.In the main UI window, the Info page for your newly created service monitor is displayed. Note there is no value in the Host field, showing that it is not assigned to any Element.
Let's now create a Service Group that includes the service monitor, and is assigned to the Infrastructure Element Group.
pingable
: Configure the Service Group to include the pingTest service monitor you created earlier in this exercise, and associate it with the My Infrastructure Element Group.
My Infrastructure is always available as an Element Group, as it represents all of your monitored inventory (or, Elements), as shown when you view it in the Infrastructure panel. The other two groups shown in this example (Discovered Hosts, and Discovered Virtual Machines) were automatically created when you added a VMware vCenter Server as an Element. |
While we are viewing this Element's Status page (if you have clicked the Info tab, return to the Status page by clicking the Services tab), let's learn a few more things about service monitors and Elements using the example screenshot above, which is of a server-type Element with an Uptime Infrastructure Monitor agent installed on it:
Now that you've gone through a rudimentary exercise of creating a service monitor, a Service Group, and assigning them to the Infrastructure Element group, we'll learn more about their properties.
As you add Elements to Uptime Infrastructure Monitor, by default, they end up at the top of the Infrastructure hierarchy. Unless you are monitoring a small number of Elements, it's best practice to keep your monitored inventory well organized. Doing so helps both administrators and end users, which we will see in this exercise.
How you organize your Elements may depend on the policies that determine other aspects of your IT infrastructure, such as naming conventions for hosts. You may want to divide your inventory primarily by platform (for example, you could have Linux, Solaris, and Windows top-level groups); you may want to divide by geographical location; or you could organize first by Element function (for example, Production versus QA/UAT). In our example, we'll organize our Elements by function, then by platform.
Provide a Group Name of Production
, leaving the other configuration options empty, or at the default value:
Windows Servers
, and make the Parent Group the previously created Production group: From the Available Elements list, locate and add your Windows Element.
As mentioned at the beginning of this module, it is assumed you have Windows and Linux server Elements in your inventory. If you don't, you can either follow along, substitute these examples with something similar in your current test inventory, or go back and add these types of Elements. |
Linux Servers
, and again make Production the Parent Group:Click Save, then click Close Window.
Notice how we did not add your Linux server to the Linux Servers Element group as we were creating it. You can also assign an Element to an Element Group from the perspective of the Element itself.
Click Save.
After adding the Element Groups, in the main UI window, Infrastructure is displayed. Click to expand the Production group, and the Windows Servers and Linux Servers child groups. Each of these child groups contain one Element.
Structuring your monitored inventory in Infrastructure not only facilitates Element management for system administrators, but, as the structures are reflected in dashboards, can also be useful for end users.
Elements are not just servers, network devices, and their virtual instances; they can also be Applications and SLAs. Although based on metrics retrieved from monitored hardware (whether physical or virtual), Applications and SLAs provide health and performance information from a business perspective. Nonetheless, they are also found under Infrastructure, and can be placed in their own Element Groups. Refer to the product documentation for more information about SLAs, and Applications and the Applications dashboard. |
Click Dashboards, then click the Resource Scan tab. This dashboard summarizes resource usage for server-type Elements from various points in your hierarchy of Elements: you can click an individual server to show its usage data, or Element Groups to show an average of all its Elements. Your Production group is here, showing an average of the data for the servers you added to its platform-specific child groups. Click the parent group to drill down and display the Windows and Linux child groups. Each child group now shows usage data for its respective Element. Click either child group to display its contents, which in our case is a single server that you added:
When you are viewing data for one child group, you can move laterally to display a sibling child group by using the drop-down at the end of the breadcrumb trail at the top of the dashboard:
Keeping your monitored inventory well organized has several important benefits including more relevant at-a-glance viewing, logical drill-down paths for investigation, and focused report generation. Element Groups are even more useful when combined with Service Groups, which we will explore a bit more in the next exercise.
In the sample images above, the gauges and performance graphs are showing more information than you may be seeing on your own Monitoring Station. A data-collection interval is required to have passed before any information is shown; until then, you may see empty graphs such as the following: |
In the first exercise, you created a basic Service Group and assigned it to all of your Elements via the Infrastructure Element Group. Let's create another Service Group that demonstrates inheritance. To do this, we make use of the Production parent Element Group we created in the previous exercise. But first, let's create a service monitor that is part of the Service Group. Because it is assigned to Elements in the Production Element group, this service monitor should be something appropriate for all servers in a production environment.
Server Performance (Prod)
, and leave it Unassigned (we are going to create a Service Group for it): Server Availability/Performance (Prod)
Click Infrastructure to see your hierarchy:
Remember, referring to the structure presented in the example above, that you directly assigned the Service Group to the Production Element Group, and you chose to include subgroups. Click one of the Elements in either the Linux or Windows child Element Group. When that Element's General Information page is displayed, click the Services tab, then Manage Services.
Note that the "Server Performance (Prod)" service monitor is now attached to this Element by way of the Service Group. In the above example, we are showing the Linux server. The service monitor will also now be attached to the Windows server:
Additionally, whenever an Element is created in, or moved to, the Production Element Group (and, as configured, to either of its subgroups), that Element will inherit whichever service monitors are assigned to the group.
Extrapolating from this example, you could create a battery of service monitors that act as performance and health checks for all production servers. These service monitors would be added to the Server Performance (Prod) service group that is associated with the top-level Production Element Group. You could then create platform-specific health checks, and add them to appropriate Linux- and Windows-specific Service Groups (which you would need to create). These Service Groups could then respectively be associated with the existing Linux Servers and Windows Servers Element Groups.
Once these Service Group and Element Group relationships are established, if you created more child Element Groups, the respective Elements they contain would inherit the appropriate service monitors. (For example, adding a "Solaris" Element Group as a child of the Production group, and sibling of the Linux and Windows groups means the Solaris servers will inherit all of the general health check service monitors; adding a "Databases" Element Group as a child of the Windows group means the database servers will inherit all the Windows-specific health check monitors.)
The important thing to note is it's more efficient to manage not at the Element level, but at the object level, whether that object is a Service Group, Element Group, or other Uptime Infrastructure Monitor construct you will learn about; if you focus on Element Groups and Service Groups, everything else lines up and falls into place. Well managed arrangements of Element Groups and Service Groups can result in powerful cascading configurations.
|