Docs

# Update 2.4 (10.08.2023)

⬇️ Let's take a closer look at the main changes to Acure 2.4:

Due to the introduction of new pages and to ensure logical organization of elements, sections of the main menu have been regrouped.

  • Overview
    • Operational Center - formerly the SM Map screen (now without tabular representation)
    • Events and Logs
    • Autotests
  • CMDB
  • CMDB View (former tabular representation of SM Maps with a separate CI card)
  • CMDB Changelog
  • Data Collection (ETL)
    • Data Streams
    • Agents
  • Reports
  • Rules & Actions
    • Rules & Actions
    • Threshold Rules
    • Scripts
    • Scenarios (formerly Automation)

# Splitting the SM Maps Screen

The SM Maps section has been transformed into two independent sections by moving the tabular representation of CMDB to a separate page.

The CMDB View section retains all the same functions that were previously in the tabular representation of SM Maps, and it also gains additional capabilities:

  • Perform actions with a single CI directly from the table
  • Share a link to the selected CI
  • Navigate to the detailed CI card with the ability to view and edit it

Gif

# Operations Center section

The Operations Center section now features the ability to track changes in CI statuses over time (heat map).

  • The list of CIs has been expanded with their statuses, divided by time intervals within the specified reporting period
  • Hovering over an interval displays the Health over the period: information about the minimum and maximum health and CI status values over the selected period
  • A time scale for the specified period has been added
  • Information about CI statuses over time is automatically updated via WebSocket
  • Four views have been implemented for the list of CIs:
    • Without the list of CIs: the list and statuses are collapsed
    • List of CIs with the option to display additional information: Type+Status+Maintenance+Lifecycle Stage, ID, Description, Health, Owner.
    • List of CIs displaying their statuses over time.
    • List of CIs displaying their statuses over time in full-screen mode.

Gif

# Other Changes to the Operations Center Section

Additionally, the new Operations Center screen has gained a set of features that simplify user interaction:

  • The screen now includes a unified calendar for selecting the display period. It works consistently across all tabs of the screen.
  • The Last changes option from the calendar has been moved to a separate checkbox within all tabs where the calendar was previously present. Activating it displays the latest 100 changes in the database without being tied to the calendar.
  • Favorited maps have been moved to a separate panel in the screen header. You can show or hide this panel in the Personal settings pop-up window.
  • Sorting of the list of CIs by their name or ID has been implemented.

Gif

# Update of Relationships between CIs

The model of relationships between configuration items (CIs) has been expanded. Users can now define three types of relationships between CIs independently of each other:

  • Hierarchy
  • Influence
  • Information

# Features and Limitations of Relationships

Informational Relationship

  1. There can't be more than one relationship of this type between two CIs.
  2. Any CI can have as many relationships with other CIs as needed.
  3. Working with this type of relationship is only possible through the public API. Displaying data about these relationships in the interface will be implemented in later versions.

Impact Relationship

  1. There can't be more than one relationship of this type between two CIs. A CI can only influence one component out of all the available components of another CI. However, it can influence multiple components of other CIs simultaneously.
  2. Relationships must not form a loop.
  3. A Dependent CI can have any number of relationships directed towards any of its components from different CIs.
  4. An Influencing CI can have any number of outgoing relationships.
  5. Working with this type of relationship is possible through:
  • The public API
  • On the SM graph, using the "Health" view.

Hierarchy Relationship

  1. There can't be more than one relationship of this type between two CIs.
  2. Relationships must not form a loop.
  3. A Parent CI can have any number of incoming relationships.
  4. A Child CI can only have one outgoing relationship.
  5. Working with this type of relationship is possible through:
  • The public API
  • On the RSM graph, using the "Structure" view.

