I have no information to prove putting the timestamp at the beginning of a line performs better, just a hunch that it does. I appreciate your answer (thanks!), but I will admit I was hoping for more than a hunch. I have that same hunch. I'm hoping that the Splunk devs will step in and answer. They have "inside information"—they know the code path—whereas I must rely on information I can gather externally, performing tests and measuring the results. I don't really have the time to do that properly, but it's looking like I'll need to make time if I want a fact-based answer. I've submitted feedback on the Splunk docs topic "Tune timestamp recognition for better indexing performance", which you'd think might answer these questions, but doesn't. From that topic: To speed up indexing, you can use props.conf to adjust how far ahead into events the Splunk timestamp processor looks The topic goes on to mention MAX_TIMESTAMP_LOOKAHEAD , but not TIME_PREFIX . Perhaps my feedback on that topic might prompt the Splunk devs or writers to address this question. ... View more

Thanks for the suggestion. Yes, that occurred to me, too. I'm on leave for the next couple of days; next week, I'm going to change the from statement in the dockerfile to refer to the latest tag and hope there are no breaking changes that affect my dashboard definitions (it's been several months since I last looked at this stuff). an old license in there and needs to be rebuilt. I don't understand the reference to "old license in there", but I'm not surprised; it's clear to me now that I don't understand how license expiry works. With thanks again for the suggestion to move to a newer tag, I'd also appreciate any insight you could offer me there (for example, what exactly do you mean by "old license in there"?). I guess I didn't expect my Docker image to work forever, but I wasn't anticipating this expiry issue; I really did think that the license clock would start ticking from 0 for each new Docker container, but I'm clearly wrong about that. ... View more

Hi @lfedak_splunk, I sent an email to [email protected]. Here's what happened next... I received a "do-not-reply" acknowledgement email: The support mailbox received the following Community Support case Priority: P3 Case: 541832 Subject: Splunk feature requests: 1. Zooming one chart zooms entire dashboard, 2. Auto-spanning for timecharts with sub-second time ranges. followed by another (without the "do not reply" text): As our priority is with entitled customers, we can only provide our best effort and delay is expected. We suggest that you post your issue in Splunk Answers I replied to that, and immediately received a reply with this: Your email is associated to the CLOSED Splunk Support CASE [541832] For what it's worth, here's my second email to Splunk Support (the one that resulted in the "associated to (sic) the CLOSED..." message)... RE: CASE [541832] 1. chart zooms entire dashboard, 2. Auto-spanning with sub-second time ranges Hi Splunk Support, Thanks for the response. Re: our priority is with entitled customers No worries at all, I completely understand. I expect the support I pay for ;-). Re: We suggest that you post your issue in Splunk Answers Already done, long before emailing you. In fact, I was prompted to email you by a Splunker commenting on a question that I had asked in Splunk Answers. I guess your suggestion means that you haven't yet had the chance to read down to the fourth line in my original email to you. Again, no worries. To recap: I already have dashboards with the behavior that I want. In Kibana. I've been asked to reproduce those dashboards in Splunk. It's likely these Kibana and Splunk dashboards will be demo'd alongside each other, or at roughly the same time, to customers. (For brevity, I'm not going in detail about who I mean by "customers", but I can expand on that term, if asked.) The customers will see—or experience for themselves, first-hand—Kibana dashboards dynamically zooming down to millisecond granularity, by marquee-selecting within any time-based chart. Thanks to the help of a Splunk user who provided an answer on Splunk Answers, these customers might get to see something like that in Splunk, too; although, as I've noted in comments on Splunk Answers, the user experience will not be as slick, and the current answer is not usable at time ranges under 2 seconds (so I've not yet implemented the code provided in that answer to all of my dashboards). Perhaps my experience is atypical, but for what it's worth: when I show someone a Splunk dashboard—or I chat to someone about their first experience developing and then using a Splunk dashboard—it's common for them to attempt to zoom in on a narrower time range by marquee-selecting in a time-based chart. And they're taken aback when it doesn't "work"; when it doesn't do what Kibana does, out-of-the-box. And then I have to explain—or the developer has had to independently find out for themselves—that reproducing that behavior in Splunk is not straightforward; in fact, to my knowledge, there is currently no good solution. Hence my feature requests. I can tell that many users flat-out don't believe me when I try to explain this. So, in a way, my experience on Splunk Answers has been reassuring. I regard sending you these feature requests as performing "due diligence", following through on a request from my management to reproduce Kibana dashboards in Splunk. Please don't worry at all about considering these feature requests just to satisfy me, a non-paying user. I wouldn't expect you to. 🙂 Instead, think about a user who has seen a Kibana dashboard progressively zooming in from a time range of, say, an hour, down to several milliseconds. Then think about them attempting to reproduce that experience in Splunk. Is this really such an atypical use case for Splunk? ... View more

