Knowledge Management

Solve the scenario by creating a macro or through macros.conf?

pavanae
Builder

when any splunk search runs with the word "getABCsWin"(in any dashboard or alert etc etc). I want the string timeformat="%d/%m/%Y:%H:%M:%S” to be added to that search. So that i can get the output as i needed i.e; in the DD/MM/YYYY format.

Example search in a dashboard :-

earliest="08/01/2016:00:00:01" latest="08/01/2016:23:59:59" getABCsWin("XYZ","abc12345678")

After creating the macro the search should run as follows

timeformat="%d/%m/%Y:%H:%M:%S” earliest="08/01/2016:00:00:01" latest="08/01/2016:23:59:59" getABCsWin("XYZ","abc12345678")

Any ideas Splunkers?

Note :-

For US users due to the localization specifier in the URL "en_US" the splunk was displaying the events in MM/DD/YYYY. but we are trying to look for DD/MM/YYYY. Since outside of US users using the same timeformat and getting the results as needed. So I need to get work on the macros instead of modifying the search since if modified the search display wrong results for outside US users.

What could be the possible sollution for this situation.

0 Karma
1 Solution

acharlieh
Influencer

I'll admit I'm playing on beta code right now but this should be the same in the released version. In short, I don't believe a macro will solve your issue.

timeformat= in the search string like that has nothing to do with the output format but rather only how earliest= and latest= are parsed. See this doc toward the bottom. No matter your locale string, en_US or en_GB or even de_DE:

timeformat="%d/%m/%Y:%H:%M:%S" earliest="08/01/2016:00:00:01" latest="08/01/2016:23:59:59" | stats count | addinfo | convert ctime(*_time) as *_pretty

Gives the number of events on 8 January from 1 second past midnight inclusive through 1 second before midnight exclusive, whereas

earliest="08/01/2016:00:00:01" latest="08/01/2016:23:59:59" | stats count | addinfo | convert ctime(*_time) as *_pretty

is the same searches just looking over 1st August... note in all cases the convert command uses the same month day year format for the formatting fields from the addinfo command.

If displaying readable dates is important to both locales is important, you could dictate that searches and dashboards should use ISO 8601 format, which should be unambiguous to all.

earliest="08/01/2016:00:00:01" latest="08/01/2016:23:59:59" | stats count | addinfo | convert timeformat="%Y-%m-%dT%H:%M:%S%z" ctime(*_time) as *_pretty

but that might not be pretty enough for your users. But tacking time zone information on helps illustrate another point of search mechanics that might be throwing your searches off between US and non-US users, your earliest and latest is being parsed in the time zone of the user. So if their time zone is individually set to UTC (or the system time zone is UTC)... the above search is for events for most of the 1st of August, UTC, however if their time zone was set to say, America/Chicago, that search window is looking for events within the 1st of August, Central US time. (1 August 2016, 5:00:01 am UTC -> 2 August 2016, 4:59:59am).

I am not a visualization dev, but you may also be able to do something with Javascript in your dashboard, or possibly event a way to eval a token to get the format, but I'm not sure about that offhand.

PSA

Out of curiosity, what use case do you have for specifying static dates in a dashboard search? Instead you could be using relative time ranges so that your dashboard stays up to date, but in addition, in a dashboard you could be using a time picker, or even just the earliest and latest elements of your search element.

View solution in original post

0 Karma

acharlieh
Influencer

I'll admit I'm playing on beta code right now but this should be the same in the released version. In short, I don't believe a macro will solve your issue.

timeformat= in the search string like that has nothing to do with the output format but rather only how earliest= and latest= are parsed. See this doc toward the bottom. No matter your locale string, en_US or en_GB or even de_DE:

timeformat="%d/%m/%Y:%H:%M:%S" earliest="08/01/2016:00:00:01" latest="08/01/2016:23:59:59" | stats count | addinfo | convert ctime(*_time) as *_pretty

Gives the number of events on 8 January from 1 second past midnight inclusive through 1 second before midnight exclusive, whereas

earliest="08/01/2016:00:00:01" latest="08/01/2016:23:59:59" | stats count | addinfo | convert ctime(*_time) as *_pretty

is the same searches just looking over 1st August... note in all cases the convert command uses the same month day year format for the formatting fields from the addinfo command.

If displaying readable dates is important to both locales is important, you could dictate that searches and dashboards should use ISO 8601 format, which should be unambiguous to all.

earliest="08/01/2016:00:00:01" latest="08/01/2016:23:59:59" | stats count | addinfo | convert timeformat="%Y-%m-%dT%H:%M:%S%z" ctime(*_time) as *_pretty

but that might not be pretty enough for your users. But tacking time zone information on helps illustrate another point of search mechanics that might be throwing your searches off between US and non-US users, your earliest and latest is being parsed in the time zone of the user. So if their time zone is individually set to UTC (or the system time zone is UTC)... the above search is for events for most of the 1st of August, UTC, however if their time zone was set to say, America/Chicago, that search window is looking for events within the 1st of August, Central US time. (1 August 2016, 5:00:01 am UTC -> 2 August 2016, 4:59:59am).

I am not a visualization dev, but you may also be able to do something with Javascript in your dashboard, or possibly event a way to eval a token to get the format, but I'm not sure about that offhand.

PSA

Out of curiosity, what use case do you have for specifying static dates in a dashboard search? Instead you could be using relative time ranges so that your dashboard stays up to date, but in addition, in a dashboard you could be using a time picker, or even just the earliest and latest elements of your search element.

0 Karma

somesoni2
SplunkTrust
SplunkTrust

I dont believe something like that is possible (conditional stuffs getting added to all search based of the search itself). What is the content of your current macro (getABCsWin) ? You may add that timeformat to that macro itself.

0 Karma
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 ...