# Changes in the Health Tab

  • In the new version, the Health tab features a three-level diagram that illustrates the impact of system objects (CIs, signals, components) on the health of the studied CI.
  • Users can investigate not only CIs but also CI components, revealing a two-level scheme.
  • Users can navigate through the diagram, exploring any object. The entire research path is displayed in breadcrumbs, enabling quick return to any previously examined object.
  • Users can access additional information about the studied object, such as its name, description, type, and switch to the parameters tab.
  • Information about signals attached to the studied object is provided, including their total count and criticality. Users can also switch to the tab containing all signals.
  • In addition to digital values, objects on the diagram are represented with visualized damage of varying heights, indicating the extent of inflicted damage.
  • Information about the object's health is presented, including its current health, status, and damage received from influencing objects.
  • Information about the object's minimum and maximum health values for today is shown.
  • A health graph is available for tracking changes in the object's health (CI or component) over a specific period.
  • In the influence configuration mode, users can modify settings for the CI component and the influence of CI/signal on the component, including weight, critical influence, and calculation threshold. When using the combo calculation, the number of non-operational CIs for the entire cluster can be specified.
  • The "Health" tab has an auto-refresh function that can be disabled, as well as the ability to manually refresh the information.

# Changes in the SM Graph Tab

In the Operations Center section, the Graph SM tab faced the following changes.

The graph has been divided into two views:

  • Health - represents the "dandelion" graph (as before) and allows working with influence relationships between CIs by configuring health calculation based on the graph.
  • Structure - represents a tree-like graph with the root CI at the top and allows working with hierarchy relationships between CIs.

On both graphs, users can view and manage corresponding relationships (with appropriate permissions to edit CIs). Users also gained the ability to add Labels to any of the relationships.

Existing influence relationships have been moved to the Health Graph, and the settings for these relationships (weight, criticality) remain unchanged. For containment relationships created before this release, migration was carried out. All existing hierarchy relationships were separated as follows:

  • Hierarchy relationships were separately created and are now located on the Structure Graph.
  • Influence relationships were separately created on the Health Graph, and the influence settings from existing hierarchy relationships were transferred.

It is now possible to create and delete influence and Hierarchy relationships independently of each other. Also, both types of relationships can exist between two CIs, directed in either the same or opposite directions.

The Health Graph has also been upgraded to incorporate the use of components.

  • When creating an influence relationship, users will need to specify which CI component the relationship should be established with.
  • Weight and criticality settings have been moved from the relationship settings menu to the Health tab.
  • In the relationship settings menu, users now have the option for quick navigation to the relationship settings and the overview of the selected component in the Health tab.
  • In the relationship settings menu, the CI component for the influence relationship can be changed.
  • Double-clicking a CI will redirect the user to the Health tab.
  • APIs for influence relationships have been expanded to accommodate the use of components.
  • The context menu for CIs now includes the option to navigate to the Health tab.

# Changes in the Signals Tab

In the Operations Center section, the Signals tab faced the following changes:

When clicking on a signal, a bottom panel is displayed to the user with detailed information about the signal.

In the detailed information, the user can see:

  • Associated CIs with the ability to link and unlink CIs available to them
  • Events with the ability to view JSON details for all events
  • Actions with the ability to open a popup with detailed information about the action
  • Tags with the ability to modify the list of tags for the signal from the detailed information
  • Attachments (interaction is possible only through automation scenarios)
  • Labels

Additionally, the fpllpwing features were added:

  • Users will be able to attach links to signals both through automation scenarios and manually through the interface.

When attaching a link to a threshold, the user will be able to navigate to working with the threshold within the current window using breadcrumb navigation.

  • A feature has been added that allows users to share signals by copying a link to them. This link can be used to open the signal in a new window or tab.

  • Information about associated Configuration Items (CIs) has been adapted to work with CI components.

# CMDB Settings - SM Metamodel

The SM Metamodel has introduced two new sections: CI Components and CI Status Model.

# CI Components

A default component named "Common" has been added to all CIs in the system. Each component has its own health and affects the CI's health. All existing influence relationships and signals that previously impacted a CI have been moved to the "Common" component. The CI component acts as an intermediary layer between the influencing object and the CI itself, allowing for a more nuanced adjustment of the CI's health calculation. Component management is carried out by administrators in the SM Metadata Model settings for the CI Type, ensuring that all CIs of the same type share the same set of components. Each CI Type must have at least one component. A component has two methods for calculating health: the previously existing critical-weighted method and the new combo method.

