Ok I might have been a bit too quick to say that it was perfect..... when it says "manage_deleteAllEvents", it means it. Does there happen to be a similar command for moving these to history and not just dropping them from the status table?
The only way I've come up with so far is return the entire event list, parse it for the device I'm working on and then run "manage_deleteEvents" on the list of events which will then archive the events to history. Obviously this approach is VERY client & network heavy when compared to "manage_deleteAllEvents". Thanks for the help, Trey On Wed, Mar 4, 2009 at 1:29 PM, Trey Sheldon <[email protected]> wrote: > Matt, > > Thanks! The "deleteAllEvents" is perfect. Basically what happens is > when we reimage a machine, we don't want to know about anything that > could have happened in a previous install or during the reimage > process. But setting to decomissioned isn't an appropriate solution > as we actually want to keep track of what state the machines are in- > whether it be redeploying software or reimaging the system. > > Thanks again! > -Trey > > > On Wed, Mar 4, 2009 at 10:02 AM, Matt Ray <[email protected]> wrote: >> I'm not exactly sure what you're looking for. Do you want to clear >> all events before changing to your maintenance production state? Or >> are you trying to not get any events while you're in a production >> state? If you put the devices into "decommissioned" they won't >> monitor or generate any new events. If you want to programatically >> clear the events, I believe you should be able to delete the events with >> wget >> 'http://admin:zen...@myhost:8080/zport/dmd/ZenEventManager/manage_deleteAllEvents?devname=blah' >> That may work. Or you could send clear events if there's a particular >> event that is causing issues. >> >> Thanks, >> Matt Ray >> Zenoss Community Manager >> community.zenoss.com >> [email protected] >> >> >> >> On Mar 3, 2009, at 11:53 AM, Trey Sheldon wrote: >> >>> I'm working on a script that will integrate our build system with >>> zenoss, and while its fairly easy to move the servers to a production >>> state to prevent alerts during our rebuild cycle- it doesn't solve the >>> problem of being alerted of any outstanding alerts once the production >>> state is reset to normal. >>> >>> I'd like to programatically "move to history" all events for the >>> associated device before resetting the production state. I've run >>> across some discussions of "getJSONEventsInfo()", but I'm not sure if >>> there's possibly a better method out there... (or better yet- a list >>> of methods available for xml-rpc??) >>> >>> If anybody has any thoughts I'd be interested in hearing them. >>> >>> Thanks! >>> -Trey >>> _______________________________________________ >>> zenoss-users mailing list >>> [email protected] >>> http://lists.zenoss.org/mailman/listinfo/zenoss-users >> >> _______________________________________________ >> zenoss-users mailing list >> [email protected] >> http://lists.zenoss.org/mailman/listinfo/zenoss-users >> > _______________________________________________ zenoss-users mailing list [email protected] http://lists.zenoss.org/mailman/listinfo/zenoss-users
