You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

LOG-395 - Getting issue details... STATUS

1. Upgrade of ELK & Potential Feature Development (AAI search-data-service)

ELK Upgrade

  • Current ELK versions: elasticsearch 2.4, kibana 4.6  (no logstash is being used) 
  • To better create the dashboards with enhanced features and look, upgrading to version 5.6 is desired. (note: Logging project is using 5.5) 
  • Upgrade from 2.x to 5.x needs "Full Cluster-restart Upgrade". 

Feature Enhancements

  •  Any change of the validation/violation data being pushed to elasticsearch? 
  • violationDetails (what is really different) need to be parsed (using logstash) or sent/stored by search-service? Kibana cannot use the nested info in the visualizations.
  • Any other meta-data useful? e.g., who (user, dept) invoked the validation


  (Note) Below are the current validation and violation events stored in ES


                    


2. Dashboard Ideas

The visualizations and dashboards will need to be designed and created according to the current and any potential use cases of the POMBA services - what the users want/need to check, how the system could help improve the whole platform integrity. We want the POMBA reporting to be informative, insightful, and intuitive from the user's perspective. 

Challenges

  • We have created a few sample validation rules but do not know all the rules to be created by the users in the production. That means most likely we can create and provide some high-level dashboards - for the specific rules and details, we could only provide some sample dashboards to give an idea so that how the end users could create their own dashboards customized for their use cases. 
  • For the Network Discovery, what specific audits will be executed and what kinds of audit results are expected 


Dashboard List


Dashboard TypeDescription (What To Want to See)Required Information To Show (Visualizations)
1Audit OverviewAs a general admin, want to see the whole platform integrity
  • validation total count (for the specified time period)
  • violation total count (for the specified time period)
  • validation count over time (trend)
  • violation count over time (trend)
  • violation count by rule type
  • violation count by rule severity
  • KPI trend: daily violation percentage against validation count (weighted metric considering the severity level)
2Audit AnalysisGiven a validation job, the user wants to see all related violations found by POMBA
  • validation details and relevant violation details on the same page
  • (stretch) given the same type of validation job, can we retrieve some historical violation results to give an idea if this is really unusual case or it used to happen?
3


4Violation Analysiswhat kind of violations mostly occur
  • violation stats by validation type
  • violation stats by validation rule
5Violation Analysis for Network Discovery


Supportable Features

  • Provide links to move back and forth across the dashboards: e.g., from the violation page to the page displaying its validation info


3. Data Generation based on Audit Use Cases

Generally two approaches to execute the audits and generate audit results:

  • Event-Driven Auditing: e.g., Post-orchestration audit trigger by system or user with a specific service instance
  • Continuous or Scheduled Auditing: targeting a pre-configured set of service instances (existing and/or new). It could be against all the deployed artifacts. 

Configurations 

  • Audit targets selection: which microservices should be included and cross-checked
  • Audit rules selection: which rules should be validated for the target services
  • Scheduling parameters: when, which rules will be applied


Audit Use Cases






  • No labels