Jaa

More with Alert and State Change Insertion

  • Artikkeli

Update: I have updated the management pack to work with the final RTM bits 

Update #2: You cannot use the aggregate method described below to set the state of any instance not hosted on the Root Management Server.

The last thing I had wanted to demonstrate about alert and state change insertion finally became resolved. This will not work in any of the public bits right now, but RC1 should be available soon and it will work there. Attached is the most recent version of the management pack to reference for this post. You'll have to clean up the references to match the proper public keys, but it should work otherwise.

What I wanted to demonstrate was being able to define a monitor for a given class, but not having that monitor actually be instantiated for every instance of that class. Normally, if you define a monitor, you will get an instance of it (think a new workflow on your server) for every instance of the class the monitor is targeted to that is discovered. If you have thousands of instances, this can lead to significant performance issues. Now, we support the ability to define an aggregate monitor that will not be instantiated, as long as there are not monitors that roll up to it. In the sample MP attached you will find System.Connectors.SpecialAggregate that is an example of this kind of monitor. It works like any other aggregate monitor in the system, it just doesn't actually have any other monitors from which to roll up state. So how does its state gets set? That's where the additional changes come in.

The first new addition is System.Connectors.Health.SetStateAction. The is the most basic form of a module that will be used to set the state of the aforementioned monitor. It this form, it accepts as configuration the ManagementGroupId, MonitorId (this is the monitor you want to set the state of), ManagedEntityId (this is the id of the instance you want to set the state of the monitor for) and the HealthState (this is the actual state you want to set the monitor to). There is a wrapper that abstracts away the need to set the ManagedEntityId and ManagementGroupId properties called System.Connectors.Health.TargetSetStateAction that will work with the SDK data types. There are also three further wrappers that explicitly define the state to set to monitor to, leaving only the MonitorId as configuration.

I have included a sample rule (System.Connectors.SpecialAggregate.Error) that will drive the state of the aggregate monitor using the same sample code I posted earlier. Note that the rule is targeted to RootManagementServer since it will process data for a variety of instances, while the aggregate monitor should be targeted at the proper class that represents the instance you want to model and drive state for.

System.Connectors.Library.Test.xml

