Grooming is optimization feature intended to limit number and storage terms of events and performance counters in AVIcode DBs. Having read this article you will learn how to configure grooming for both SEViewer and Advisor. Having configured AVIcode monitoring you will instantly find SEViewer and Advisor DBs being populated with data. Great! But what will happen in a week? In a month? In a year? Will it just keep growing till it breaks? AVIcode is designed for the harsh realities of the everyday production environments, where the amount of data is significantly high, the load rates are constantly growing and, as a result, your events are piling up in the database. Therefore it is taking care of cleaning up the monitoring data to keep the most recent and relevant information at your fingertips, while gently brushing away the old stuff you probably don’t need. This process is called “database grooming”. You may come across with the effects of the database grooming in several cases. Here are some typical scenarios:

• • you tried generating an Advisor report for some specific date and got no data. You are sure that the monitoring was on, there was no issues, data was rolled up into Advisor and you recall having run the same report for the same interval previously, and it worked just fine;
  • you click on an event in SEViewer and find no stack available, and the window says that event has been “groomed”.

Grooming is optimization feature applied to SEViewer and Advisor DBs and imposing the limits on events and performance counters being stored in databases. It’s useful for keeping the database size reasonable and performing well. As you may guess, there are two types of grooming:

• • one applied on SEViewer database (or SEViewer tables in SCOM2012) and is based on number of events and performance counters,
  • the other is done on Advisor database and is based on events and counters storage terms.

SEViewer grooming SEViewer grooming settings are configured through Web Application UI by opening “Tools”->”Options..” and navigating to “Data” tab then: Let’s take a look at all these options: Keep the N most recent events in the database – this option defines maximum number of events in SEViewer DB. When the limit is reached, and new events are constantly collected, the oldest events will be deleted from database in order to store new events. Keep the N most recent events in an event group – another grooming option determining the number of stored event of each event group. You can see event groups in the UI when you group by problem. Events of the same event group have the same problem and matching stack. Keep details for the N most recent events in an event group – grooming option defining the number of events in each event group for which details will be stored (the details are the view opening while you click on event. Coming back to the last scenario described above actually this option was triggered in the case). If you open event with groomed details you’ll be notified with appropriate message. Delete event groups older than N months – if for specified time no events of some event group have been received, the corresponding event group (as well as all related existing events) information will be deleted. Delete events with a ‘Deleted’ status for more than N hours – if using “Problem Management” functionality, you can set status for some events based on defined conditions. For example, you collected event, but the root problem is already resolved, thus you may mark the event as ‘Deleted’. ‘Deleted’ events are only stored in database for 24 hours and will be cleaned up after. Delete events with a ‘By Design’ status for more than N hours – similar to event marked with ‘Deleted’ status. When event is considered to be a by design behavior you may mark it with this status – and such events will be stored for 72 hours. Besides grooming is also applied on number of performance counters stored in DB, but this setting is configured through “SEViewer.config” rather than UI: Advisor grooming Unlike SEViewer grooming based on numbers, Advisor one is imposed on storage terms. If storage limit is reached for the events and/or performance counters appropriate data will be cleaned. Advisor grooming is configured only through “SEViewer.config”: Note:

<add value="91" table="Event" /> - 91 days is the storage term for Advisor events.

<add value="91" table="PerfHourly" /> - 91 days - for Advisor hourly aggregated 
performance counters

<add value="182" table="PerfDaily" /> - 182 days - for Advisor daily aggregated performance counters which are not used by reports.

That was everything concerning AVIcode 5.7. APM in SCOM 2012 has some difference dealing with Advisor grooming. Instead of specifying grooming in “SEViewer.config” (which doesn’t exist anymore) now there is a rule called “Operations Manager APM Data Transfer Rule” targeted to the “Operations Manager APM Data Transfer Service” object. By overriding the rule settings you can configure the grooming for events and hourly aggregated performance counters. Daily aggregated counters are hardcoded with default value equals to 182 days. Now you know everything there is about configuring the grooming. Well-configured grooming becomes your friend and helps keeping your database optimized, and your monitoring solution performing well. Regards!