In this section, administrators gain the following capabilities:

  • Add / remove components for CIs of a selected type

  • Define the default component

  • Specify component influence settings on CIs

  • Specify the health calculation method for the component

    • Combo: This health calculation method aims to detect the failure of a critical number of CIs out of all CIs influencing a single component. When combo calculation is enabled, the weight and criticality of relationships between CIs are not considered - all relationships are treated as equal, and the influence of signals is not taken into account at all. This calculation has one setting: the number of CIs required for the complete degradation of the component.

    • Critical-weighted: Health calculation is determined by weight or by critical transfer, with the possibility to set a criticality threshold. The criticality threshold enhances the functionality of the critical transfer function. If the health of the influencing object (CI/component/health from signals) is above the defined threshold, the critical transfer is disabled; if it's below a certain percentage of health, it's enabled.

  • Specify default settings for influence relationships and signals

Important Note:

Changing default health settings within a component will only affect newly created CIs and will not alter settings for previously created CIs. These settings can be individually overridden for each CI in the Health tab.

# CI Status Model

In the new SM, the status of a CI depends on the health of the CI.

CI status can have the following values (standardized with signals):

  • Fatal
  • Critical
  • Major
  • Warning
  • OK
  • Unknown

Current CI statuses have been recalculated according to the new calculation model.

System administrators now have the ability to independently define status calculation rules for all CIs of a selected type, similar to the existing functionality in Thresholds.

Additionally, the ability to delete unnecessary CI statuses has been introduced, except for OK and Unknown. The calculation rules for these statuses cannot be changed.

All sections in the SM Metamodel are now standalone, requiring individual saving for each section.

# Attributes Update on CI Types

Administrators now have the following capabilities when working with attributes with CI types:

  • Defining basic attributes without creating a structure - these attributes can also be used as key attributes
  • Using the same automation library structure to define different attributes within a single type
  • Defining the display order of attributes in a CI by setting it on the CI type.

# Additional CI Types

To enable the automatic building of SM Graph from Kubernetes, additional CI types with predefined attribute models have been added to the system:

  • K8s Cluster
  • K8s Node
  • K8s Deployment
  • K8s ReplicaSet
  • K8s StatefulSet
  • K8s DaemonSet
  • K8s Pod
  • Persistent Volume

# Content Wizard

A new module called Content Wizard was developed - a configuration wizard that allows users to create necessary pre-configured Acure objects in just a couple of clicks. Now there's no need to manually configure all entities for a specific scenario (e.g., setting up event processing from Zabbix or others), as this service can set up a Workgroup to a functional state in a matter of minutes.

A Content pack can contain multiple independent scenarios that can be launched separately from each other in any order and any number of times.

The Scenario of a content pack is a collection of configured object templates, such as data streams, coordinators, automation scenarios, SM maps, and threshold rules.

Basic Zabbix and Kubernetes scenarios issued by Acure are available. These scenarios are mainly designed to demonstrate the platform's capabilities - adapting them might be necessary for your specific monitoring processes. However, in future versions, installation owners will have the capability to write their own scenarios and create content packs. Acure will also continue to develop these scenarios and prepare new content packs.

Summary of functionality:

  • In the Content Wizard section, there are cards for scenarios with brief information and a search feature.

  • On the detailed scenario viewing page, there are tabs with general information - Overview, the purpose of the scenario, and the Acure objects that will be created and configured as a result of the launch.

  • There is also a tab with instructions - Instructions, that need to be followed before/after launching the scenario (if required). For example, instructions for installing/configuring agents or related plugins.

  • After the first scenario launch in the Workgroup to which the user belongs, a tab with a history of launches appears - Run History, allowing the user to track all scenario launches.

  • In the case of a successful launch, instructions become available with actions needed to complete the setup (if necessary) or variables of configured objects (e.g., coordinator or fata stream API key).

  • If a scenario runs into errors, the user can identify the cause from the error log, which will also be displayed on the Run History tab.

# Data Streams

Users now have the ability to Export and Import Data Stream settings.

This feature enables users to duplicate Data Streams, transfer already created streams from one Userspace to another, debug the Data Stream on a test setup, and then move it to production.

The Export includes all the necessary settings for the successful operation of the Data Stream, including Task scheduling.

Users only need to fill in the parameters that were protected in the settings of the imported Data Stream.

