There are many different helpful articles and documents on the Symantec web site and some in the documentation which talk about how to monitor Enterprise Vault. In this article though, I'd like to present a different approach. I'd like to talk about the types of things to monitor rather than the detail of HOW to monitor the different components which make up an Enterprise Vault environment. Of course there are some fundamental things that we must cover, and we will, but there are also (I hope) some twists in the story.
Disk space is nearly always the first thing that people think about when it comes to monitoring any kind of system. Whether the Enterprise Vault server is running on local direct attached disk, network storage, a SAN, or a combination of all of those, monitoring the disk free space is essential. Running low on disk space will cause Enterprise Vault to shutdown - unless the Enterprise Vault Admin Service has been configured to not monitor disk free space (and I don't think that is a particularly good idea in most circumstances). Consider though the different types of disk usage that is needed for the Enterprise Vault environment:
- Temporary space for activities like conversion to HTML for indexing
- PST Temporary processing
- FSA Pass through recall
- Vault Cache builds
- Vault Store partition data
- Recalled CAB files and extraction from them
- Indexing data
- Windows and application updates
- PST Holding Folder
The list is actually quite long, and where each of these things is placed in terms of the environment and the system is important. Each of them also may have differ access characteristics, and some of them are only relevant if you are doing that type of activity (eg PST Migration, Vault Cache builds and so on)
It is very likely that out of hours when your Enterprise Vault environment is busy processing mailbox archiving requests that it will be a busy bee. During the normal working day it might be completely the opposite. You may have almost zero CPU activity during the day. But, it's worth monitoring these sort of things, and making sure that you are not pushing the maximum that you can get hold of for too long a period, and definitely not at times when you do not expect it to be happening. Things to consider which will drive CPU load are:
- Storage Expiry
- Create collections (and migrations)
- Vault Cache builds
- PST Import
- User retrievals of data
- Queries from external systems like (for example) Discovery Accelerator
If you find that your server is constantly 'busy' .. and by that I mean it has quite high CPU .. then you may be approaching a bottleneck in terms of the extra that you can get out of the system at hand. It used to be expensive to upgrade hardware to get more CPU's, but many people use Enterprise Vault in virtual environments now, so getting extra CPU's might be a case of being 'nice' to your virtual machine administrator!
Just like CPU usage another thing to watch for is memory usage. Using the page file is bad. Unlike CPU usage though memory usage does not always return to 'normal' once activities have been finished. Many processes on the Enterprise Vault server will 'keep' hold of memory, and only release it back through the Operating System when the Operating System requires it. This means that 'just' having high memory usage may not indicate a problem. Page file usage, or at least significant page file usage does indicate a problem though. Keep in mind the minimum and recommended requirements for Enterprise Vault, and if at all possible ensure that you have adequate memory for the processes that are being used in the environment. The latest Enterprise Vault 10.0.4 guides suggest:
Minimum 8 GB
Recommended 16 GB
Vault Store Partitions
The Vault Store partitions are key to the operation of Enterprise Vault, they are added to pretty much every time any kind of archiving takes place, and the only respite that they might get in terms of space usage is when storage expiry runs. The Vault Store partitions though don't just need to be monitored in terms of the space that they have left, they need to also be monitored to ensure that there are no significant disk queues during normal operations. Granted during the archiving runs, or the storage expiry runs *some* disk queues may form, but again you don't want them to be significant or for prolonged periods of time. Another thing to consider when it comes to partitions is the overall size. You should be able to easily back up the partitions which are active/open during a reasonable sized backup window. If you can't then you have to either invest in more technology to make your backups 'faster' (eg snapshots or similar) or you need to implement a strategy to close off partitions and create new ones regularly. Also consider for Vault Store partitions that the types of data access that are needed during the archiving window, versus the normal day to day flow of traffic from users and other processes is 'different', with the archiving activities being more a sustained push on to the disks. Take that sort of information in to account when you review and monitor the performance of the disks.
Just like the Vault Store partitions the Enterprise Vault Directory database, each Vault Store Group (aka Fingerprint) database, and each Vault Store database is likely to continue to grow day after day. Things like the Enterprise Vault Directory database may not grow overly quickly and is usually quite small when it comes to database sizes. The Vault Store database is likely to considerably though over time as it is where the information about each item in the system is stored, and the fingerprint information is stored in the corresponding Vault Store Group database. The performance of the SQL server is key to an Enterprise Vault system, and, is likely to be looked after by dedicated SQL Administrators in many organisations. [In many organisations there might also be dedicated storage administrators]. Whilst SQL may be a bit of a black box when it comes to your organisation it doesn't hurt to know some of the basics involved with SQL.
One of the crucial often forgotten about aspects of SQL is the maintenance plans. There is a good article which describes some very useful activities which need to be consider, so I won't repeat it all here. Take a look at:
The majority of Enterprise Vault customers are archiving Exchange servers, and with that comes the fact that doing the archiving will generate Exchange transaction logs. These need to be considered at all times, particularly when archiving is first introduced or policies are changed. In fact it might be that policies are changed 'slowly' over time so as to lessen the impact on the Exchange servers.
In any Enterprise Vault there is a long list of inter-related activities and options that should be monitored. In most deployments it is crucial to ensure that you have a complete (or as complete as possible) list of things that you are going to monitor before delving in and picking products or tools to actually perform the monitoring. Are there any other aspects of Enterprise Vault that you consider monitoring? Let me know in the comments below.