Data Collection

Data Collection

OMFLOW is divided into Server and Collector. Collector can execute the process dispatched by Server for data collection to assist OMFLOW in data monitoring and analysis.

Collector management

Classification

Location: [Main Menu]>Data Collection>Collector Management
  1. Uncategorized: All Collector reporting for the first time will be classified here by default.

  2. Distributed Computing: When the process runs to the code component with "Distributed Computing" checked, one of the Collector in this category will be selected to run the code component. For details, please refer to the [Application Management > Code Component] chapter.

※ Whenever Collector is installed or restarted, it will report to the Server within 5 minutes.

Collector List

Location: [Main Menu]>Data Collection>Collector Management>[Any Category]

The Collector list of the current category is displayed here, and each field is introduced as follows:

  1. Light Signal: Green light means normal connection, red light means lost connection

  2. Name: Collector display name editable by administrators

  3. Host name: The hostname of the host where this Collector is located

  4. IP location: The ip of the host where this Collector is located

  5. Operating System: The operating system category of the host where this Collector is located

※ If the deleted Collector is still running and reporting to the host, it will appear in the list again.

Collector information

Location: [Main Menu] > Data Collection > Collector Management > [Any Category] > [Any Collector]

Basic information

Displays information related to the collector. The "IP location, PORT" fields can be changed according to the customer environment to ensure that the server can correctly connect to the collector.

Parameters

Collector system parameters can be set here, which is the same as the [Application Management > Parameter Management] chapter. When the collector process uses the system parameters function, the settings here will be referenced.

process

Here you can view the collection data related to all processes dispatched to the Collector, and you can also unassign individual processes.

Collector process

Location: [Main Menu]>Data Collection>Collector Process

All collector processes are displayed here, which can be sent to the Collector to perform billing operations regularly and send data back to the server. The following interface operations are introduced:

  1. New: Similar to [Application Management > Application Design], you can create any process and assign a collector to execute it. For the Event Billing tab, please refer to the next section.

  2. Delete: Delete the check process.

  3. Copy: Copy the selected process and create it as a new process.

  4. Dispatch: Specify the checked collector to perform this process.

  5. Execution: Set process execution variables, schedule, and execution Collector.

  6. Data: View the data collected during this process and display it in a line chart.

Important points to note:

  1. The collector process needs to be sent to the Collector before it can execute the schedule.

  2. The Collector returns the output data of the "End Component" to the Server at the end of the process. The data source is the output variable of the "End" component of the process. For related settings, please refer to the [Application Management > End Component] chapter.

Event billing

When the Collector returns data, you can set filtering rules here and upgrade it to an event when the rules are met.

※ The event-related fields can use the output variables of the "End" component of this process. For related settings, please refer to the [Application Management > End Component] chapter.

Extra Kits

When Collector is in an environment with an external network, it can install the necessary packages for the process by itself, without the need for users to install them manually. If there is no external network, there are two suggestions:

  1. If a private PIP Server is set up in the environment, please refer to the chapter [Setting up a PyPI server].

  2. You can also install it manually according to the collector process that the Collector needs to perform.

Collector API

Location: [Main Menu] > Data Collection > Collector API

Establish a collector-specific API so that external parties can directly call the process of the collector and transmit the output of the process end component back to the data center. Each call will only be executed once.

Important points to note:

  1. Due to security considerations, Collector only accepts API calls from itself and the data center by default. If you need to call from the outside, you must log in to the server where the Collector is located and add a trusted IP to httpd.conf under Apache.

  2. The API response content is the output variable of the "End" component of the delivery process. For related settings, please refer to the [Application Management > End Component] chapter.

Event management

Location: [Main Menu]>Data Collection>Event Management

All events will be managed here, and there are three tabs with the following functions:

Event List

Displays all events, where Source Category events are divided into the following four types:

  1. Data Collection: Events triggered by the event rules of the collector process will automatically close when the event conditions are not met.

  2. Service Level: Triggered by the Service Level rule of application management. For details, please refer to the [Application Management > Service Level] chapter. It will automatically close when the conditions are not met or the form has been closed.

  3. Periodic check: Triggered when the connection between Collector and Server is interrupted, and automatically closed when the connection is restored.

  4. API: generated when the external system calls through the API. It also needs to be closed through the API. For details, please refer to the [Accident API] chapter below.

Accident Rules

Location: [Main Menu] > Data Collection > Incident Management > Incident Rules

When an incident occurs, the system will check whether the incident rules are complied with and generate an incident ticket. Most of the fields are basic fields of the accident ticket, among which the accident triggering conditions need to meet the following two conditions at the same time to be established:

  1. Time Match: An event is generated when this rule reaches the specified number of matches within the specified time range. For example, if it matches 3 times in 1 day, if it is blank, an incident ticket will be generated every time it matches any one time.

  2. Field conditions: When all specified fields are judged to be true, they are deemed to be met.

Notes:

  1. The event will check the incident rules from top to bottom, and will stop once it escalates to an incident.

  2. When the same incident has been upgraded to an incident, no new incident ticket will be generated.

Incident API

Location: [Main Menu] > Data Collection > Incident Management > Incident API

Provides an API for external systems to open events for OMFLOW. Due to information security considerations, Collector only accepts API calls from itself and the data center by default. If you need to call from the outside, you must log in to the server where the Collector is located and add a trusted IP to httpd.conf under Apache.

Last updated