Re: the good, bad and ugly examples are static values right? Yes. I arbitrarily set thresholds at 30 and 50: less than or equal to 30 is "good", greater than 30 and less than or equal to 50 is "bad", greater than 50 is "ugly". Would it be possible to do something like ... Instead of static values? Yes. However, a specific answer would depend on which method you want to use to specify the threshold values. For example: macro, token, lookup, search? In yet more detail, if the answer is "token": do you want dashboard UI controls that set tokens for the threshold values, and for those tokens to be used in your search? This is veering off the subject of your original question, and I suspect there will be existing answers (and Splunk docs) that cover this, but I'm happy to help as far as I can. ... View more

You're welcome! You wrote: So I would need to add these 2 lines to my search Yes, but it's not quite that simple. If I interpret your original search correctly, it uses the appendcols command to append columns to a single event. By contrast, my answer requires that you have three events: one per day, each with two fields ( Day and Errors ). You need to reproduce that structure based on searching your ingested events, rather than generating them as I have done using makeresults . I don't have your data, so I would have some trouble providing you with a complete replacement for your search that would be guaranteed to work. You need to do some work to adapt my makeresults -based example. Tip: use append , as in my example, instead of appendcols . Copy my example search into the default Splunk Search app, excluding the last eval Good... and table commands, and view the tabular results in the Statistics tab. Your search needs to reproduce that structure. That is, you need to reproduce the structure of the results of the following search (identical to my example in the answer, but with the last eval Good... and table commands replaced with a single table command: | makeresults | eval Day="Daybeforethat", Errors=20 | append [| makeresults | eval Day="Yesterday", Errors=40 ] | append [| makeresults | eval Day="Today", Errors=80 ] | table Day, Errors (The table command is really only there to exclude the unwanted _time field generated by makeresults . I could have used fields - _time to do the same thing.) ... View more

I deliberately confined my answer to Simple XML, without delving into JavaScript. ... View more

If you wanted to expose the good/bad/ugly thresholds to the dashboard user, you could include the thresholds in the field names. For example, instead of the field name Good , use the field name Good (< 30) (or ... (< 30%) : for various reasons, including simplicity, I deliberately kept the term "percentage" out of my answer). ... View more

"Daybeforethat" (your term) = "The day before yesterday" = "Eergisteren" (Dutch), right? ... View more

You're welcome! I'm glad I could help. Some final points: With apologies if you know this: you don't need to use the makeresults | eval hard... commands that I used in my example search. I used those commands to dynamically generate data because I don't have your log. You don't need to use makeresults with eval to generate data; you have the data in your log. I notice you changed the MB string in my example to GB . To calculate gigabytes from bytes, you need to divide the number of bytes by 2 to the power of 30: you need to change the pow(2,20) function call to pow(2,30) . (Guilty admission: in my original comment, which I edited shortly afterwards, I incorrectly used pow(2,10) to convert bytes to megabytes. I did that because I was hastily copying'n'pasting from code that converted bytes to kilobytes. Sorry if that misled you.) ... View more

Given time, and if the following solution doesn't work reliably, then I might (possibly; I'm not certain) be able to define tokens that contain the adjusted field names, and refer to those tokens in the <option> . Or I might just be dreaming; it's late here (I'm in Perth, Australia, UTC+8). Try replacing the fieldColors option with this: <option name="charting.seriesColors">[0xff0000, 0x77aaff]</option> You might need to change the order of those colors, depending on the order of the fields in your search. I'm not certain that seriesColors , even when given the same number of colors as corresponding fields in the search, always assigns colors in the same order. It might; I just don't know for sure. It would be helpful if the Splunk docs were clearer on this specific point. ... View more

Just a thought: if the byte figures are big, you might want to show them in different units (here, megabytes): eval Space = 'Space'." ".tostring(round('Bytes'/pow(2,20),1))." MB" ... View more

Yes, I've seen the effect my answer has on the mouseover tooltip for each segment. However, given that you're already specifying showPercent , I think it looks okay. ... View more

Thanks very much for the follow-up. I really appreciate your descriptions in options (a) and (c) of "data-only" apps, with and without Eventgen. While option (c) had previously occurred to me, I'd never gotten around to thinking in detail about the specific configuration required (the monitor input). I'm going with option (b), which is the option I was originally considering. You've helped convince me that this is the best fit for my use case. I'm okay with providing instructions to step through the upload procedure, such as selecting the appropriate custom source type. Thanks again for your help and advice, much appreciated. ... View more

I wish there were a corresponding fieldLineWidths . ... View more

