Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The following discusses any enrichment opportunities of the audit validation/violation data being pushed to elasticsearch. Most jobs could be done in the data-router micro-service code instead of using logstash.

Notice that the two boxes below are the demonstrating a sample validation and violation events event currently stored in ES that , which will be the data source for the Kibana dashboards.

  • The violation event need to add more fields from the field "violations" available in the validation info including: modelName, errorMessage, violationDetails
  • The field violationDetails (which would tell the exact discrepancies; see the sample event below inside the '?violations') need to be parsed and stored in separate fields. Such nested data cannot be directly used in the kibana visualizations (? mark indicates it).
  • We could further parse out the ONAP components involved with the violations to see the violation stats factored by component (from violationDetails)"Elapsed time after orchestration" would be useful? Could the audit result change over time for the same audit requests at different times since orchestration?
  • "Audit duration" stats would be useful? time taken for the auditing itself (from trigger to result).
  • Any other meta-data that would be useful? e.g., who invoked the validation (user, dept) 

...