Splunk Search

Per-app field name prefixes?

Justin_Grant
Contributor

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.

1 Solution

dwaddle
SplunkTrust
SplunkTrust

Justin,

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.

View solution in original post

mw
Splunk Employee
Splunk Employee

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 exception_id from a particular source, sourcetype, or eventtype, then that's how they should craft the search. If they want all exception_id 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.

Justin_Grant
Contributor

Hi @Lowell - good point. I changed the dash to an underscore in my question.

0 Karma

Lowell
Super Champion

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?

dwaddle
SplunkTrust
SplunkTrust

Justin,

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.

Get Updates on the Splunk Community!

What's new in Splunk Cloud Platform 9.1.2312?

Hi Splunky people! We are excited to share the newest updates in Splunk Cloud Platform 9.1.2312! Analysts can ...

What’s New in Splunk Security Essentials 3.8.0?

Splunk Security Essentials (SSE) is an app that can amplify the power of your existing Splunk Cloud Platform, ...

Let’s Get You Certified – Vegas-Style at .conf24

Are you ready to level up your Splunk game? Then, let’s get you certified live at .conf24 – our annual user ...