Argo Rollouts analysis with ISD and Elasticsearch
Last updated
Last updated
This document explains the end-to-end flow for the analysis run with the Elasticsearch data source.
Follow the steps below for the end-to-end workflow for the analysis run and to get an analysis report.
Note: You must add all the integrations through ISD UI only.
To add an Elasticsearch integration as your data source to allow ISD to perform your log analysis, follow the steps given below:
From the ISD dashboard, click "Setup" and click "Integrations" and then Click "+New Integration" button as shown in the image below:
The list of available integrators and their respective fields appears. Select the Elasticsearch integration and fill out the information about it that appears on the right pane of the screen.
Update the following information on the above screen:
Account Name: Name of the Elasticsearch account to operate on
Elastic End Point: End of the Elasticsearch URL for the account to operate on
User Name: Provider the user name for the ElasticSearch instance
Password: Provider the password for the ElasticSearch instance
Kibana End Point(Optional): Endpoint URL for the Kibana instance
Kibana User Name(Optional): Provide the username for the Kibana instance
Kibana Password(Optional): Provide the password for the Kibana instance
Permissions: To restrict permissions to this account, you can select the User Groups.
Once you have updated all the information, click "Save" and the newly created Elasticsearch integrator appears as shown below:
Create a log template after adding the Elasticsearch integrator.
We support the following two modes of template creation
Gitops mode template creation
Template creation in ISD UI
You can create a log template in a GitHub repository where your deployment manifest files are saved. The sample Log Template for Elasticsearch data source is available here.
OpsMx provides the two types of sample log Templates for Elasticsearch as follows:
Minimal yaml file (elasticsearch-log-generic-minimal.yaml)
Extended yaml file (elasticsearch-log-generic-extended.yaml)
Minimal yaml file:
The following sample Elasticsearch minimal yaml file contains the mandatory parameters to create a log template. You can use this sample yaml file instead of creating a new template.
Parameters details are as follows:
name: Give a name to the Log Template (This Log Template name, must be used in OpsMx Provider configmap file ).
monitoringProvider: Provide the name of “ELASTICSEARCH”.
accountName: Log provider account name (Must be provided the same account name, which you have given while adding the Elasticsearch integrator in ISD UI)
index: Index containing logs for processing
filterKey: Unique Key which identifies logs to be processed in the index
responseKeywords: Field name in the index containing logs to be processed.
Extended yaml file:
The following sample Elasticsearch extended yaml file contains all the available parameters even non-mandatory to create a log template. You can use this sample yaml file instead of creating a new template.
Parameters details are as follows:
name: Give a name to the Log Template (This Log Template name, must be used in OpsMx Provider configmap file ).
monitoringProvider: Provide the name of “ELASTICSEARCH”.
accountName: Log provider account name (Must be provided the same account name, which you have given while adding the Elasticsearch integrator in ISD UI)
index: Index containing logs for processing
filterKey: Unique Key which identifies logs to be processed in the index
responseKeywords: The element in Elasticsearch record referring to the actual log line. e.g. log, message, etc.
errorTopics: Error Topics can be defined to filter the attached errorString to categorize the logs carrying it into a severity level. The definition of an errorTopic contains a combination of errorString and severity to associate with it. errorTopics can have 4 severity levels: CRITICAL, ERROR, WARN and INFO
tags: Tags are used for future reference of an issue captured during analysis. An error string (as configured) when found in a log cluster, the cluster gets tagged and comments can be associated with the tag for future reference.
You can create a log Template on the Setup → Analysis Templates page in ISD UI. To create a log template in ISD UI, follow the steps below:
From the application dashboard, click "Setup" and click “Analysis Templates” and then click "+New Template" button. Refer to the image below.
After clicking “+New Template” button, two options appear for you to choose the type of template you want to create. Select the “Log Template” from the available options as shown in the below image.
The New Log Template window appears and it has three sections to update the necessary parameters as shown below:
Log Provider: Select the data source for analysis and provide relevant parameters
Log Topics: Strings that appear in logs with their characterization
Log Tags: Create custom tags based on business logic.
Select the data source for analysis and update the relevant parameters as per the below instructions.
Log Template Name: Provide a unique name to the Log Template in the text box.
Provider: Select the data source from the Provider drop-down. Based on the selection there will be new options added. In this section, we have selected Elastic Search as an example. Once selected, the new options appear as shown in the image below:
Log Account: Select the Account of the Log provider from the “Log Account” drop-down. Refer Integrations tab under Setup for Log Account.
Index Pattern: Index containing logs for processing.
Query Filter Key: Unique Key which identifies logs to be processed in the index
Response Keywords: Field name in the index containing logs to be processed
Timestamp Key (Optional): Unique Key which identifies the timestamp for the log. By default, it is the timestamp for ElasticSearch and Graylog.
Turn on/off toggle button:
Custom Regex: Custom Regular Expression to filter the logs.
Autobaseline: ML based learning of the baseline from historic analysis.
Contextual Cluster: Enable/disable cluster of unexpected events in similar context.
Info Cluster Scoring: Enabling this option will include INFO clusters in scoring.
Sensitivity: Select the Level of Sensitivity from the drop-down. Sensitivity means the importance of warning or error. For example - If the sensitivity is high any error or warning will be considered as highly sensitive and the penalty in the final risk score will be more. If medium or low, the penalty in the risk score will be moderate or low respectively.
Scoring Algorithm: Click the Scoring Algorithm drop-down and select the type of algorithm and the options are:
Click Next to update the Log Topics section.
The Log Topics screen is where the intelligence is provided to the application. Here we have listed some of the most common errors in the industry and categorized them as Critical, Error, Warn and Ignore. The categorization has been done based on industry standards. For example - OutofMemoryError is a show stopper. We have also provided the option for you to change the category based on your requirements.
After updating the Log template section with the necessary parameters, the Log Topics screen appears as shown below:
In the above screen you can do the following:
Click the Characterization Topic drop-down to change the category of the error. So for example, you can set the OnOutOfMemoryError to WARN from CRITICAL. Refer to the image below:
Click the Delete icon to delete a string pattern as shown below:
Click the “+” icon to add a new log topic and a new row will be added. Update the string and set the category as you want and then click “Next” as shown below:
After you click Next, the Log Tags screen appears. As a user, you might want to give some business logic-related input to the analysis. The Log tags help you to do the same. In this screen, you can add the cluster tags. Issues like Infrastructure, build error, etc. you can pre-define in this screen. Refer to the image below:
To add a cluster tag, follow the steps below:
From the “LogTags” screen, click on the “+New Cluster Tag” button as shown below.
Enter the Cluster Tag string and give a name to the Cluster Tag. Refer to the image below:
Click “+New” button to add a new row of Cluster Tag and enter the Cluster Tag string and give a name to the Cluster Tag. In the same way you can create multiple Cluster Tags. Refer to the image below.
After adding the Cluster Tag click the “Submit” button. Refer to the image below.
After creating Log Template, it appears in the list for an application on the “Analysis Templates” page as shown below:
To create an application, refer here. This application must be specified in the “OpsMx Provider Configmap”.
Create “OpsMx Provider Configmap” with opsmx metric provider information, including “log template name” and “application name”. Sample “OpsMx Provider Configmap” yaml file is available here. To create “OpsMx Provider Configmap” refer here.
Note: The user is given the flexibility to create metric and log templates in ISD and also, to maintain them as config maps via GitOps.
In the “OpsMx Provider Configmap”, If gitops is set to “true”, the metric provider prioritizes the presence of log template as config map, and if not found, tries to load it from ISD.
In the “OpsMx Provider Configmap”, If gitops is set to “false”, the provider only loads the log template from ISD.
Note: If you want to load the log template from ISD, do not specify the following parameters in the “Analysis template”.
Note: Must be provided the same Log Template name in OpsMx Provider Configmap, which you specified in the Minimal yaml file\ Extended yaml file\ ISD UI.
Specify the “OpsMx Provider Configmap” under the job section in the Analysis template. Sample "Analysis Template" is available here. To create an Analysis Template, refer here.
Modify the rollout.yaml with the image and include the analysis step by specifying the Analysis template that you have already created as shown below. Sample rollout.yaml is available here.
To deploy the application, refer here.
Note: Please make sure all the above configuration files are stored in the folder where the rollout.yaml manifest file is stored.
If a newer version of the application is deployed, the Rollouts strategy will be invoked and an analysis run will be triggered. Update the image version in rollout.yaml as shown below and sync the application to trigger the analysis run. To sync the application, refer here.
Note: For the first version of application deployment, Rollout strategy is not invoked. The Rollout strategy is followed only when a newer version of the application is deployed.
To view the Analysis report from Rollouts Dashboard, refer here.
