Technologies configuration
Introduction
In the context of Service Operations, a technology consists of a data source, understood as an internal data structure or table, alongside a number of metadata records and links to other resources in the platform. For example, a technology database would include in its definition the main entry point of its data when ingested in Devo (my.app.database.mydatabase, for example) and linkages with existing models or Activeboards, and links to internal or external resources such as information repositories. Technologies are logical groupings of different assets that share a common data source in the platform.
Similar to the case of maps, Devo provides off-the-shelf technologies support with Service Operations, leaving end-users of the application with the possibility to create their own ones.
The existence of a technology is not a pre-requisite to create a map in Service Operations that makes use of the associated data structure.
Available technologies
To list all available technologies in a Service Operations instance, access the administration section in the application by clicking on the cogwheel icon on the upper-right side of the user interface. Once in there, click on Technologies > Supported technologies on the left menu.
This section does not allow the creation or modification of existing technologies. However, it allows users to list, access related documentation, or open the raw data structure in the Devo core platform. Using the filter icon above on the left of the technologies list, it is possible to filter technologies by category or publisher for quick access. Above on the right, it is possible to filter by name.
Creating / editing technologies
To list all available technologies in a Service Operations instance, access the administration section in the application by clicking on the cogwheel icon on the upper-right side of the user interface. Once in there, click on Technologies > Supported technologies on the left menu.
Clicking on the Create new technology button will display the technologies creation and editing form:
Parameter | Description | Value type | Example |
---|---|---|---|
Technology name | Reference name for the technology. | Text string | XYZ database |
Technology logo | URL to the image file (.png, .jpg, .gif) used as logo for the technology. | Text string | https://cdn.pixabay.com/photo/2016/08/25/07/30/red-1618916_1280.png |
Publisher | Person, organization or company that created the technology. | Text string | Devo |
Category | Type, area or purpose of the technology. | Selectable or new text string | Cloud |
Subcategory | Subtype, area or purpose of technology. | Selectable or new text string | Performance metrics |
Main data structure | Data table that holds the information related to the technology. | Devo data structure identifier | my.app.databasexyz.metrics |
Data sample file | Synthetic datasets uploaded as events files, to be used as inputs for the synthetic data injector. Multiple can be added using ‘+' icon and delete with '-’ icon. |  Uploaded file )max 20MB) | databasexyz_performance_metrics.log |
List of associated maps | List of maps that utilize or rely on the technology in its definition, or show information related to it | Â Multiple selectable map name | Databases health |
List of associated Activeboards | Activeboards that utilize or rely on the technology, or show information related to it. Multiple can be added using '+' icon and deleted with '-' icon. | Name, URL text strings | Databases status - https://devo.com/39393993 |
Setup documentation URL | Link to internal or external documentation related to the configuration of the technology as a data source (collectors page, for example). | Text string | https://docs.devo.com/space/latest/94659363/List+of+Devo+parsers |
Reference and troubleshooting guidelines URL | Link to internal or external documentation sites related to the technology itself: official manuals, administration guides, and so on. | Text string |
Data sample file structure
Uploaded data sample files must comply with the following specification per line in the file. Each line will be treated as a single event:
An example of a valid data sample file would be the following:
1598227200000 GR-1,cluster0001,node0001,svm0001,vol0001,agg0001,disk03rn97cn,eth0001.1,9.1,7.7,6.5,87,3910,8,51,US,CA,Pasadena
1598227201000 GR-2,cluster0002,node0002,svm0002,vol0002,agg0002,diskiktcz5uc,eth0001.2,9.1,3,3.3,48,4664,8,30,US,UT,Salt Lake City
1598227202000 GR-3,cluster0003,node0003,svm0003,vol0003,agg0003,diskjczmhxhx,eth0001.3,9.1,2.2,4.9,51,5574,12,45,US,TX,El Paso
1598227203000 GR-4,cluster0004,node0004,svm0004,vol0004,agg0004,diskxbhe4w45,eth0001.4,9.1,9.5,8.2,80,9934,5,58,US,VT,Montpelier
1598227204000 GR-1,cluster0005,node0005,svm0005,vol0005,agg0005,disklgzph91g,eth0001.5,9.1,7.9,1.4,35,6909,15,31,US,PA,Mc Keesport
The synthetic data injection engine does not pay attention to the exact timestamp to perform the data ingestion operation at that specific time. Instead, the timestamp is used as a reference to set the cadence of events between them. As an example, if the previous file was utilized as source data for a job, the result would be the following:
The job would ingest the first event in the file (line #1) immediately, that is to say, ignoring the timestamp.
The second event would be ingested after 1000 milliseconds, which is the difference between the second and the first timestamp (1000 milliseconds).
The third and following events would be processed in exactly the same way, that is, introducing a delay between them which is the delta of milliseconds between their respective timestamps.
Once the last line of the file is processed, the job would stop if its type is "once", or it would continue ingesting again the first event in the file.
Make sure the sample data file is encoded as UTF-8
Injecting synthetic data
Service Operations implements a built-in data injector server that allows end-users to create their own real-time data injection processes.
The data injector utilizes the definition of the entry technology entry point (internal data table) and the uploaded sample files to initiate back-end jobs in charge of sending the data contained in the sample files to the targeted table. This way, two objectives can be met:
Simulate the ingestion of the technology data into Devo so that the defined models can utilize it as baseline information to populate them.
Simulate the ingestion of the technology data for other purposes across the entire Devo platform (to feed Activeboards, for example).
Simulate specific scenarios (service errors, for example) by injecting raw data that contains the conditions to generate them.
Access the data injector by selecting Synthetic data injector on the left menu. The following UI will be shown:
To start a new injection job, follow the next steps:
Click on the start new job button corresponding to the technology whose data you want to be ingested into Devo.
Choose from the available data sample files the one you want to use as the source.
Select the ingestion mode: "continuous" for cyclic ingestion—the content of the file will be ingested recurrently from beginning to end—, or "once" for a one-time pass to the same file.
Click on apply.
The new job will be displayed in the upper list of active jobs, along with its status. "Continuous"Â jobs are meant to remain in running status until they are stopped manually. "Once"-typed ones will, on their side, eventually reach stopped status as soon as they finish processing the sample file and ingesting it into the targeted data structure.
Deleting technologies
Click on the corresponding button under the manage technologies section.
All associated resources (sample files) will be deleted as well. As a result, active injection jobs will be stopped.
Â