We are upgrading from splunk 3 to 4. We previously had sourcetypes with "-" in them. It looks like these aren't supported?
That's not my real question. We want both the new and old sourcetypes to work. Can we alias them? I see some stuff about tagging/renaming so you can access the orignal with "_sourcetype=xxx", but we want them both to just work.
Yes. You can use the
rename command in props.conf:
[sourcetype] rename = <string> * Renames <sourcetype> as <string> * With renaming, you can search for the sourcetype with sourcetype=<string>
If you rename the old to the same name as the new sourcetype, that should do what you want.
we tried that, but we want BOTH the old and new sourcetype to work (you can actually get the old sourcetype to work with _sourcetype, but we want current saved searches/code to not have to change)
I don't think there is anything you can to do make this "just work" for all your existing searches since you want both names available.
Here are a few options:
1.) Use a massive find and replace process that replaces all occurrences of "sourcetype=name" with "(sourcetype=name OR sourcetype=name") in your savedsearches.conf and eventtypes.conf.
2.) Use sourcetype "tags". In 4.x you can actually "tag" your sourcetypes, which you couldn't do in earlier version because the tagging a sourcetype in those versions was hijacked for the rename-like behavior. So now that you can straight up tag sourcetypes, you can get the functionality you are looking for that way.
You still have to do some kind of massive find and replace thing, using "tag::sourcetype=name" rather than "sourcetype=name".
3.) Put the effort into consolidating your sourcetypes and fixing everything on a one-by-one basis. I know you would like to avoid this, but it may make your sourcetypes more consistent long term. (Also keep in mind that with the rename feature, you can rename your souretypes per application by making that "rename" entry in props.conf only available to a single app. This may or may not be a good idea, but it's an option.)
Those are just some thoughts, it's hard to say what approach is easier or better long term without seeing the bigger picture of your existing setup. Just wanted to throw another idea out there.