This is the second article in a multi-part series to guide you through your first weeks in Minion Enterprise. In Part 1 we covered the philosophy of environment monitoring, and how to register servers.
Today let’s start with how to configure error log search terms, and navigating ME.
Configure Error Log Search Terms
The Error Log Search module allows you to set up specific error log search terms in the dbo.ErrorLogSearch table. This module automatically gathers any search term matches, and logs them in the Collector.ErrorLog table for alerting or reporting.
For more information on error log searches, see Error Log Search Module.
IMPORTANT: SQL Server error logs are simply text files; they aren’t indexable. So, any search on an error log file must (by definition) search the entire file. It’s possible, then, that you could see some performance lag during error log searches if the SQL Server error log is extremely large. To minimize this effect, set up a nightly job to cycle the SQL Server error log on each instance, and configure SQL Server to retain 30 days of logs. This is good log management that we recommend in any case; it has the added benefit here of helping the performance of this process.
To set up an error log search, insert that search to the dbo.ErrorLogSearch table. From that time forward, search is now valid for all active, managed SQL Server instances (that don’t have an exception defined in dbo.ErrorLogSearchServerExceptions).
Take the example of an enterprise-wide search for corruption errors. DBCC CHECKDB detects corruption, and logs it in the SQL Server error logs in the form of Error 823 and Error 824. So we will define one search for 823, and one for 824:
-- Error log search: Error 823
INSERT INTO dbo.ErrorLogSearch
( LogNumber
, LogType
, Class
, Search1
, Search2
, BeginDate
, EndDate
, SortOrder
, IsActive
, Comment
)
VALUES ( 0 -- LogNumber
, 1 -- LogType
, 'Corruption' -- Class
, 'Error: 823' -- Search1
, NULL -- Search2
, NULL -- BeginDate
, NULL -- EndDate
, 'DESC' -- SortOrder
, 1 -- IsActive
, 'High priority: Standard corruption search for all servers.' -- Comment
);
-- Error log search: Error 824
INSERT INTO dbo.ErrorLogSearch
( LogNumber
, LogType
, Class
, Search1
, Search2
, BeginDate
, EndDate
, SortOrder
, IsActive
, Comment
)
VALUES ( 0 -- LogNumber
, 1 -- LogType
, 'Corruption' -- Class
, 'Error: 824' -- Search1
, NULL -- Search2
, NULL -- BeginDate
, NULL -- EndDate
, 'DESC' -- SortOrder
, 1 -- IsActive
, 'High priority: Standard corruption search for all servers.' -- Comment
);
Remember: from now on, ME will search all of your active SQL Server instances for these errors, and will log them in the Collector.ErrorLog table for alerting or reporting. But we have not set up an alert for this! You can make your own alert SP, or pull one down from the Community Zone!
Getting Around ME
The Architecture Overview article is an excellent place to start. But, to name a few salient points, we’ll tell you:
- How to get around in ME
- A bit about default values
- A couple of super important features
- What we think about your customizations
Getting Around
Minion Enterprise is made up of SQL Server stored procedures, tables, jobs, executables, and configuration (“config”) files. Almost everything you’ll touch is native SQL!
The Minion Enterprise repository groups database objects logically into schemas. Some of the most common schemas you’ll see are:
- Alert– The Alert schema includes alert-related stored procedures, and tables that control alert thresholds and deferments.
- Archive– The Archive schema includes tables and stored procedures related to Minion Enterprise’s self-cleanup. For example, the Archive.Config table determines how many days’ worth of data to keep for each of the tables in the Minion database. Be sure to look at the archival settings in this table to customize your data retention.
- Collector– Tables in the Collector schema hold collected data from managed instances. As you might suspect, Collector stored procedures play a part in the actual data collection.
- dbo– Data in the dbo schema tables tends to be more static than in other schemas – for example, the data in dbo.Servers will change as servers are added, removed, and upgraded, but the frequency of server changes is far less than data collections or alerts.
- History– Alert details are saved to tables in the History schema, before those alerts are emailed. For example, one row in the table History.Backups represents one detected missed backup. This allows you to (among other things) report on databases that have frequent trouble with backups.
- Setup – The Setup schema denotes stored procedures that allow you to set up various deferments, exceptions, and thresholds (e.g., Setup.DiskSpaceThreshold allows you to create or alter a disk space alert threshold). In the future this may expand to additional setup stored procedures.
Using this, and a touch of “sys.tables”, you can find pretty much anythink you’re looking for. “Where is the lastest job history collection? Oh yeah, Collector.SysJobHistoryCurrent…”)
On Defaults
Global Default – Any time you see InstanceID = 0 in Minion Enterprise, it represents a global default. So for example, you can set an alert exception for all servers, using InstanceID=0 in that alert’s exceptions table.
Instance Default – Any time you see DBName = MinionDefault, it represents a global default for all databases on the given InstanceID.
Global Database Default – You can also set an environment-wide default for a specific database, by using the database name along with InstanceID = 0.
Super Important Features
IsActive – Many tables have an IsActive column. This allows you to “turn off” that particular row, temporarily or permanently, without deleting the row.
Each managed server in Minion Enterprise must be assigned a Service Levels – a simple label for the level of the server’s importance. (You assign a service level to a server in the dbo.Servers table, ServiceLevel column.) By default, Minion Enterprise handles three specific service levels:
- Gold
- Silver
- Bronze
ME collects a lot of data, keeps it for a (configurable) amount of time, then deletes it.
Customizing – Do it!
MinionWare encourages you to create stored procedures and views as you find you need them. ME is meant to be customized.
We further recommend you create your own schemas to organize these custom objects. For example, if your company name is ABC, you might create the schemas ABCAlert and ABCReport.
As long as you do not modify existing Minion Enterprise objects, there should be no ill effects. And, Minion Enterprise upgrades will not remove or modify your custom objects and schemas.
Next time we’ll talk more about what you can do with Minion Enterprise. In the meantime, feel free to look around the online documentation!