Monitoring multiple apps on same server
Hi All,
We have a customer with converged infrastructure where multiple applications are hosted on one server.
This means, auto-learning mechanism will report popular operations (busy apps) and put the rest (quiet apps) into one All Other bucket.
This means, we cannot define applications in BU as CAS does not see quiet operations.
To get around this problem, we have manually defined regex and static URL's to capture operations we want to report and turned off the auto-learning mechanism.
Recently we found out that manually captured URL's are not aged out by URLAging mechanism leaving a big server cache and DB that eventually (1 year) ages out.
Has anyone come across a similar situation? How did you solve this issue?
That is by design
In general to help you with server cache you could try to set per-SS URL Learning parameters instead of using regexes but if you're adding then any of these URLs to BUs they won't be aged out.
With one exception: if you have many BU definitions set with masks you can add and set _VAS_URL_AGING_CHECK_MASK_ property to 1 on http://<YOUR_CAS>/DiagConsole#/advancedprops page to start aging URLs that are in BUs, but defined using masks.
For "full URLs" added to BUs there is no way to age them.
Ok, so I can age them out if I use asterisk - that is good to know.
As per software service per server - that is the issue we have. We have the same server and port serving multiple applications. So defining software service at server level will only include top URL's of top apps while all quite application url's end up in one All Other box.
Yeap, this might be problem ...
You could also try to add more memory to CAS and extend server cache size or move some other SSes to another CAS to make room in server cache ...
Yep we did that, one of the CAS's have 256GB of RAM with 600K server cache. Memory is currenlty hovering around 50GB, our issue is the ever expanding DB that does not age out its URL's.
We are currently monitoring 20+ apps on that CAS, plan is to monitor 300+ apps in the coming months, so coming up with a solution for this is vital, we have other DCRUM customers who are moving in this direction too.
If the problem is in short DB then I have not other advice than bigger HD or shorter STORAGE_PERIOD ...
Ok, so this needs to be an RFE. I will wait for the developers response before creating an RFE for this.