Further to this answer, see the answers to the related question (among others), "Display date/Time range in Dashbaord" (sic). ... View more

Hi @rjthibod, Thanks very much for sticking with me across questions... With apologies, I'm unlikely to have time to try your answer today (I want a few minutes spare to look at it properly), but I will as soon as I can. One fatal flaw that I have realized with my approach (my answer)—and one reason I want to test your answer carefully—is that the size of the buckets in my approach are based on the earliest and latest records that exist in the time range, which is not the same thing as the earliest and latest times of the time range; in some instances, depending on the available records, not even close. ... View more

@rjthibod, Re: Suppressing those is definitely a much larger undertaking that would require overwriting internal Splunk objects. Yep. Prompted by @lfedak_splunk (thank you!), I've sent a feature request to Splunk via email. ... View more

Hi @lfedak_splunk, Uncanny timing. I was just about to go looking for a way to send feature requests when I saw your comment. I'll send an email now. Thanks for the tip! ... View more

@rjthibod, More niggles with narrow time ranges: if the time range is less than 2 seconds—if the difference between the values of the earliest and latest URL query string parameters is less than 2—then marquee-selecting an area of a timechart fails to trigger the custom "reload" behavior. What I'm doing: you've given me the ability (thank you!) to progressively zoom in on timecharts. That ability led me to realize that the granularity of auto-span timecharts "bottoms out" at a minimum bucket duration of 1 second, hence my latest question. Finding a solution to that question led me to discover these niggles with your solution to this question. ... View more

@rjthibod, I've hit a problem when marquee-selecting a sub-second time range: the earliest and latest parameter values in the resulting query string don't accurately reflect the time range I marquee-selected in the timechart. For example, if I select a half-a-second (0.5s) time range in a timechart—I know I'm selecting that time range, because of the tooltips on the data points within the area that I've selected—I end up with the following URL parameters: earliest=1502692231&latest=1502692231.05 and no results in the newly loaded dashboard, even though the area that I marquee-selected contained multiple data points. I discovered this problem while researching an answer to my recent question Subsecond minspan in auto-span timechart?. Your thoughts? (I wish Splunk Answers showed a preview for comments!) ... View more

