According to MSDN "in Microsoft SharePoint Foundation 2010 the preferred method of writing to the Trace Logs is to use the SPDiagnosticsServiceBase class" (http://msdn.microsoft.com/en-us/library/ff512746.aspx).
MSDN also provides some guidance on the trace and event log severity levels to use (http://msdn.microsoft.com/en-us/library/ff604025.aspx), however the WriteEvent() and WriteTrace() methods use slightly different enums; the diagnostics logging configuration in Central Administration is slightly different again, and then you have a third set of values accessed by the PowerShell command Get-SPLogEvent.
The table below shows the mapping of levels from these different sources.
Despite the complicated mapping, in general I think things go in the right direction with events writing to the event log and trace log at the same time, and having a high trace level. The distinction between event logging and trace information is also good, with independently set thresholds.
| EventSeverity | EventLogEntryType | TraceSeverity | ULSTraceLevel | ULSLogFileProcessor .TraceLevel |
| None = 0 | None = 0 | 0 (None) | Unassigned = 0 | |
| ErrorServiceUnavailable = 10 | Error | 1 | Critical = 1 (or ErrorCritical) | |
| ErrorSecurityBreach = 20 | ||||
| ErrorCritical = 30 | ||||
| Error = 40 | ||||
| Exception = 4 | ||||
| Assert = 6 | ||||
| Warning = 50 | Warning | 8 | Warning = 8 | |
| FailureAudit = 60 | ||||
| Unexpected = 10 | Unexpected = 10 | Unexpected = 10 | ||
| Monitorable = 15 | Monitorable = 15 | Monitorable = 15 | ||
| SuccessAudit = 70 | Information | 18 | Information = 18 | |
| Information = 80 | ||||
| Success = 90 | ||||
| Verbose = 100 | ||||
| High = 20 | High = 20 | High = 20 | ||
| Medium = 50 | Medium = 50 | Medium = 50 | ||
| Verbose = 100 | Verbose = 100 | Verbose = 100 | ||
| VerboseEx = 200 | VerboseEx = 200 | VerboseEx = 200 |
The blue highlight shows the normal default event logging, with red the other available settings; the green highlight shows the normal default trace logging (which applies to both events and traces), with the other available settings in yellow.
When using the public class Microsoft.SharePoint.Administration.SPDiagnosticsServiceBase, the two public enums that you start with are Microsoft.SharePoint.Administration.EventSeverity and Microsoft.SharePoint.Administration.TraceSeverity.
In WriteTrace() the value is mapped directly to internal enum Microsoft.SharePoint.Diagnostics.ULSTraceLevel, checked against the logging configuration, and then sent to ULS.
In WriteEvent(), the EventSeverity is checked against to logging configuration to determine if it should be written to the event log (only limited settings can be selected in the UI); the EventSeverity is also mapped to the EventLogEntryType that should be used.
EventSeverity is also mapped to ULSTraceLevel, then that value checked against the logging configuration (for tracing) before being sent to ULS. Note that all events are mapped to relatively low ULSTraceLevel values, so will normally all be sent to ULS.
So, that's how values get into ULS.
Coming from the other end, if you use the PowerShell cmdlet Get-SPLogEvent then one of the parameters you can pass in is -MinimumLevel. The cmdlet uses the internal class Microsoft.SharePoint.Diagnostics.ULSLogFileProcessor to retrieve the records, which uses the nested enum ULSLogFileProcessor.TraceLevel, with special additional handling that allows "ErrorCritical" (which is converted to Critical). These values are compare directly to the values logged.
Appendix: There is another internal enum, Microsoft.SharePoint.Diagnostics.ULSEventSeverity, which I have left out because it isn't used in the main flows above.
There is a private method in SPDiagnosticsService to convert from EventSeverity to ULSEventSeverity, and another private method in Microsoft.SharePoint.Diagnostics.ULS that converts ULSEventSeverity to ULSTraceLevel, but they are not consistent with the mapping in TraceEvent() or even appear to be used (no callers for the private method in ULS)!