You might be capturing leading whitespace in your capture group with the \s+
in rex "(?\s+\d+\.\d+\.\d+\.\d+)"
which could cause it to not match if there isn't leading whitespace in your lookup. If you remove the \s+
from your extraction, does it help?
You might be capturing leading whitespace in your capture group with the \s+
in rex "(?\s+\d+\.\d+\.\d+\.\d+)"
which could cause it to not match if there isn't leading whitespace in your lookup. If you remove the \s+
from your extraction, does it help?
You could try setting match_type = WILDCARD("Bundle Version")
in transforms.conf. It may require a restart of Splunk after though, and no guarantee that it will work as I've seen a documented bug on Splunk not ignoring leading whitespace when it's supposed to. Worth a try though...
Docs: http://docs.splunk.com/Documentation/Splunk/6.2.5/admin/Transformsconf
match_type =
* A comma and space-delimited list of () specification to allow for non-exact matching
* The available match_type values are WILDCARD, CIDR, and EXACT. EXACT is the default and does not need to be specified. Only fields that should use WILDCARD or CIDR matching should be specified in this list
On a side note, I would try to avoid using spaces in field names - both in lookups and in event field names. If you use an underscore (_) instead of space, it'll save you a lot of headache. If you're trying to make it look nice for users, use a rename at the very end of your search, i.e. ....entire search.... | rename myfield as "My Field", myotherfield as "My Other Field"
etc.
Great Thank you!
Yes that was the problem thank you very much, by chance, would you happen to know if there is a way that i can still capture the rex pattern for my Bundle with the white space ( if i omit it i get the wrong code) but only compare the parts after?
How about this
index=* sourcetype=collectedCodeLevels.All "HMC Code Levels"
| rex "(?<Bundle>\s+\d+\.\d+\.\d+\.\d+)" | search [ | inputlookup Report_lookup.csv | table "Bundle Version" | rename "Bundle Version" as "Bundle" ]
Hmmmm that doesn't seem to work either, do you think it might be that the lookup table is configured wrong?
WIth the approach I gave, I don't think you need special configuration for that. Can you confirm if the values and its format in the lookup table matches the one you're extracting in your data?
Also, from the search I gave, open the job inspector and check the normalizedSearch that is being run.
Yes I checked and there are fields of the same value on both sides, also normalizedSearch is being ran.
Am i going to have to this from the server?
can you provide the normalizedSearch that you see (mask sensitive information).