Maps configuration
- Juan Tomás Alonso Nieto (Deactivated)
Analytics
First time execution
Go to Devo’s main menu and click on Applications > Service Operations. Refer to the installation section if Service Operations does not appear in the list of available applications.
After the application’s initial loading process, you should see Service Operation’s welcome section:
Service Operations manages two types of maps: global and domain-specific. Typically, the first execution will yield no available results for domain maps, and the application will inform you about this status as shown in the previous screenshot. In the following sections of this document, the full procedure to create a new map will be explained, but at this point it is also possible to click on the Global maps tab and select one of the Devo-curated maps that are available off-the-shelf. Please refer to the Global maps section in this documentation for more information on the access and usage of global maps.
Maps management
Click on the Go to administration button. The administration module of Service Operations will be loaded and it will go straight into the maps management section, listing all available maps in the current domain:
The two sections available in the left-hand side menu related to maps, provide two types of management capabilities:
Available maps: Lists all available maps in the domain and allow their direct access (execution) as well as handling their associated back-end jobs.
Manage maps: Provides general editing capabilities for all available maps, as well as the option to create new ones.
Creating a new map
Creating maps in Service Operations is a fairly iterative process that commonly starts with sketching the general service or application map you want to monitor, and how it breaks down in terms of main building blocks, subsystems, and so forth. It generally reaches the lowest level of detail with the atomic KPIs and/or KQIs that rule the operational, performance or business related-status of their affecting entities. Once that rough design of the service map is done, it becomes a far simpler task to begin translating that design in terms of actual entities and relationships in Service Operations. As a general recommendation, it is a good idea to work with two browser tabs simultaneously; the first one to navigate and perform the actual configurations on Service Operations, and the second one to run and refine any queries that will be necessary for the map creation.
Follow the steps outlined below to complete the creation of a new map:
Go to the administration interface by clicking on the config icon in the Service Operations main menu.
Click on Manage maps under the maps main section on the left menu. A list of all available maps in the domain and their associated categories will be shown:
Click on the Create new map button. The interface changes to the map editing mode, showing a blank configuration for the newly created one.
Once there, to configure the new map, collapse the left menu (button 1 in the image): Hide the main menu of the administration module.
Contextual editing tools (add entity "+", for example, button 2 in the image): Addition, cloning or deletion of entities in the map. Since it is a context-based tool, the number of active options will vary depending on the selected entity in the map.
General map setting (button 4 in the image): Shows or hides the general configuration parameters of the map.
Creating entities
Click on the "+" button to add a new entity to the map. A form will be shown with all necessary parameters to be set in order to create the new entity:
Entity definition section
The following table shows the general parameters associated to an individual entity. Asterisks denote mandatory fields to be filled out.
Parameter | Description | Value type |
|---|---|---|
Auto mode | Overall behavior of the entity in terms of its status calculation. When auto-mode = off, the value of the entity will be retrieved from the result of the associated query defined for it. If auto-mode = on, the result of the query will be ignored and overrode by an automatic calculation based on the aggregation of the normalized status values from the entity's child nodes. | Enabled / disabled |
Name | Name of the entity. | Text string |
Description | Textual description of the entity. | Text string |
Icon | Graphical representation of the entity. There are more icons that they can be searched writing on the input. | Icon of the Devo icons list |
Value unit* | Entity metric unit: status, connections, errors, requests, and so on. | Text string |
Precision* | Metric decimal precision: “2” of precision specifies 2 decimals to be shown for a percentage value. | Number |
Best value* | Best value that can be reached by the metric (for example, 100% of health score). | Number |
Worst value | Worst value that can be reached by the metric (for example, 0% of health score). | Number |
Warning threshold | Metric warning threshold value (for example, 50% health score). | Number |
Dynamic warning threshold query | LinQ-format Devo query that defines the warning threshold dynamically. If this query returns inconsistent values referring to the entity definition (best and worst value) this threshold will be ignored and static threshold will be applied. | Query in LinQ format |
Critical threshold* | Metric warning threshold value (for example, 25% health score). | Number |
Dynamic critical threshold query | LinQ-format Devo query that defines metric critical threshold. If this query returns inconsistent values referring to the entity definition (best and worst value) this threshold will be ignored and static threshold will be applied. | Query in LinQ format |
No data criticality level* | Default criticality level when there is no data. | List of predefined values |
No data value | Defines metric value when there is no data. | Number |
Visualization type | Configure in which types of visualization the node will be represented: summary, topology, geolocation, 3D. | List of predefined values. Choose one or more |
Autodiscovery query* | LinQ-format Devo query that implements the two most important features in the entity definition: discovery of existing individual entities in run time as well as the calculation of their respective status value (for non-auto entities). All autodiscovery queries in Service Operations must be implemented with a grouping clause (group every), and finished with at least a "select" clause after the last "group every" to determine the value of the entity. Only the last "select" clause will be utilized in the calculation of the entity’s value. | Query in LinQ format |
Autodiscovery criteria | If the Autodiscovery query contains a final "group by" clause with at least one grouping value ("group every xxx by yyy, zzz"), those grouping values will be selectable in this field and used by Service Operations to discover all entities based on the grouping key values. This mechanism ensures the definition and discovery of entities gets simplified to the maximum, eliminating the need of creating individual entities per each element of the same time to monitor. | List of predefined values from the Autodiscovery query |
Inventory query | LinQ-format Devo query used to retrieve the inventory information referred to the same entity. This query will add to the entities in map the list of all the components, whether they have data or not, so those without data will also appear on the list. Entities discovered through the autodiscovery query will be matched against the inventory query results, and any deviation will be highlighted as a "missing data" condition. | Query in LinQ format |
Metadata section
Metadata fields definition is an optional process but it is important for data filtering actions, as well as for the activation of certain application functions such as to populate the Customer Experience section, or to enable the calculation of incidents.
Parameter | Description | Value type |
|---|---|---|
Type | Main category that defines the entity being modeled. Some of the entity types are utilized for automatic calculations of service metrics and incidents. For example, the "KPI" type is reserved for entities that measure a concrete metric affecting its parent node ("CPU consumption", for example), and are a pre-requisite for the detection of incidents. In other words, incidents require at least one entity defined with type "KPI" to work. Additionally, types "user", "session" and "device" are utilized by the User Experience module to automatically compose the status of the service from an end-user perspective. | List of predefined values |
Subtype | Subtype of the entity, more oriented to the environment or purpose it is defined, for example, business-specific, operational, and so forth. The subtype value is utilized only in filtering actions. | List of predefined values or custom string |
Additional metadata fields | Customizable data fields per entity that can hold any sort of additional information or parameters. They are commonly used to enrich the entity definition. Typically, these metadata fields are utilized as filtering criteria together with "type" and "subtype". Metadata fields are configured as key/value pairs. The key is defined as a string, whereas the value has two different possibilities: static value (treated as another string) or a query. In the case of adding a query with more information than type or subtype, that information will be reflected, as additional information in entities Information in Service Overview. | Key, value pairs, composed by string + string or string + LinQ query |
Impact assessment section
Parameter | Description | Value type |
|---|---|---|
Generate incidents for this entity | Enable or disable the generation of incidents for the entity. If this switch is disabled, no incidents will be calculated nor reported for the entity. | Enabled / disabled |
Query | Query that is triggered any time an incident affects the corresponding entity to calculate the level of affectation the incident generates. For example, if an entity definition maps the operational status of a web server, the impact evaluation query could be defined to calculate the subset of client hosts that have received an HTTP 500 code as a result of any connection request. | LinQ query |
Unit | Text-based description or unit of the entities affected by an incident (for example, “end-users”, “network nodes”). | String |
Linking entities
Once there are at least two entities created in the map editor, it is possible to link them to specify impact rules. For example, two "CPU consumption" and "Server" entities are created individually, it is possible to establish a link between "CPU consumption" towards "Server" to indicate "CPU consumption" is an impacting entity on the status of "Server’" Furthermore, if the type "CPU consumption" is "KPI", the incidents detector mechanism will be able to create incidents and determine their root cause using it.
To link two already-created entities use the following procedure:
Click on the source entity. The entity will be shown highlighted in the model, and a icon in the upper part of the node will be displayed.
Click on the button, keeping the button pressed down by your mouse, and start dragging the arrow to its destination.
Release the button on your mouse when the arrow is pointing at the border of the targeted entity.
To unlink two entities:
Click on the arrow that they are connected by.
Click on the paper bin icon on the top of the screen. Alternatively, you can press the Supr button on your keyboard.
NOTE: Remember the relationship you are establishing is based upon impact. That means, links should be read as "source entity impacts the status of the targeted entity".
Linking entities using a link criteria
The mechanism described in the previous paragraph is the standard to link entities in an all-to-all way. The following table of results should be expected when linking entities using that approach:
Cardinality of source entity | Cardinality of target entity | Expected result |
|---|---|---|
One (no discovery key defined or only one entity value discovered, for example) | One | The established link is rendered as a one-to-one relationship |
One | Many (a discovery key has been defined and there are multiple discovered entities, for example) | Single one-to-one links are rendered, one per discovered target entity |
Many | One | Single one-to-one links are rendered, one per discovered source entity |
Many | Many | Full all-to-all relationships mesh |
In some situations though, it is necessary to link sources and targets based upon some criteria. In the event of this, it is possible to set a linking criteria to ensure only those links will be created.
The procedure to observe is as follows:
Create a link between two different entities using the procedure described in the previous section.
Click on the link (arrow). A form on the right hand side of the screen will be displayed with four options:
Use the dropdown selectors to set the linking criteria between the two entities. Service Operations will list all grouping keys defined in both source and target entities' value calculation queries. The way this should be interpreted is as follows: “link the entities whose value in the ‘from’ column matches exactly the value of the ‘to’ column". Looking at this mechanism from a different perspective, a join operation is being performed between the source and destination entities' tables, linking the details of those entities for which there is a match between the ‘from’ and ‘to’ column values.
Click apply. The link criteria is established and displayed in textual form on top of the arrow between the two linked entities.
By definition, only those entities with grouping keys in their value calculation definition can be linked using this mechanism. If Service Operations cannot retrieve the grouping keys for both queries, a message in the same form will be displayed informing of this situation.
It is possible to assign a relative weight to the established link. The link weight is utilized in the calculation of the final score for auto entities, or more specifically, as a multiplier to the normalized value of the underlying child node. For example, if an ‘auto’ parent entity called ‘Server’ had two child nodes ('CPU' and ‘Memory’) implemented as KPIs and linked to the parent entity, the overall status score for ‘Server’ would be automatically calculated using the normalized values for ‘CPU’ and ‘Memory’, and then by applying the weighting factor for each of the two nodes. If the specified weight for ‘Memory’ were 0, then the overall score of the ‘Server’ entity would be a normalized version of the ‘CPU’ metric alone.
The weight value can be specified either by a static number (1, 0, 0.5, and so forth), or as the result of a query using the ‘Dynamic weight’ input field. Use that field to specify a LinQ query whose evaluated numeric result will be the applicable weighting factor for the link.
Configuring summary view
The Service Overview module in Service Operations supports multiple layouts for the representation of the real-time status of a service or application. One of them is the so-called ‘Summary views’ (or ‘Summary’ for short). Summary views consist of a reduced number of high-level entities and metrics displayed on a background image that condense all information calculated by Service Operations in an efficient, easy-to-interpret interface.
For Summary Views to be available, at least one entity in the map must be configured including the ‘Summary’ value in the ‘Visualization type’ list. Note that only those entities with an Autodiscovery Criteria value set to ‘None’ are eligible for Summary Views. Once the previous conditions are met, the ‘Summary Options’ button will become available and clicking it will switch the map editing tool to the Summary View editor.
Summary views in Service Operations support a nested approach, meaning it is possible to create and navigate through different levels of visualizations. While the first level of the Summary always corresponds to the level-1 entities defined with such visualization type, users can navigate to a second and subsequent levels by linking level-2, level-3 entities to the parent ones and defining them also with the ‘Summary’ value in their respective ‘Visualization type’ input.
For each entity defined as Summary in the Visualization type, a green box will be shown on screen, with a sample value and unit text ('0 unit'). Click on the green box and, without releasing the button, drag it through the screen to position it in its desired location on top of the defined background image. Check in the ‘Setting the General Map Configuration - Modules’ section in this same document how to set the initial background image for the Summary View.
A single click action on the green boxes will, on its side, show the ‘Summary Mode Settings’ form for the selected entity:
The following table summarizes all available configuration options for an entity in the Summary View:
Parameter | Description | Value type |
|---|---|---|
Elements | Elements to be displayed in the summary item: value, unit and chart. Each entity can be configured to be displayed as a combination of those elements, with value being the last evaluated numeric value of the entity, unit the textual description of the numeric value, and chart a number of graphical widgets to display the entity’s value: gauge or sparkline. | List of combinable value |
Summary node background image | The image of the background image for the child nodes in the topology level n+1 will correspond to the background defined in their parent node (level n). | URL to an image resource (e.g., http://****.com/background.png) |
Font color | Text font color of the value and unit fields. | Color picker |
Font size | Text font size of the value and unit fields. | Number |
Alignment | If the entity reports any of the statuses listed in this input (‘critical’), ‘value’ and ‘unit’ fields will be displayed as blinking text). | List of predefined values |
Blink with statuses | If the entity reports any of the statuses listed in this input (‘critical’), ‘value’ and ‘unit’ fields will be displayed as blinking text). | List of predefined values |
Warning status color | Text color when the entity reports a warning status. | Color picker |
Critical status color | Text color when the entity reports a critical status. | Color picker |
X coords | Anchoring X coordinate for the entity box. Value between 0 and 1000. | Number |
Y coords | Anchoring Y coordinate for the entity box. Value between 0 and 1000. | Number |
Setting the general map configuration
These settings describe the general characteristics and structure of a model. Among other things, these settings are used to configure the overall behavior of Service Operations mainly by enabling or disabling its main functional modules. Ancillary configurations are also performed in this block, such as the predefined analysis time range, and so on:
Global settings
Parameter | Description | Value type |
|---|---|---|
Map name* | Name of the map. | Text string |
Image | Icon of the map. | (e.g., http://****.com/icon.png) |
Category | Logical group the map belongs to. | Selectable or custom text string |
Subcategory | Logical subgroup the entity belongs to. | Selectable or custom text string |
Amount and unit* | Default time window utilized to define the amount of time back to be displayed by default in graphs. | Selectable numeric value and unit |
Level - N name | Descriptive name of the N-level in the hierarchy. | Text string |
Inventory query | LinQ-format Devo query used to retrieve the inventory information referred to the same entity. | Query in LinQ format |
Visual theme | Application visualization theme or visual skin. | Light | Dark |
Accent color | Main application color for visual components and texts. | Color picker |
Modules
Parameter | Description | Value type |
|---|---|---|
Sort module | Location in Service Operations main menu. | Switch to enable / disable the modules position in the application’s main menu |
Enabled | Status of the module. | Enabled / disabled |
Layout | Default layout schema applied to the nodes visualization in the map. | Hierarchy, Radial, Standard, Sequential, Organic, Structural, Lens |
Layer | Default layer to show when map is loaded. | Summary, Topology, Geo, 3D |
Orientation | Default layout orientation | Left to right, Right to left, Top to bottom, Bottom to top |
Level | Default maximum number of levels to display when map is loaded. | Number |
KPIs view mode | Define the way to visualize the KPIs on the map. The type of display chosen can greatly affect the performance of the layout view especially when there is a significant number of entities. Each option has an indicative value: LP (Low Performance), MP (Medium Performance), HP (High Performance). | Glyph info (HP), Glyph and combos (LP), Opened Glyph Grouping (LP), Donuts (MP), Donuts and combos (LP), Visibles (LP) |
Summary mode background image | Background image applied in the Summary layer. | Image URL |
Status panel | Availability of the status tiles panel. | Enabled / disabled |
Status panel expanded | Show the status panel by default when accessing the topology map. | Enabled / disabled |
Incidents viewer | Availability of the incidents viewer module. | Enabled / disabled |
Close incidents after | Incidents are closed after selected interval. An incident whose status is "new" will be closed after the indicated period of time | Number | List of predefined values |
Archive incidents after | Incidents are archived after selected interval. An incident whose status is “closed” will be archived after the specified period of time. | Number | List of predefined values |
Delete incidents after | Incidents are deleted after selected interval. An incident whose status is "archived" will be deleted after the specified period of time. | Number | List of predefined values |
Monitors | Availability of the monitors module. | Enabled | Disabled |
User experience | Availability of the user experience module. | Enabled | Disabled |
Administration
Parameter | Description | Value type |
|---|---|---|
Combine map | Allows the addition of the entities and nodes definition of another existing map within the current one. | Map selector via dropdown menu |
Rename / copy | Creates a copy of the current map. | New map’s name input |
Delete | Erases the current map definition. | |
Export | Download the current definition of the map to a local .json file. | json file |
Import (only in new maps) | Upload an existing map definition from a local .json file. | json file |
Init the data processor job
In order to see the maps and be able to work with them, it is necessary to init the data processor jobs. To do this, go to ‘Available Maps’ and click on the 'play' icon.
Three options will appear for displaying the maps:
Sampling period seconds: The period of time in which we want to monitor a map.
Enable stats module: Enable or disable to generate statistics of the entities. If you have it activated, the statistics will be added to Devo, in addition to the calculation of the state of an entity, its maximum, minimum, and average value.
Enable incidents module: Enable or disable to init or stop the incidents identification processor.