今天听“the .NET show”，里面有一个叫做ALEX SUTTON的，是个结巴~
第一次听结巴英语，暴寒~~~
From a developer point of view, the message is just raise an event. You shouldn't have to think about, well, in this case, I used this API; in this case, I used the other. What's nice about Longhorn is there's one API for raising the event, separate in the manifest that describes the event that you're raising. You can pipe that event to a particular log. Our guidance there is to think about four types of events: admin events, operational events, analytic events, and debug events. Each type of event has some different characteristics around how that event is used and the quality of service, if you will. The admin events are the critical events. These are the things that the administrators or users need to know when something's wrong, and they need to take action. Yes, in the ideal case, a troubleshooting script or MOM Management Pack can take care of that, but when an administrator wants to know if something's wrong and what to do, they want to look for those admin events. The key there is making them actionable, no noise. The next level down are operational events. These are additional events that may be useful for troubleshooting, they can indicate that an application has returned to a healthy state, or they are events that are useful for triggering automated actions. One of the new features we have in Longhorn is the ability for the Task Scheduler to run an action on an event. If you want a troubleshooting script or an email sent when a particular event happens, that can now be raised. That event may or may not indicate a problem, so it could be an operational event.