We’re looking for a way to support a number of identical named environments, such as UIT1, UIT2, etc. Each environment is a collection of applications running on a particular set of hosts. Each application is a collection of a certain set of sourcetypes.
What I’d like is to be able to independently define the source types generated for a particular application, and give it a name. The name is just the mapping of sourcetypes generated by a particular application. Separately, we’d like to give a name to an environment, which would be a collection of hosts. So when we’re done we’d be able to say:
And that would translate in splunk terms to something like:
Host=”foo” and sourcetype=”type1” or sourcetype=”thype2” or ....
When we’re done, because we’ve separated the app definition out, when we later change the sourcetypes for an application, we’ll be able to make that change in one place. If we were merely to give the above search a name, we’d have many hundreds of cloned full queries, and changing the sourcetypes for one application would require manually updating every cloned and named query.
Create two automatic lookups, to map from "host" to "environment", and from "sourcetype" to "app" respectively.
with lookup files containing at least these columns:
etc. With an automatic lookup, the reverse mapping on search will work exactly as you have asked.
answered 14 Jun '10, 18:32
I think you could do this with tags or lookups. There are pros and cons to either approach. Here are a few things to consider: Lookups would require editing of a csv file when new environments/apps are added. Lookups are generally faster and can be made to work in a date-effective way. Tags are individual objects in 4.1, and therefore can be assigned to a specific user or shared across role (which will probably just get in the way for you).
Gkanapathy just posted an example using lookups, ...
Using tags, you search would look like:
answered 14 Jun '10, 18:40
We assign environments like that in the host value rather than sourcetype. Since our log files are the same in the different environments, we don't really want to have to re-do field definitions for every environment (every new sourcetype).
We do this for appservers, databases, webservers, and more.
"host" is really an abstract concept in the age of virtual servers and cloud computing after all...
So in the inputs.conf we have:
and for another one:
Users can then search on:
host=myserver*_myenvironment1 or host=myserver1_myenvironment*
or some combination.
You could extend this to:
answered 14 Jun '10, 18:41