Bernd, apologies it has taken this long to reply to your question. Let me
answer some of this inline...
David Keogh [MSFT]
--------------------
| Reply-To: "B.Hoffmann" <hoffmann@REMOVEmicom-medicare.de>
| From: "B.Hoffmann" <hoffmann@REMOVEmicom-medicare.de>
[quoted text clipped - 13 lines]
| Ex. only log messages from Component1 that are issued by user X (property of
| the event) or which contains a searchstring.
There is good news and bad news here. EIF doesn't provide the ability to
filter in the EnterpriseInstrumentation.config file by event property
value. However, if you don't mind doing this filtering downstream, you can
of course create a WMI subscription which filters based on specific event
properties using standard WQL (WMI query language).
The other way you could do this is to wrap the place you fire the event in
an IF block, testing for a specific user value and only firing the event if
you have a match. Unfortunately, unless you do this carefully, it's
hard-coded in your application. If you drive this from configuration, it
could impose a significant performance penalty unless you are very careful
about how you cache this info. This is one reason why we only enabled
filtering in EIF based on the kind of event, not down to the level of
specific event property values.
| I already created my own schema. I added several properties to common, error
| and some other events.
[quoted text clipped - 5 lines]
| After this he analyzes the logged data. But the first step is to configure
| the amount of data that is being logged.
This makes sense to me. Many of our customers have used our configuration
API, either within scripts, or GUI consoles as you describe. What you can
often do is define multiple filters, each of which represent a particular
"logging level" or amount of information being published. Then, your
scripts/consoles can simply bind to or unbind from each filter in order to
change the amount of information which is logged.
| /Bernd
B.Hoffmann - 02 Mar 2004 11:14 GMT
Thank you for this information.
What I try now is the following. Maybe somebody has suggestions for this
approach..
In the BaseEvent i check the EventSource.Parameters and filter events
depending on property values. This is done by doing a regular expression
check with RegEx.IsMatch(<property value>,<regular expression from eif
config>).
The entry in the EnterpriseInstrumentation.config could be (this checks
occurence of String1 OR String2 in the property MyProperty, if true the
event is send to the configured sinks):
<eventSource name="MySource" type="softwareElement"
internalExceptionHandler="report">
<eventSourceParameter name="MyProperty" value="String1|String2" />
</eventSource>
If the Reg. Expr matches then PrepareForSerialization can return true.
Otherwise false.
Im doing the check with something like this (is not yet completed)
private Boolean IsEventFiltered(EventSource eventSource)
{
bool bIsFiltered = true;
foreach(Object oKey in eventSource.Parameters.Keys)
{
bIsFiltered = IsPropertyFiltered(this.GetType(),
oKey.ToString(),eventSource.Parameters[oKey].ToString());
if(!bIsFiltered) return false;
}
return bIsFiltered;
}
private Boolean IsPropertyFiltered(Type poType, string psPropertyName,
string psFilter)
{
try
{
string sPropertyValue = poType.InvokeMember(psPropertyName,
BindingFlags.DeclaredOnly |
BindingFlags.Public |
BindingFlags.NonPublic |
BindingFlags.Instance |
BindingFlags.GetProperty,
null, this, null).ToString();
return
System.Text.RegularExpressions.Regex.IsMatch(sPropertyValue,psFilter);
}
catch
{
return true;
}
}
moi moi
Bernd
Mike Hayton [MS] - 09 Mar 2004 21:30 GMT
I think the approach is fine.
The only comment is that I would remove the call to InvokeMember() and hard
code the getting of the property values.
InvokeMember() is extremely slow - so you'll be getting a big performance
hit at this point.
You might want to check out caching the RegEx objects as well.
Cheers
Mike
--------------------
| Thank you for this information.
|
[quoted text clipped - 55 lines]
| moi moi
| Bernd

Signature
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm