Splunk Search

Eval Case Sequence on Conditions

Mary666
Communicator

Hi Splunk Community,

How does Spunk prioritize conditional case functions? Lets say I have a case function with 2 conditions - they work fine, and results are as expected, but then lets say I flip the conditions. What I see happen when I flip the conditions in the case function the results are not correct. Shouldn't Splunk be able to still check which condition it applies to even though I have flipped the conditions?  Example below:

Case: TimeSchedule should output the closest 7th min or 37th min - so every half hour past the 7th min or 37th min from the zipTime_epoch.

Works Fine as output TimeSchedule should be 2021-03-06 23:37:59.000000

 

| makeresults
| eval zipTime="2021-03-06 23:35:59.000"
| eval zipTime_epoch=strptime(zipTime, "%Y-%m-%d %H:%M:%S.%6N")
| eval lastunzip_hour=tonumber(strftime(zipTime_epoch, "%H"))
| eval lastunzip_min=tonumber(strftime(zipTime_epoch, "%M"))
| eval lastunzip_sec=round(zipTime_epoch%60,6)
| eval TimeSchedule=strftime(case(lastunzip_min%30 < 7, zipTime_epoch-zipTime_epoch%1800+420+lastunzip_sec,lastunzip_min!=37 AND lastunzip_min!=7, zipTime_epoch-zipTime_epoch%1800+2220+lastunzip_sec,1=1,zipTime_epoch),"%Y-%m-%d %H:%M:%S.%6N")

| table TimeSchedule, zipTime, lastunzip_hour, lastunzip_min, lastunzip_sec, zipTime_epoch

 

 

Does not work fine when case in conditions are flipped- output should be 2021-03-06 23:37:59.000000 instead.

 

| makeresults
| eval zipTime="2021-03-06 23:35:59.000"
| eval zipTime_epoch=strptime(zipTime, "%Y-%m-%d %H:%M:%S.%6N")
| eval lastunzip_hour=tonumber(strftime(zipTime_epoch, "%H"))
| eval lastunzip_min=tonumber(strftime(zipTime_epoch, "%M"))
| eval lastunzip_sec=round(zipTime_epoch%60,6)
| eval TimeSchedule=strftime(case( lastunzip_min!=37 AND lastunzip_min!=7, zipTime_epoch-zipTime_epoch%1800+2220+lastunzip_sec,lastunzip_min%30 < 7, zipTime_epoch_epoch-zipTime_epoch_epoch%1800+420+lastunzip_sec,1=1,zipTime_epoch),"%Y-%m-%d %H:%M:%S.%6N")

 

 

Labels (1)
Tags (1)
0 Karma
1 Solution

scelikok
SplunkTrust
SplunkTrust

@Mary666,

Case statement checks the conditions in given sequence and exits on the first match. That is why order depends on your conditions. 

In your second sample case, lastunzip_min values less than 7 will not hit to second case since they are not equal to 7, so they will end up by adding 2220 seconds.

On below sample order is not important;

| eval result=case(a=1,3,b=2,7)

| eval result=case(b=2,7,a=1,3)
If this reply helps you an upvote is appreciated.

View solution in original post

0 Karma

scelikok
SplunkTrust
SplunkTrust

@Mary666,

Case statement checks the conditions in given sequence and exits on the first match. That is why order depends on your conditions. 

In your second sample case, lastunzip_min values less than 7 will not hit to second case since they are not equal to 7, so they will end up by adding 2220 seconds.

On below sample order is not important;

| eval result=case(a=1,3,b=2,7)

| eval result=case(b=2,7,a=1,3)
If this reply helps you an upvote is appreciated.

View solution in original post

0 Karma

Mary666
Communicator

Hi @scelikok 

Let me know if I’m tracking correctly, case will take the first match as the answer?

On my question the query’s - the min of the time stamp is 35, and both conditions are true, since min is not 37 and not 7 on first case, and on the second the modulus operator is working like so 35%30 = 5 which makes it <7 - which makes it also true...

so since both are true it will grab the first match...

adding 2220 in seconds instead of 427 in seconds....

0 Karma

scelikok
SplunkTrust
SplunkTrust

Hi @Mary666 ,

Yes,correct. Case stops on the very first match. 

If this reply helps you an upvote is appreciated.
Did you miss .conf21 Virtual?

Good news! The event's keynotes and many of its breakout sessions are now available online, and still totally FREE!