Understanding how to append to a lookup following an example

[ricotries]

Currently going over the Splunk App for Windows Infrastructure and found a saved search that updates a lookup table that I mostly understand, but there is a detail I am very curious about. The stanza is:

[WinApp_Lookup_Build_Perfmon - Update - Detail]
<field - value pairs>
search = `perfmon-index` eventtype="perfmon_windows" object=* \
| eval instance = if(isnull(instance), "NA", instance) \
| stats count by collection, object, counter, instance \
| sort collection, object, counter, instance \
| eval _key = collection . "___" . object . "___" . counter . "___" . instance \
| outputlookup windows_perfmon_details append=true

I understand every line in the search and I understand what happens when you use append=true and how setting a field will ensure that the column with the name of the field is added to the lookup table, what I don't understand is why the specific evaluation of the concatenation of the four columns with three underscores in between. When I try to generate _key in a separate search, it results in an empty column and from my understanding from the outputlookup documentation, the field created is the column to be added. 

Any insights on why the specific eval execution?

[scelikok]

Hi @ricotries,

It seems windows_perfmon_details is a KVStore lookup, search is creating key field for it.

https://dev.splunk.com/enterprise/docs/developapps/manageknowledge/kvstore/uselookupswithkvstore/#Th...

Splunk hide these internal fields, you can see the key value by adding another eval;

| eval key=_key

( I assume you have data inside perfmon )

[ricotries]

Your answer pointed me in the right direction. I was assuming the lookup was a CSV file and was trying to apply how outputlookup works literally. Instead of doing an eval, doing a rename actually showed the _key value. Basically the eval in the original query just creates a very unique value according to the value in the row according to the columns of the lookup. I originally thought there was a reason related to Splunk query or lookups requirements involved.