Answering my own question... In brief I'm using a case function to set a token that, depending on the time range, specifies either an empty string (to rely on auto-spanning) or a span attribute: eval span=case(diff>20," ",diff>1,"span=50ms",diff>0.01,"span=10ms",true(),"span=1ms") where diff is the difference in seconds between the earliest and latest records in the time range. The "breakpoints" in the case function are an experimental work in progress. I might change these breakpoints, and add more. In detail I use the following search(es): <search id="base_metrics"> <query>index=my_index sourcetype=my_sourcetype | stats count, earliest(_time) as earliest, latest(_time) as latest</query> <earliest>$earliest$</earliest> <latest>$latest$</latest> </search> <search base="base_metrics"> <query>eval startTime=strftime(earliest, "%x %H:%M:%S"), endTime=if(strftime(earliest, "%x")=strftime(latest, "%x"), strftime(latest, "%H:%M:%S"), strftime(latest, "%x %H:%M:%S")), diff=(latest-earliest) | eval hours=floor(diff/3600) | eval minutes=floor((diff-(hours*3600))/60) | eval seconds=floor(diff-(hours*3600)-(minutes*60)) | eval duration=hours." hour".if(hours>1,"s "," ").minutes." minute".if(minutes>1,"s "," ").seconds." second".if(seconds>1,"s",""), span=case(diff>20," ",diff>1,"span=50ms",diff>0.01,"span=10ms",true(),"span=1ms")</query> <progress> <condition match="'job.resultCount' > 0"> <set token="startTime">$result.startTime$</set> <set token="endTime">$result.endTime$</set> <set token="duration">$result.duration$</set> <set token="eventCount">$result.count$</set> <set token="span">$result.span$</set> </condition> <condition> <unset token="startTime"></unset> <unset token="endTime"></unset> <unset token="duration"></unset> <unset token="eventCount"></unset> <unset token="span"></unset> </condition> </progress> </search> Here, I've included tokens that are not required for this particular solution (sorry, I couldn't be bothered stripping them out for this answer), which I use in the following HTML panel: <html depends="$eventCount$,$duration$,$startTime$,$endTime$"> $eventCount$ events spanning $duration$ ($startTime$ to $endTime$) </html> I use the span token in timechart commands: timechart $span$ ... ... View more

I'm going to fall back to using a case function. ... View more

I don't really fancy implementing a GCD function just to do this. ... View more

There's more: Error in 'timechart' command: The value for option span (741ms) is invalid. When span is expressed using a sub-second unit (ds, cs, ms, us), the span value needs to be < 1 second, and 1 second must be evenly divisible by the span value. To recap: Kibana zooms auto-interval time-based charts down to 1ms buckets. Out of the box. ... View more

Hi @MuS, Thanks for the tip. Nope, I've not tried that. From the Splunk docs for bin : The bin command is automatically called by the chart and the timechart commands I'd thought, perhaps naively, that specifying span via timechart gave me the same control as specifying span directly via bin ; that timechart "passed through" the span value to bin "under the covers". ... View more

Dang. span values must be integers. So my calculation needs to evaluate out which subsecond unit to use: us | ms | cs | ds. Not rocket science, but a tad tedious. ... View more

I'm going to try setting a token with a value based on the time range, and then injecting the token into the timechart command: For time ranges down to a few seconds—say, 20 seconds—set the token to an empty string (let the timechart "auto-span") For narrower time ranges, take control of spanning: set the token to span=<milliseconds>ms , where <milliseconds> is a number of milliseconds, calculated from the time range, that results in a "reasonable" number of buckets ... View more

@rjthibod, Even nicer would be if you could suppress the display of the now-unnecessary slider controls and Reset button, and reload immediately after the user finishes marquee selection. But I imagine that might require significantly deeper customization of the selection behavior; best left to the Splunk dev team deciding to support this behavior without custom JavaScript (I can hope). And it's not going to stop me accepting your current answer. ... View more

@niketnilay, Re: you would need to use Simple XML JS Extension, where you can combine Splunk JS Stack and jQuery to implement the UI behavior you need. Yes, you are absolutely correct: @rjthibod has provided an answer with working code that matches this description. ... View more

@rjthibod, Do you have any preference, or suggestion, for a JavaScript file name that does not explicitly include the term kibana ? Yes, this JavaScript enables Kibana-like behavior—that is, after all, why I asked for it—but the fact that @lfedak_splunk redacted the term "Kibana" from my original question has sensitized me to the possibility that some people might not appreciate seeing that term in relation to Splunk. I don't want to offend anyone. One idea: reload_on_zoom.js On the other hand, if users start including your code as-is, and the Splunk dev team starts noticing this code with its "kibana" qualifier cropping up frequently, that might prompt them to support this behavior out of the box. (Splunk devs, I'm curious: are you monitoring the activity on this question?) ... View more

