Splunk Search

outputlook with a subset of fields

middlemiddle
Explorer

I have an alert that joins RAW events with a lookup containing thresholds (and yes, it has to be a join).  I would like to take one field from the alert details, last_file_time, and outputlookup only that field back to the root lookup table.

Question: Is there a way to only outputlookup a single field from the table output?

Example:

| inputlookup MyFileThresholds.csv

| join type=left file_name

[ search .......

eval last_file_time=strftime(_time, "%x %T")
]

| table monitor_status current_time current_day file_name file_cutoff_time host last_file_time

| outputlookup append=false MyFileThresholds.csv  <-I only want last_file_time going back to the root lookup table.

Labels (4)
0 Karma

Richfez
SplunkTrust
SplunkTrust

If you only want "last_file_time" back in the MyFileThresholds.csv, then only *put* last_file_time in there.

...
| table last_file_time
| outputlookup append=false MyFileThresholds.csv

 Of course, you didn't structure your search to only GIVE you a single last_file_time, but instead to give one per event, and an event in this case is ... probably ... possibly?... a list of filenames and last_file_time and some other fields?

If you only wanted to update the last_file_time with the new information from your search, then it seems like that's what you are doing - though you hid that giant search inside the "it has to be a join" so we can't really see what it's doing. 

Anyway!

If you would like a better answer, please let us know what it is you are trying to do in English.  Just explain it. It feels like you are starting at the end of the process instead of at the beginning.

 

0 Karma

middlemiddle
Explorer

That is the documented way to only have one Field in the outputlookup command.  What I need is the table command to have all the fields referenced so the Alert has context, however only have one field in the outputlookup to go to the .csv file.  The search is not critical, all that remains are the fields within the table; both the table and the outputlookup are non-streaming commands.

search ....

| table monitor_status current_time current_day file_name file_cutoff_time host last_file_time

| outputlookup.....

0 Karma

Richfez
SplunkTrust
SplunkTrust

Could you explain what it is you are trying to actually accomplish? 

I'm pretty sure we can find a way to get done what it is you need to get done if we only knew what it was you were trying to do, but you are still starting at the end of the process. 

But maybe this is the answer you were looking for -

There's no way to branch like that in SPL.  It is a linear pipeline from the beginning to the end (with a few weird fan-outs that aren't branches for the map command and a few others).  If you do a thing in step N-1 that removes field X, then in step N you can't reference field X because it's not there.  The *only* output it gives will be the output from step N, and that won't include what was removed in step N-1.

So if outputlookup doesn't have a way to filter to a specific set of fields, the only way to filter it to a specific set of fields is in the step before the outputlookup, which means you lose that context.

So either you run the search twice - once to get the alert and once to update the threshold, or you rethink *how you are doing this whole process* and make it so it'll all work like you want.  Which we'd love to help with, but we need to know what it is you are doing in order to help you with that.

 

 

 

 

 

 

 

 

0 Karma
Get Updates on the Splunk Community!

Splunk Education - Fast Start Program!

Welcome to Splunk Education! Splunk training programs are designed to enable you to get started quickly and ...

Five Subtly Different Ways of Adding Manual Instrumentation in Java

You can find the code of this example on GitHub here. Please feel free to star the repository to keep in ...

New Splunk APM Enhancements Help Troubleshoot Your MySQL and NoSQL Databases Faster

Splunk Observability has two new enhancements to make it quicker and easier to troubleshoot slow or frequently ...