While working on some diagnostic tools for SharePoint 2013, I came across this gem. All of the event log messages that SharePoint 2013 Search will throw are contained in a .man file that is included as a part of the SharePoint install. "searchfoundationmanifest.man" can be found inside the install directory at Program Files\Microsoft Office Servers\15.0\Bin\. Here's an example event log message that can be raised and how the definition is formatted:
<event symbol="Search_DocumentFeederNoCallbacks" value="17" version="15" channel="SearchFoundationOperationalChannel" level="win:Warning" message="$(string.SearchEvents.event.Search_DocumentFeederNoCallbacks.message)" task="msoulscat_SEARCH_DocumentFeeder"/>
value="17" corresponds to an event id of 17
version="15" sets the version level in the event log. I'm not sure how to set this programmatically using powershell to create a duplicate entry for testing. I think this is set by the version of the dll doing the logging, I haven't yet figured out how to set this when creating the log entry myself.
channel="SearchFoundationOperationalChannel" specifies the sub log to use. If you trace SearchFoundationOperationalChannel further in the file you will find. <string id="SearchEvents.channel.SearchFoundationOperationalChannel.message" value="Operational"/>, so this event will be written to the Operational log. All of these events fall under the log level log Microsoft-Office Server-Search specified in the file by <string id="SearchEvents.provider.message" value="Microsoft-Office Server-Search"/>.
I'm not totally clear on this part. The logs are actually in the application log but display in event view under a sub log. So, I was able to replicate this behavior by creating a log in Application and the setting the source to Microsoft-Office Server-Search
$EventLog = new-object System.Diagnostics.EventLog('Application')
$EventLog.Source = "Microsoft-Office Server-Search"
level="win:Warning" specifies the log level as warning
message="$(string.SearchEvents.event.Search_DocumentFeederNoCallbacks.message)" can be traced to the actual log message
<string id="SearchEvents.event.Search_DocumentFeederNoCallbacks.message" value="Maximum number of pending callbacks reached and no new callbacks received the last 10 minutes"/>
task="msoulscat_SEARCH_DocumentFeeder" can be used to find the task id
<task name="msoulscat_SEARCH_DocumentFeeder" symbol="MSOULSCAT_SEARCH_DOCUMENTFEEDER" value="8" message="$(string.SearchEvents.task.MSOULSCAT_SEARCH_DOCUMENTFEEDER.message)"/>
So, if you wanted to create a duplicate log entry, you would specify 8 as the task id.
Some, but not all of the events are monitored by the SCOM Management Pack for SharePoint 2013. An overview of the events the Management Pack covers along with suggested resolutions are covered here http://technet.microsoft.com/en-us/library/ee513082 . I have not found a public mapping of event ids to these issues. But it should fairly straightforward to map to the issues from the searchfoundationmanifest.man. This would allow you to build comparable monitoring for other event log monitors.
The searchfoundationmanifest.man also specifies information on ULS logs for search as well.
I've included a copy of the searchfoundationmanifest.man for reference below: