I have this simple data:
Wich will be cut by fixed positions.
201508150015002060HHTTP090E0000000085CHAN5050
I need to cut this into 8 new fields
1 field - length 8
2 field - length 6
3 field - length 2
4 field - length 3
5 field - length 3
6 field - length 1
7 field - length 10
8 field - lenght 12
I've been tryin' to use regex positional, it works inline, but not in field extractor, why?
This is my current regex:
rex field=_raw "(?P<FIELDNAME>\.{8}" | table _raw FIELDNAME
Thanks in advance!
Youll need props and transforms
props.com
[sourcetype]
...
report-a = reporta
transforms.conf
[reporta]
REGEX = (?<field1>.{8})(?<field2>.{6})(?<field3>.{2})(?<field4>.{3})(?<field5>.{3})(?<field6>.)(?<field7>.{10})(?<field8>.{12})
Youll need props and transforms
props.com
[sourcetype]
...
report-a = reporta
transforms.conf
[reporta]
REGEX = (?<field1>.{8})(?<field2>.{6})(?<field3>.{2})(?<field4>.{3})(?<field5>.{3})(?<field6>.)(?<field7>.{10})(?<field8>.{12})
Thanks @jkat54 and @Runals!
We've just upgraded Splunk's version, so we're kinda new to this new field extractor.
Seems the older one was working faster and easier.
But I guess that'll do it!
cool thanks, i know it was a dance around the question. maybe if you use triple backslashes or triple dots etc in the field extractor it will work. You can only imagine the code behind a regex making website...
I'm reminded of a guy i know who writes code in ruby that writes powershell code that writes sql code. ugh.
Keeping it simple when possible in my shop...
Haha lol
I don't wanna regret upgrading the version, also cuz my project app was being developed in 6.1 and the server uses 6.3. Now my props conf has [EXTRACT] tags and also [REPORT] tags, kinda confusing, hope I don't loose previous regex fields, not sure if this update came to help when it comes to field extractions...
hmm i havent seen that yet,,, still poking around on 6.2.x and below
Did u have any in-app concern version-related over updates?
Generally commands are backwards compatible.
They do deprecate and add commands over time though.
So I always read every "change log" with every update between the version i'm on and the version i'm upgrading to. Just to be sure they haven't deprecated anything or changed some functionality I was depending on.
I also make a copy of the splunk folder as is before any upgrades (automated backups usually suffice, but i'll make a local filesystem copy in /tmp c:\temp, etc before making changes.
Remove the \ in front of your "." as that is telling the engine to specifically look for a dot character. You also don't have a closing paren though that might be a copy/paste issue. The following methodology should work (in theory)
... | rex "^(?<field1>.{8})(?<field2>.{6})"
It worked for the first field, but when I go back to the field extractor, I get this message:
" The extraction failed. If you are extracting multiple fields, try removing one or more fields. Start with extractions that are embedded within longer text strings. "
Yeah look at jkat54's answer. I don't play with the GUI field extractor /shrug. If you don't have CLI access I'd bake that into a macro or something.
I like the idea of a macro to run the rex command that way you dont have to use the extraction if you dont want it. I doubt there are many performance concerns with this data though. So maybe full fledged props and transforms will be fine. I too avoid the field extractor. I also feel sorry for the developers of the tool.
" ." = " Matches any character, except for line breaks if dotall is false. "
So, it should work passing the amount of positions inside {size} as a substring for example but in a regex, right?