Yes. Use the charting.fieldDashStyles option. Tested in Splunk 7.3.0: <option name="charting.fieldDashStyles">{"fieldname": "dash"}</option> ... View more

Another reason why, for my use case, I prefer uploading via Splunk Web over the method that you describe: uploading via Splunk Web does not require the user to have direct access to the Splunk app folder. It's conceivable that the users who want to try out my app with sample data might not be that Splunk-savvy. Installing Splunk, installing the app from Splunkbase via Splunk Web, and then uploading sample data (after downloading the data from somewhere else) via Splunk Web: these are—thanks to you, the Splunk developers—easy GUI procedures. Furthermore, if the user decides to run Splunk in a Docker container, rather than installing it on their native OS, then that adds another level of complexity to the method that you propose: having to copy the sample file into the Docker container. I'm sincerely not being deliberately adversarial here: I really do want to understand whether, for my use case, the Eventgen-based method that you suggest is better than uploading via Splunk Web. Currently, however, I see more cons than pros. ... View more

Thanks for your answer, much appreciated. I've not used an eventgen.conf file before. That requires the Eventgen app to be installed, right? That is, this app: http://splunk.github.io/eventgen (also available on Splunkbase), correct? With apologies—I realize I'm probably missing something—I don't see the benefits of using Eventgen in this context. It seems like an unnecessary prerequisite. I don't need to alter timestamps in the sample data; I don't need to simulate real-time event arrival. I just want to upload the sample data, as is, as quickly as possible. In my app description in Splunkbase, I'd planned to point users to wherever on the web I'd put the zipped JSON Lines sample data file, and then provide instructions to unzip the file, and then use Splunk Web to upload the data in the file. A few mouse clicks. What am I missing? How does using Eventgen improve on this? ... View more

The property in the incoming JSON Lines event data that contains the event timestamp is also, after timestamp extraction, similarly redundant. But I'll leave discarding that property for another, ahem, time. ... View more

Follow the existing transform that overrides the source type with a new, second transform that removes the code property from the _raw event data. In props.conf : TRANSFORMS-changesourcetype = set_sourcetype, remove_code_property In transforms.conf : [set_sourcetype] # Set the sourcetype to code property value in JSON REGEX = \"code\":\"([^\"]+)\" FORMAT = sourcetype::$1 DEST_KEY = MetaData:Sourcetype [remove_code_property] # Remove the code property to conserve license usage REGEX = ^({.*)"code":"[^"]+",(.*)$ FORMAT = $1$2 DEST_KEY = _raw (In my case, in the serialized incoming JSON Lines data, the code property happens to be the first property in each line.) ... View more

You wrote: I am indexing a file with JSON ... incStart: "1.4848974e+12" I'm curious. I doubt that this is a verbatim example of the JSON in the input file, because it's not JSON: in JSON—as opposed to a JavaScript object literal—you must enclose property names, such as incStart , in quotes. And then, you enclose the numeric value in quotes, as if it were a string value. Are you really enclosing that value in quotes in the JSON (JSON Lines?) input file? If so—and if you have any control over the format of that input file—then do this instead: "incStart": 1.4848974e+12 Splunk (I'm currently using 7.3) correctly ingests such numbers in scientific notation in JSON. ... View more

Thanks again for your help, much appreciated. In this case, I can't see any alternative to a dedup with sortby . I take your point about doing it as late as possible. The search I cite in my question produces the results I need without using stats . I'll call this "solution 1". Your answer (a) uses stats but (b) doesn't produce the results I need. Not as-is. So, in that sense, it's not a solution. Your answer uses stats purely (see the note below) for data reduction: it consolidates events with identical by field values into a single row. The reduction ratio depends on the event field values. For example, if each original event has a unique peaktasks value, there would be no data reduction. Note: The count field produced by this stats has no intrinsic value in this context. We remove it. For my current data, with 863 events (a relatively small set compared to the set that I anticipate working with soon), that stats command outputs 224 rows, which is a significant reduction. That stats command does not remove the need for dedup : it just reduces the number of input rows to dedup . For performance reasons, that might, as you imply, be reason enough to do it. I edited your answer to produce the results I need, replacing the sort with a dedup . I'll call this "solution 2". For my current data, solution 1—the original solution cited in my question, which does not use stats —is faster than solution 2—your answer, using stats , adjusted to produce the results I need. I suspect, but do not know, that solution 2 (based on your answer) might be faster with more events. I look forward to doing further testing with a much larger set of events. For example, I'm curious to see—while acknowledging that this depends on the data values—if there's a performance crossover point between a dedup -only (solution 1) and a stats -followed-by- dedup (solution 2). P.S. I'll likely apply round() to the eval for the percentage field. ... View more