The reason of my question: When I do maintenance tasks on OMS´s server and I must restart the server, I would like that mails as "Agent is unable to communicate with the OMS" don´t be send.
I have known the blackout concept, so I change my question... Do you know how to create an agent´s blackout through command line?
To create a blackout, you can use emcli create_blackout command:
Also there is "emctl start blackout" that can be run from an agent host:
Hi Loc, thanks for your answer.
Yes, I know the commands, and I have read the documentation again. But I am not be able to create an agent blackout, this is my problem.
For example, using emctl command:
The result of it is:
$AGENT_HOME/bin/emctl start blackout PRUEBA_AGENTES "srvoem1a.garba.com.ar:3872":agent -d 30
With emcli command I don´t find the agent type, I have found the group type, so I have created a group with two agents, then I created a blackout on it, but the agents continue in active state.
Blackout start Error : the agent target "srvoem1a.garba.com.ar:3872" does not exist
Also, you shouldn't really have to blackout all your agents when the OMS is down. I would look at the ping grace period, this is the time EM gives all the agents to start talking before it assumes they're down.
Download the latest repvfy kit
Run repvfy execute optimize (this will adjust the ping grace time, disable tracing that's on by default and not necessary, reduce the retention time for internal em errors (not more than 7 days generally needed), and make sure you have at least 2 task workers running).
Yes, the blackout at nodeLevel is an option, but I want avoid this option because if I put this type of blackout when the OMS starts, sends mails with the targets that were down previously.
For example, if I have a Stand By Database as a target, this target is show down always, and this is correct. So when I stop OMS and then I start it, EM sends mails showing this target down, so we want avoid these mails, do you understand my example?
Please correct me if I have understood your problem incorrectly. I believe what you are referring to is the set of notifications about OEM components sent by the OMS after stopping and restarting the OMS, is that correct?
If that's what you mean, I also found those annoying. I think you are probably receiving these because you have subscribed to receive emails for one of the default incident rulesets: "Incident management Ruleset for all targets". Because OEM monitors its own components, it recognizes that these pieces were down, and sends a notification, then sees they are back up and sends an all clear notification. I think the actual incident rule in this set causing these emails is the "Incident creation Rule for target error" rule.
To avoid receiving these notifications, I do not subscribe to the default incident management rulesets for email. Instead I have created my own incident rulesets that cover only those targets and target types for which I do want to receive notifications: database systems, agents, hosts, listeners, and metric alerts. All of the internal OEM components have their own target types (like "Application Deployment", "Oracle WebLogic Domain", "Oracle Authorization Policy Manager", and so on) and if you have a rule set up to send notifications for ALL target types (like the default rulesets do), you will receive those notifications.
Do I understand your problem correctly?
Hi Brian, thanks for your answer.
Yes, I am subscribed to receive emails for the default incident rulesets. And is a good idea create new incident rulesets too. But my question is not about OEM components only.
Perhaps, if I unsubscribe of all default incident rulesets and I create a new ruleset without targets down (stand by databases for example) my problem will be resolved. But I don´t know if this is correct, because (following the same example) if we active the standby database in the future, it wouldn´t be being monitored.
I don´t understand why is so difficult create a blackout on an agent... This will be easier.
Are you on EM12cR1 or R2? R2 removed the ability to blackout an agent from the GUI. I don't know if it still works through EMCLI. A host blackout seems to accomplish what I used to do with agent blackouts (stop all notifications). But as Courtney said you should not have to blackout your host targets to bounce the OMS. I only get one email when I bounce my OMS, and that's from the OOB notifications I have set up. I will test a few things when I'm back in the office tomorrow.
By design, you cannot blackout just the agent target regardless whether you use emctl, emcli or through the console. If you bring down the OMS host for maintenance and you want to avoid alerts relating to the targets on the host, you can blackout the whole host (i.e., blackout all targets on the host) as Courtney suggested.
The default rulesets are mainly for boot strapping. Except in some very trivial environments - we would expect folks to create rulesets to suite their environments and disable these.
I think this many be mentioned in the best practices document as well. We obviously need to do a better job of highlighting this. I'll talk to my team and the PMs to see how we can clarify this further in the documentation and the product as well.
I have put a node level blackout on OMS´s server, but the alerts of "Agent is unable to communicate with the OMS" continue. So I think that an option would be put a blackout on all target hosts. Because I need down oms to take a cold backup.
So, I will investigated how to put a blackout on all targets automatically, and then I will post it here.