@rjthibod, With apologies for the belated reply (I felt bad not getting back to you, but I'm under the hammer at work)... Yes, I've tried the solution you posted above, and... It works perfectly! Thank you so much! Thank you especially for providing code that plays nicely with URLs that contain query string parameters in addition to earliest and latest . I am happy to accept your answer as-is, but before I do that, I thought I'd ask: is it possible to apply this behavior to all time-based charts in a dashboard without explicitly specifying: <selection> <set token="kibana_pan_zoom.earliest">$start$</set> <set token="kibana_pan_zoom.latest">$end$</set> </selection> For example, is it possible in JavaScript to detect whether the query for a chart includes a timechart command, and then dynamically perform the equivalent of specifying that <selection> element in the Simple XML? If so, then simply adding a script attribute to the dashboard Simple XML would confer this "Kibana-like" zooming behavior, rather than having to add that <selection> element to every "time-based" chart. One reason I'm asking: some of my dashboards contain numerous timecharts. For example, one of my dashboards has 9 instances of Simple XML similar to this: <chart> <search base="base_timechart"> <query>fields _time avg(response)</query> </search> (That is, the dashboard contains numerous timecharts, all based on a common base search.) If it's not possible, or it's too difficult, or you disagree that it's worthwhile, or you feel—justifiably!—that you have already spent enough time answering this question, then I will happily accept your answer without further ado. Or I'll accept it as-is anyway, if you're prepared to add comments or edit the code in your answer later, after I've accepted your answer. (Is such "post-acceptance" editing of an answer allowed? I don't know.) I'm wondering how to "spread the word" about your solution, over and above accepting your answer, because I think it will be useful to a lot of people. Certainly, I think that anyone who has developed dashboards in Kibana, and then moves to Splunk, will be interested in this. Thank you so much for taking the time to consider my question and provide such a clear answer, with working code. ... View more

Possibly too much information: I'm using these "top 10" tables with data bars for drilldown. I originally wanted to use tag clouds (which is what I'm using in equivalent dashboards on a different analytics platform), but it wasn't immediately obvious to me how to add drilldown behavior to either the custom tag cloud viz in the Splunk-built dashboard examples, or the Wordcloud viz. So I "fell back" to using tables (which support drilldown out-of-the-box via Simple XML), and added data bars to offer the feeling of "scale" that font sizes in tag clouds offer. In case you're wondering, I don't simply use bar charts with drilldown because, in my data, some values can be relatively huge, dwarfing the bar sizes of others (even in the "top 10"), so there's not much "bar" to click on for drilldown. This problem is avoided in tag clouds by having a minimum font size. ... View more

I had the same issue using the "Table with Data Bars" example. I wanted to apply data bars to multiple tables in a dashboard, not just a single table with id="table1" . (Splunk 6.6.3.) I solved this by iterating over mvc.Components.getInstances() and looking for tables. I apply the data bar rendering to any cell whose field name contains "%". This suits me better than requiring a fixed field name of "percent". I typically don't use the top command to generate these percentage values. Here's an example of the type of query I use for these data bars (with the first application-specific stage omitted): | stats sum(response) as response by applid | sort -response | head 10 | eventstats sum(response) as total | eval percent=100*response/total | fields - total | rename response as "Total response time", percent as "% of top 10" Here's my updated table_data_bar.js file: require([ 'jquery', 'underscore', 'splunkjs/mvc', 'views/shared/results_table/renderers/BaseCellRenderer', 'splunkjs/mvc/tableview', 'splunkjs/mvc/simplexml/ready!' ], function($, _, mvc, BaseCellRenderer, TableView) { "use strict"; var DataBarCellRenderer = BaseCellRenderer.extend({ canRender: function(cell) { return (cell.field.indexOf('%') !== -1); }, render: function($td, cell) { $td.addClass('data-bar-cell').html(_.template('<div class="data-bar-wrapper"><div class="data-bar" style="width:<%- percent %>%"></div></div>', { percent: Math.min(Math.max(parseFloat(cell.value), 0), 100) })); } }); $.each(mvc.Components.getInstances(), function (i, view) { if (view instanceof TableView) { view.addCellRenderer(new DataBarCellRenderer()); } }); }); ... View more