AAI Performance Target to Support Holmes Alarm Processing

Owned by Keong Lim
Apr 17, 2019
3 min read

References

Discussion

@Guangrong Fu mentioned AAI in Baseline Measurements based on Testing Results:

  1. Cache the AAI data and refresh them periodically so that Holmes won't have to make an HTTP call to AAI every time it tries to correlate one alarm to another.



The problem for caching is how to know when to update the cached data. Even though the access time may be fast for Holmes, the risk is using out-of-date data, so the correlations will be wrong anyway. Also, duplicating the AAI data outside of AAI is probably a bad architectural decision. Making AAI faster for these use cases would be better.

Has there been a performance analysis of where the time is spent? Could it help to use ElasticSearch (e.g. as in sparky)? Should Holmes have a batch interface to get more AAI data in fewer calls? Or a better correlation API that results in fewer calls?

31st Oct: https://lists.onap.org/g/onap-discuss/topic/27805753

1st Nov:

  • @Guangrong Fu will try custom queries for queries that took to long to return

  • The hardware (mainly storage) influences the query speed - need to find out what hardware was the speed test conducted on (@Guangrong Fu will provide HW specs)

  • HOLMES-186: Improve the performance on AAI queries.Open

Would the AAI Cacher AAI-1337: AAI CacherClosed help to improve performance?

5th Mar: Guangrong Fu

Hi,

Sorry for my late response. It took me a long time to set up AAI in my own env. For Item 10, here's some information:

Main APIs invoked in Holmes for different use cases:

VoLTE

  • Getting the VM query URL via: /search/nodes-query?search-node-type