Additionally, users can now filter the list of Data Streams. This feature allows users to flexibly configure the filtering of the streams they need.

# Automation

Several key updates have been released for the "Automation" module.

# New BuildsProcessor node for Scenarios

As part of the transition of build parsers from the "Autotests" module to the automation engine, a new routing node has been added. This node receives events related to builds that have been submitted to the system.

Users can create parsing scenarios for Allure builds on this routing node using the special function ParserAllure and generate signals for failed builds without the need for external scripts.

Screenshots of builds can be attached to signals using specific automation functions:

  • BindImageLinksToSignal - to attach an image link
  • UnbindImageLinksFromSignal - to detach an image link

# Metrics Sending Function

Now users can generate metrics and send them to a stream using the special function SendMetrics.

With this change, metrics can be generated from any logs at any stage of their processing within the system.

As metrics should include Unix timestamp, for convenient metric creation, the following functions have been added:

  • ConvertFromUnixTimeMilliseconds - the function converts from Unix format (milliseconds) to DateTimeOffset format
  • *onvertFromUnixTimeSeconds - the function converts from Unix format (seconds) to DateTimeOffset format
  • ConvertToUnixTimeMilliseconds - the function converts from DateTimeOffset to Unix format (milliseconds)
  • ConvertToUnixTimeSeconds - the function converts from DateTimeOffset to Unix format (seconds)

# Batch Functions for Working with Signals within Automation scenarios

  • CloseSignalsBatch - the function implements a request for batch closing of signals
  • CreateSignalsBatch - the function implements a request for batch creation of signals
  • UpdateSignalsBatch - the function implements a request for batch updating of signals
  • BindConfigItemsToSignalsBatch - the function implements a request for batch updating of signals, regarding binding to CIs
  • UnbindConfigItemsFromSignalsBatch - the function implements a request for batch updating of signals, regarding unbinding from CIs
  • BindTagsToSignalsBatch - the function implements a request for batch updating of signals, regarding binding tags to signals
  • UnbindTagsFromSignalsBatch - the function implements a request for batch updating of signals, regarding unbinding tags from signals

# Scenario Debugging Mode

A beta-version of the debugging mode for automation scenarios has been released. A scenario in this mode automatically records the incoming and outgoing parameters of Impure-functions to the log, greatly simplifying the debugging process.

# Global Functions

  • In Automation Settings, the addition of custom global functions is now available.
  • Userspace administrators can create functions in the form of scenarios, followed by compilation and publishing for access in all Userspace scenarios.
  • The concepts of "Compilation" and "Publication" have been introduced in the context of working with functions. A function is added to the canvas as a draft. After configuration, the user must compile it for validation and then publish it. Once published, the function will be accessible in all user scenarios.

# Scenarios Work Screen

  • Scenarios have transitioned to a tabular component, with the ability to sort and rearrange columns.
  • For scenarios, universal platform-wide tags can now be assigned, similar to how it's done with signals.
  • Filtering by most scenario parameters has been added:
    • Owner
    • Status
    • Type (routing node)
    • Tags
  • The ability to add scenarios to favorites has been introduced, with filtering and sorting options.
  • A change history for scenarios has been added, logging changes to core information, status changes, and scenarios structure.
  • Information about the date of the last launch and last modification has been included.
  • Indicators now show if a scenario is in debugging mode.

# Functions

  • A function for implementing full-fledged HTTP requests has been added, with the ability to specify various parameters.
  • A versatile FilterStruct function has been introduced, allowing flexible configuration of conditions in a single window without the need to add a large number of blocks to check property values of structures.
  • A "Notifications" library has been added with basic functions for sending messages via email and Telegram, as well as a function for sending images through Telegram.
  • A NewGuid function has been added, which generates a unique identifier upon request.
  • A function for linking any references to signals has been added.
  • Signal functions have been adapted for components.

# Threshold rules

In the settings of Threshold rules, an additional subsection for hash rule settings has been added.

Now users can specify keys in the rule settings that should not be considered when generating the hash for the threshold or, conversely, specify a list of keys by which the uniqueness of the metric will be determined.

# Zabbix Agent Plugin

The agent plugin for Zabbix has been upgraded to collaborate with the new version of Zabbix 6.4.