We're building an app for WebSphere and trying to come up with a naming convention for field names.
I'm nervous about simple field names (e.g. "ExceptionId") because if users write searches like "ExceptionId=123" and another app gets installed which also defines an "ExceptionId" field, then all those existing searches might break.
So we're thinking about prefixing all our field names with a common prefix, e.g. "websphere_". Is this a good idea or a bad idea?
If "good idea" then should we use lower case or PascalCase, and should we use dashes, colons, or some other character as a separator?
I realize that sometimes users will want to aggregate results for the same field name across multiple apps. I've been thinking that we should handle that case using field aliases so our prefixed fields could be mapped to "bare" field names in a [common information model](http://www.splunk.com/base/Documentation/latest/Knowledge/UnderstandandusetheCommonInformationModel). So, the question above is solely about what we should do when sharing is not intended by the app author, and how to avoid unintended sharing of field names across apps.
We follow a similar practice in our deployment, usually naming fields with "xxx_" where xxx is a rough approximation of sourcetype. Things like "pix", and "db2", and "was". The aliases to a common model are a good idea as that should let you be more or less specific as need be. Obviously, whatever naming "standard" you make and like should be okay. We went with our scheme simply to make it look visibly different from auto-extracted fields. But, avoid names starting with an underscore, as Splunk has internal metadata that uses those.
You should probably avoid using dashes, since I don't think they are legal. And even if they are, that would make eval's ugly, for example what does
eval total_kb=websphere-bytes/1024 mean?
First, my vote is always for "xxx_yyy" format, and it matches up with the common information model anyways.
However, I say it's a bad idea. It sounds like you're trying to account for user stupidity, which tends to be unavoidable and not worth the time. I think the field name should be common to multiple sources and apps if it has the same meaning/value. Educate the user on proper searching -- if they need exceptionid from a particular source, sourcetype, or eventtype, then that's how they should craft the search. If they want all exceptionid values from their entire install they shouldn't have to jump through hoops to get there.
If there's real concern about data sharing, the real way to do that is by putting data into different indexes. In that way, you even gain RBAC if they need it.
There certainly will be cases where a field needs a name that communicates some sort of context or uniqueness, but I don't think it should be a wholesale act of creating special fields names.