My introduction to SCOM
OpsMgr is a very large and complicated program. It's best described as a framework. It's not a matter of installing it, deploying some agents, importing a few management packs and moving on to the next project; It's like an infant being left on your doorstep and you have to raise it up into a productive member of society.Our overall goal for OpsMgr is to handle some of the one-off tasks we can't accomplish with Cacti, not to replace or override Cacti. Cacti is our primary monitoring system. It's predates us using OpsMgr and has had 6+ years to grow into what it's doing today (which is a lot). Though we've had OpsMgr before (SCOM 2007), it was setup to handle some specific monitoring items that Cacti couldn't do. No monitoring system is plug-and-play so any product you get can do a lot with enough work. However, OpsMgr, being designed by Microsoft and part of their System Center suite of IT Management programs, can very deeply monitor the health and availability of other MS programs such as AD, Exchange, Sharepoint, etc. It basically allows us to pick up where basic SNMP monitoring leaves off.
OpsMgr is installed on a single management server. OpsMgr requires an OperationsManager database and OperationsManagerDataWarehouse database. Both reside on the same SQL server (The OperationsManager db is for short-term data (think a week) while the OperationsManagerDW db is for longer-term data (think a year) mainly for reporting and trending purposes. We're currently not very concerned about long-term data for reporting and trending purposes. At the time of install, the available features are Management Server, Reporting Server, Web Console and Operations Console. The Management Server and the Operations Console (it is exactly what it sounds to be) are the only features installed currently. (The Web Console could be added later should we want to see more information from OpsMgr and the Reporting Server feature could be enabled for other projects down the road). What we have currently is a fairly bare-bones installation.
OpsMgr has 3 service accounts associated with it according to Best Practices. A Data Access acct, an action acct (basically the account used for the SCOM agents) and an SQL service account.these are accounts you create.
OpsMgr supports both Agent and Agentless monitoring. Agent monitoring is generally easier on the management server as collection processes and tasks run on the target host rather than the management server. Agent monitoring is akin to “So $server, tell me about yourself.” while agentless monitoring is more like “$server, tell me about your friend. Is she single? What's the deal?” Agentless monitoring is primarily used for monitoring network devices rather than workstations or servers. Cacti is already monitoring network devices with pings or SNMP queries so we aren't using agentless monitoring in OpsMgr in our environment. However, should you want to know more about it in the future, you can read all about it here. After being added initially, you'll notice that the Health State of the new server(s) show as “Not Monitored” rather than “Healthy”. This is perfectly normal for up to an hour after adding the server. It's OpsMgr telling you “There's an agent out there but I haven't gotten any health information back from it yet”.
OpsMgr is best described as a framework rather than a simple application. After installation, you'll notice there's really nothing going on. You have to teach it what you want it to do. This is done with Management Packs. Remember the scene from The Matrix where Neo learns Kung Fu by getting all of that knowledge uploaded into his brain? Of course you do. OpsMgr Management Packs are effectively the same thing. Management Packs (MPs) consist of various monitors, rules, tasks, views, etc. MPs are also often written by Microsoft. For example, the team that engineers Sharepoint also wrote the MP for it. Other companies also make MPs for other products such as Veeam's MP for monitoring vSphere environments with OpsMgr.
Management Packs come in 2 different types; Sealed and Unsealed. An Unsealed MP means you can get in there and make changes. Don't want that monitor or don't like that rule? You can get in there and change it. A sealed MP means you can't directly get into the MP and start making changes. Changes to the behavior of sealed MPs are performed by creating Overrides, which are discussed later.
There's 2 general ways to obtain MPs; The most convenient way is to use the Operations Console itself. From the “Administration” section, you can download and/or import MPs and it's really pretty simple. (Using the Operations Console exclusively, you can download MPs without importing them or you can download and import them in one simple wizard.) You can also search Technet and download MPs manually and import them using the Operations Console. You're probably wondering why you'd want to use Technet to manually find and download the MPs when you can download and import them using OpsMgr's own wizard. The latter sounds much easier and faster, right? The reason it's actually better to download them manually from Technet is because you can also download the documentation specifically for the MP (written by MS since they also probably wrote the MP itself). The documentation will give you getting started instructions, explain what monitors and rules are in the MP, etc. Downloading and Importing directly with the Operations Console, while easier and way more convenient, leaves you flying blind of sorts.
As mentioned earlier, there are 2 kinds of MPs. Sealed and Unsealed. Examples of sealed MPs would be the majority of those available from Microsoft. Examples of unsealed MPs would be the MPs you make for a custom monitor. With an unsealed MP, you can get in there, root around, change things, etc. With a sealed MP, you cannot. The way to change the behavior of monitors and rules in sealed MPs are to create overrides. Overrides basically step in to tell OpsMgr “Look, I know what the Management Pack said but we're going to do it this way, kapeesh?”
You can start creating overrides in the Authoring section of the Operations Console by simply finding the monitor you wish to create overrides for, right-clicking, selecting “Overrides”, and then choosing what items you want the override applied to a group, objects of a specific class, specific objects of a class or objects of another class.
One of the awesome things about OpsMgr is that if you can't find a management pack to do something you need done, you can write your own. At a basic level, you don't need to write a whole management pack. If writing your own MP is akin to writing a cookbook, making a custom monitor is like writing a simple recipe. The first thing you'll want to figure out is what you want to accomplish with your custom monitor. Having a goal in mind will ultimately shape how you build your monitor.
OpsMgr is installed on a single management server. OpsMgr requires an OperationsManager database and OperationsManagerDataWarehouse database. Both reside on the same SQL server (The OperationsManager db is for short-term data (think a week) while the OperationsManagerDW db is for longer-term data (think a year) mainly for reporting and trending purposes. We're currently not very concerned about long-term data for reporting and trending purposes. At the time of install, the available features are Management Server, Reporting Server, Web Console and Operations Console. The Management Server and the Operations Console (it is exactly what it sounds to be) are the only features installed currently. (The Web Console could be added later should we want to see more information from OpsMgr and the Reporting Server feature could be enabled for other projects down the road). What we have currently is a fairly bare-bones installation.
OpsMgr has 3 service accounts associated with it according to Best Practices. A Data Access acct, an action acct (basically the account used for the SCOM agents) and an SQL service account.these are accounts you create.
Managing Agents
OpsMgr supports both Agent and Agentless monitoring. Agent monitoring is generally easier on the management server as collection processes and tasks run on the target host rather than the management server. Agent monitoring is akin to “So $server, tell me about yourself.” while agentless monitoring is more like “$server, tell me about your friend. Is she single? What's the deal?” Agentless monitoring is primarily used for monitoring network devices rather than workstations or servers. Cacti is already monitoring network devices with pings or SNMP queries so we aren't using agentless monitoring in OpsMgr in our environment. However, should you want to know more about it in the future, you can read all about it here. After being added initially, you'll notice that the Health State of the new server(s) show as “Not Monitored” rather than “Healthy”. This is perfectly normal for up to an hour after adding the server. It's OpsMgr telling you “There's an agent out there but I haven't gotten any health information back from it yet”.
Management Packs
OpsMgr is best described as a framework rather than a simple application. After installation, you'll notice there's really nothing going on. You have to teach it what you want it to do. This is done with Management Packs. Remember the scene from The Matrix where Neo learns Kung Fu by getting all of that knowledge uploaded into his brain? Of course you do. OpsMgr Management Packs are effectively the same thing. Management Packs (MPs) consist of various monitors, rules, tasks, views, etc. MPs are also often written by Microsoft. For example, the team that engineers Sharepoint also wrote the MP for it. Other companies also make MPs for other products such as Veeam's MP for monitoring vSphere environments with OpsMgr.
Management Packs come in 2 different types; Sealed and Unsealed. An Unsealed MP means you can get in there and make changes. Don't want that monitor or don't like that rule? You can get in there and change it. A sealed MP means you can't directly get into the MP and start making changes. Changes to the behavior of sealed MPs are performed by creating Overrides, which are discussed later.
There's 2 general ways to obtain MPs; The most convenient way is to use the Operations Console itself. From the “Administration” section, you can download and/or import MPs and it's really pretty simple. (Using the Operations Console exclusively, you can download MPs without importing them or you can download and import them in one simple wizard.) You can also search Technet and download MPs manually and import them using the Operations Console. You're probably wondering why you'd want to use Technet to manually find and download the MPs when you can download and import them using OpsMgr's own wizard. The latter sounds much easier and faster, right? The reason it's actually better to download them manually from Technet is because you can also download the documentation specifically for the MP (written by MS since they also probably wrote the MP itself). The documentation will give you getting started instructions, explain what monitors and rules are in the MP, etc. Downloading and Importing directly with the Operations Console, while easier and way more convenient, leaves you flying blind of sorts.
Creating Overrides
As mentioned earlier, there are 2 kinds of MPs. Sealed and Unsealed. Examples of sealed MPs would be the majority of those available from Microsoft. Examples of unsealed MPs would be the MPs you make for a custom monitor. With an unsealed MP, you can get in there, root around, change things, etc. With a sealed MP, you cannot. The way to change the behavior of monitors and rules in sealed MPs are to create overrides. Overrides basically step in to tell OpsMgr “Look, I know what the Management Pack said but we're going to do it this way, kapeesh?”
You can start creating overrides in the Authoring section of the Operations Console by simply finding the monitor you wish to create overrides for, right-clicking, selecting “Overrides”, and then choosing what items you want the override applied to a group, objects of a specific class, specific objects of a class or objects of another class.
Creating a Custom Monitor
One of the awesome things about OpsMgr is that if you can't find a management pack to do something you need done, you can write your own. At a basic level, you don't need to write a whole management pack. If writing your own MP is akin to writing a cookbook, making a custom monitor is like writing a simple recipe. The first thing you'll want to figure out is what you want to accomplish with your custom monitor. Having a goal in mind will ultimately shape how you build your monitor.
Comments
Post a Comment