Comments

  • Anonymous
    February 12, 2007
    One question, After user closed all the error alerts(on one object) manually, I want to make the state of the object to Healthy. How to make it? Thanks

  • Anonymous
    February 13, 2007
    If you go find the object you want to reset the state for, you can right click on it and go to the health explorer for it (Open -> Health Explorer for...). Next, on the root node (or any monitor in the hierarchy) you should be able to right click and reset state. Note that this will not reset the state of a monitor that goes red and green on its own based on events.

  • Anonymous
    February 13, 2007
    I remembered that if user solved all critical alerts of one object, the state of the object will be set to healthy automatically in MOM 2005. It's not the same scenario in SCOM 2007. Am I right?

  • Anonymous
    February 14, 2007
    Yes, you are correct. That is how things worked in MOM 2005. In 2005 state was driven by alerts, whereas in SCOM 2007 alerts are driven by state; hence, resolving an alert will not reset the state.

  • Anonymous
    May 21, 2007
    Hello, I'm using the special aggregate monitor since I have thousands of instances to monitor. There is a way to enable the manual reset health status for these aggregate monitors?

  • Anonymous
    May 21, 2007
    I believe this question was answered in the newsgroups. I do not believe it is possible; we have a developer investigating whether it would be possible through some rule.

  • Anonymous
    May 22, 2007
    I posted reply to newsgroup including updated version of management pack to use with your scenario.

  • Anonymous
    June 21, 2007
    I have a question: when I insert a RedEvent to an agentless computer , the computer state had changed to Critical. But when inserted RedEvent to an computer which had installed the agent, the state can not change. Is this right? We can't change the state of an agent computer?

  • Anonymous
    June 22, 2007
    Whether the state changes is a function of whether the monitor is targetted to the proper type (i.e. the type of the instance you are trying to change state for) and if the rule is running that sets the state of that monitor. Outside of that, it doesn't matter what the instance is.

  • Anonymous
    June 24, 2007
    I used the type Target="System!System.Computer",it should means all the computers, isn't it?

  • Anonymous
    June 24, 2007
    Does the System.Computer cannot contain the computer which is agentmanaged?

  • Anonymous
    June 24, 2007
    oh, I saw the types of the Managed Objects, System Center Managed Compter (Server OS) , then what Target I should write into MP?

  • Anonymous
    June 24, 2007
    The comment has been removed

  • Anonymous
    June 24, 2007
    I don't understand it clearly,can you give me a sample mp to change the state of an agent managed computer?

  • Anonymous
    June 25, 2007
    This blog post has an example of this (kind of). Since the agent don't have db access, you need to manage their state from somewhere that does. Take a look at the SpecialAggregate in this example and the corresponding rule that sets its state. This will work for agent-managed computers; you can special aggregate to computer for instance, then use the rule targeted to the Root Management Server to set its state.

  • Anonymous
    June 25, 2007
    Thanks JakubOleksy, but already not useful. I have used the mp you post and have a little changed. Add some rules <!-- RULE TO SET AGGEGATE TO ERROR -->      <Rule ID="System.Connectors.SpecialAggreate.Error" Enabled="true" Target="SCLibrary!Microsoft.SystemCenter.RootManagementServer" ConfirmDelivery="false">        <Category>StateCollection</Category>        <DataSources>          <DataSource TypeID="SCLibrary!Microsoft.SystemCenter.SdkEventProvider" ID="DataSource" />        </DataSources>        <ConditionDetection TypeID="System!System.ExpressionFilter" ID="ConditionDetection">          <Expression>            <SimpleExpression>              <ValueExpression>                <XPathQuery>EventNumber</XPathQuery>              </ValueExpression>              <Operator>Equal</Operator>              <ValueExpression>                <Value>1</Value>              </ValueExpression>            </SimpleExpression>          </Expression>        </ConditionDetection>        <WriteActions>          <WriteAction TypeID="System.Connectors.Health.TargetSetErrorAction" ID="WriteAction">            <MonitorId>$MPElement[Name="System.Connectors.SpecialAggregate"]$</MonitorId>          </WriteAction>        </WriteActions>      </Rule> <Rule ID="System.Connectors.SpecialAggreate.Warning" Enabled="true" Target="SCLibrary!Microsoft.SystemCenter.RootManagementServer" ConfirmDelivery="false">        <Category>StateCollection</Category>        <DataSources>          <DataSource TypeID="SCLibrary!Microsoft.SystemCenter.SdkEventProvider" ID="DataSource" />        </DataSources>        <ConditionDetection TypeID="System!System.ExpressionFilter" ID="ConditionDetection">          <Expression>            <SimpleExpression>              <ValueExpression>                <XPathQuery>EventNumber</XPathQuery>              </ValueExpression>              <Operator>Equal</Operator>              <ValueExpression>                <Value>2</Value>              </ValueExpression>            </SimpleExpression>          </Expression>        </ConditionDetection>        <WriteActions>          <WriteAction TypeID="System.Connectors.Health.TargetSetWarningAction" ID="WriteAction">            <MonitorId>$MPElement[Name="System.Connectors.SpecialAggregate"]$</MonitorId>          </WriteAction>        </WriteActions>      </Rule> <Rule ID="System.Connectors.SpecialAggreate.Success" Enabled="true" Target="SCLibrary!Microsoft.SystemCenter.RootManagementServer" ConfirmDelivery="false">        <Category>StateCollection</Category>        <DataSources>          <DataSource TypeID="SCLibrary!Microsoft.SystemCenter.SdkEventProvider" ID="DataSource" />        </DataSources>        <ConditionDetection TypeID="System!System.ExpressionFilter" ID="ConditionDetection">          <Expression>            <SimpleExpression>              <ValueExpression>                <XPathQuery>EventNumber</XPathQuery>              </ValueExpression>              <Operator>Equal</Operator>              <ValueExpression>                <Value>3</Value>              </ValueExpression>            </SimpleExpression>          </Expression>        </ConditionDetection>        <WriteActions>          <WriteAction TypeID="System.Connectors.Health.TargetSetSuccessAction" ID="WriteAction">            <MonitorId>$MPElement[Name="System.Connectors.SpecialAggregate"]$</MonitorId>          </WriteAction>        </WriteActions>      </Rule> <Monitors>      <!-- this aggregate monitor has "no" unit monitor contributors -->      <!-- this aggregate monitor should target entity with thousands of instances -->      <AggregateMonitor ID="System.Connectors.SpecialAggregate" Accessibility="Public" Enabled="true" Target="System!System.Entity" ParentMonitorID="Health!System.Health.EntityState" Remotable="true" Priority="Normal">        <Category>StateCollection</Category>        <AlertSettings AlertMessage="System.Connectors.Test.Monitor.AlertMessage.FromAggregate">          <AlertOnState>Error</AlertOnState>          <AutoResolve>true</AutoResolve>          <AlertPriority>Low</AlertPriority>          <AlertSeverity>Error</AlertSeverity>          <AlertParameters>            <AlertParameter1>$Data/Context/EventNumber$</AlertParameter1>            <AlertParameter2>$Target/Id$</AlertParameter2>          </AlertParameters>        </AlertSettings>        <Algorithm>WorstOf</Algorithm>      </AggregateMonitor> </Monitors> Please help to check why it is not useful for the agent-managed computer. When insert an Event which number is 1(Error) {2(Warning),2(Success)}, the computer state changes successful except agent-managed. :(

  • Anonymous
    June 25, 2007
    Hmm...that all should work. Can you elaborate on what you mean that the state for agent-managed computer does not change. Where are you looking? If you go to the health explorer for the instance whose state is not changing but should, do you see this special aggregate monitor in the hierarchy? What is it's state? Are there any state change events associated with it?

  • Anonymous
    June 25, 2007
    OK, I see the computer state in the Computers View. If I insert an Event( number=1 ), the state of agentless computer in Computers View change to Critical from Healthy, but agent-managed computer's state didnt change. I can also see the special aggregate monitor in the health explorer, but I found that , the state of special aggregate monitor are different between agentless computers and agent-managed computers.To the agentless computers , it is success , and also has state change events which context is "The monitor has been initialized for the first time or it has exited maintenance mode". To the agent-managed computers , the special aggregate monitor has no state, it didnt change to Success, didnt have state change events, too. It has not been intialized I think , but why?

  • Anonymous
    June 26, 2007
    Just wanted to let you know that I am looking into it and have not forgotten about you.

  • Anonymous
    June 26, 2007
    Thanks JakubOleksy, :)

  • Anonymous
    June 26, 2007
    Thanks JakubOleksy, :)

  • Anonymous
    June 27, 2007
    I have read the comment. You means that the unitmonitor in your sample can only work on target who's root is management server. Is that right?

  • Anonymous
    June 27, 2007
    No, the special aggregate can be targeted to anything, but it will actually only run on the root management server. The rules that set it MUST be targeted to something on the root management server. Jack401 - The dev who developed the special aggregate is swamped with some other investigations right now. I will keep following up with him, but I am not sure how long it will be. Have you tried setting the state for other instances on the agent managed computer? Say the OS or sometihng like that?

  • Anonymous
    June 27, 2007
    Thanks JakubOleksy, I have found a way to change the state of agent-managed computer. Write a program to insert a event to the EventLog, and put it to the agent-managed computer.Create a task which runs the program for Agent Computer, then create a monitor for the windows events , the state will change when we run the task via OpsMgr SDK. This way is so complex and not the best way but really can do. Wait for your better news.If inserting SDK event can change the agent-managed computer state will be very perfect!

  • Anonymous
    October 05, 2007
    Not sure if you are still there, but we investigated this and didn't find an issue. What instance are you inserting your event 1 on behalf of?