As my program isn't great at planning for the future, or doing anything involving industry standards, we are indexing our Liferay Tomcat logs in Splunk, but had not used the typical "access_combined" sourcetype: we just called it "liferay" and we extracted all the fields using more of an IIS theme (so 'cs_uri_stem' instead of 'uri', etc.). We built several rudimentary web stats dashboards for the various sites we are hosting in Liferay.
However, in a recent effort to get the Splunk App for Web Analytics working, I used the sourcetype rename and renamed our "liferay" sourcetype to "access_combined" and re-extracted all of the fields using the more common standard field names the App was expecting. So now, the Splunk App for Web Analytics works great, but all of my previously built custom web stats dashboards are broken because the old sourcetype (and associated field extractions) is no longer recognized.
Is there a way to have a single sourcetype respond to two different names, like a field alias? Or do I have to go and do a bunch of find & replace work and change all my old dashboards?
It might be possible to use the sourcetype rename in the app context of Splunk App for Web Analytics only. This way all your old dashboard would still use the original sourcetype.
So you actually got it working with IIS logs? I have had a heck of a time trying to get it to work with my IIS logs, so it sounds like doing what you are doing and mapping to the Apache access_combined must be the only way to go. I am left wondering why they list 'iis' as a supported source type for Web Analytics. Is it that Splunk hasn't looked at IIS since it moved to W3SVC logs by default? I wish we could get more information on this because I would really like to get Web Analytics to work.
Well, no. While we do use IIS, it is in support of an automated data movement software, so it isn't really web site navigation traffic, just uploads and downloads. We built custom dashboards for handling all of that.
However, I did get the Web Analytics working with the field aliases for my tomcat logs, at least within the limitations of our logging. I did ultimately end up updating all of my existing custom web stats pages to use the field aliases, as the aliases seemed to completely take over the field naming, instead of both field names being available.