KnowledgeItem is a concept that allows users to attribute business-relevant information to their monitored infrastructure. This information may include (but is not limited to) cost-center attributes, business unit associations, or configuration and application management metadata.
The Management Server pre-defines an abstract type KnowledgeItem that contains basic information:
The Management Server will offer management of these knowledge items in the UI in a later release. At the moment, users should extend the KnowledgeItem type as desired, and create business-related knowledge content and references in scripts.
The following is an example of a simple business-unit related knowledge item:
To add real value to this basic knowledge item, extend this type, by renaming and customizing it appropriately — see <foglight_home>/extension/knowledge-items/acme-types.xml
The types-file can be imported into the model by copy and paste, or as a file upload in the Administration > Data > Add Topology Type dashboard.
The Management Server shows the KnowledgeItems in the model under Services > All Model Roots > Knowledge Items and Root of Monitoring > KnowledgeItemModel >knowledgeItems. To see the data model tree, in the navigation panel, under Dashboards, click Configuration > Data.
The server comes with an example that shows how to surface the knowledge items in the UI. The example dashboard depends on a Acme example KnowledgeItem type (see <foglight_home>/extension/knowledge-items/acme-types.xml) that first needs to be imported through the Add Topology Type dashboard. The example dashboards can then be imported by using the following command:
When accessing the Service Operations Console (in the navigation panel, under Dashboards, click Services > Service Operation Console), all Acme knowledge items for elements inside the selected service are then shown in an extra tab, named ACME BU Knowledge Items.
This section provides a tutorial that walks you through the process of adding new functionality to Foglight, by building new models and without changing the Foglight core code.
The technique for extending Foglight is shown in the following illustration.
The process consists of the following steps:
4 |
To demonstrate the power of models, we are going to create a company org structure inside Foglight.
To do that, we are going to create three objects: Organization, Manager, and Employee. Manager is a subclass of Employee.
All the relationships we need are going to be modeled using three collections:
• |
• |
• |
In a real-world case, the identity of each employee is defined by an employee ID. For this example, we are going to define the identity of an employee based on his or her first and last name. That feels like a unique value for an individual, at least in a small organization. For Organization, we are going to define the identity based on the name of the organization. The reasons behind choosing this option are explained in the following scenarios:
• |
• |
Manager: same identity as Employee, has a directReports collection of Employees. |
• |
Organization: identity field orgName. Has an orgLeader link to the organization’s manager, and has a childOrgs list of departments that make up the organization. |
Rather than examining the syntax for topology type definitions, we are going to study real examples.
In Foglight types, a type can extend another type. Most types extend TopologyObject in order to inherit alarm propagation and roll-up features. Each type contains a set of properties. A property can be:
We can get started by looking at the simplified definition for the Employee type. It contains two properties, lastName and firstName:
1 |
On the navigation panel, under Dashboards, click Administration > Data > Add Topology Type. |
2 |
3 |
To validate the type definition, click Validate. |
4 |
Click Close. |
5 |
6 |
Click Close. |
The Employee type definition is now part of the Foglight topology types. We should highlight the following characteristics:
• |
Employee extends TopologyObject. This means that it inherits all the alarm roll-up capabilities that most Foglight objects use. We want this capability because we want to be able to show the state of the systems managed by an Employee. |
• |
• |
Both lastName and firstName are identity properties. This means that the combination of first and last name define a unique Employee object instance. You can have two Employee objects with the same last name, or the same first name. But the combination is considered unique. |
Next, we are going to look at a slightly extended version of the Employee object:
This (partial) definition includes new properties, which hold basic contact information for each employee. We have added jobTitle, phoneNumber, and emailAddress. These properties are a little different than lastName and firstName. Specifically, they are not identity properties. What that means is:
• |
An Employee is not uniquely defined by his or her phone number, for example. A change to a phoneNumber property does not create an Employee instance. |
The next interesting definitions are for ownedItems and interestingItems, which are used to model an employee’s system responsibilities. If Bob in IT is responsible for three machines, we want to be able to represent that relationship. We have chosen to add two collections to represent this relationship:
• |
ownedItems: represents those items for which an employee is responsible. The state of these items impact the state of the employee. If Bob in IT has three machines, and one of them is in a Fatal state, then the Employee object representing Bob is in a Fatal state. This is made to happen by setting is-containment to true. |
• |
interestingItems: represents things that an employee finds interesting, but for which they are not responsible. This allows us to maintain a relationship between an employee and other things that does not result in alarm state rolling up. This is made to happen by setting is-containment to false. |
NOTE: Both ownedItems and interestingItems are set to type TopologyObject. Remember that TopologyObject is the base type for most objects in Foglight. By using this as the type for a collection, we are allowing nearly any object to be added to the collection. In this case, it makes sense, as it allows for an Employee to include services, hosts, application servers, databases, and agents in their ownedItems list. |
There is one last technique to show related to model definitions. The value of a property can be set at run-time by agent or script, but we can also supply code to create a property. As a simple example, consider the fact that we have stored lastName and firstName separately. It is likely that we want to put the two names together when we build dashboards. To do that, we could add a fullName property that has a copy of the data in lastName and firstName, but they might get out of sync. It makes much more sense for us to make fullName a derived property, and to provide a Groovy code to calculate its value:
The code is straight forward and should be familiar to everyone who knows either Groovy or Java®. We are building a string that puts the first and last names together, and returns that value. When we access fullName, this script is run.
The Manager type extends Employee; its simplified definition contains one property, directReports.
This adds the ability to have a list of direct reports. By setting the is-many attribute to true, we allow a Manager to have zero or more Employees.
The Organization type (simplified) definition contains several properties:
An Organization inherits TopologyObject. Each Organization has an orgName that uniquely defines its identity. All Organization instances must have different values for orgName.
Each Organization has a relationship with a Manager through the orgLeader property. Each Organization can only have one manager. This might be a flaw in our model, but we will keep it as-is, for now. Also note that is-containment is set to true. This means that an Organization inherits the state of its Manager, who in turn inherits the state of his or her Employees.
Each Organization also has a relationship with zero or more child Organization objects through the childOrgs property. This property has is-many attribute set to true, in order to allow an Organization to have zero or more child Organizations.
1 |
On the navigation panel, under Dashboards, click Configuration > Data. |
2 |
Expand the topology tree to show the Management Server > All Data > All Type Instances > TopologyObject collection. |
3 |
Open TopologyObject > Sub Types, then (for example) open Organization to see all Organization object instances. |
This creates a model that contains all Organization instances. As we create our objects (see Full definitions for the org structure types), we need to make sure that we add them to OrganizationModel.organizations. But how does this help? The key is the ModelRoot. This is a special marker class that tells Foglight to include this model in the list of ModelRoots. This means it displays as shown in the following illustration.
As a result of including something in ModelRoots, you can now refer to your model in a query like this:
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Nutzungsbedingungen Datenschutz Cookie Preference Center