The basic issue I faced was a dashboard with prominent single-value visualisation what was to display a count of exceptions.  The users wanted 0 exceptions to be "good" color and a range of colors after that. To demonstrate, here is a simple test dashboard making use fo the excellent features of single-value viz.   <form> <label>test single value viz</label> <fieldset submitButton="false"> <input type="text" token="limit"> <label>limit</label> <default>2</default> <initialValue>2</initialValue> </input> </fieldset> <row> <panel> <single> <search> <query>| gentimes start=1/25/2022 end=1/26/2022 increment=1h | eval count=random()%$limit$ | eval _time=starttime | table _time count | timechart span=6h sum(count) as count</query> <earliest>-1h</earliest> <latest>now</latest> <sampleRatio>1</sampleRatio> </search> <option name="colorBy">value</option> <option name="colorMode">block</option> <option name="drilldown">none</option> <option name="numberPrecision">0</option> <option name="rangeColors">["0x53a051","0x0877a6","0xf8be34","0xf1813f","0xdc4e41"]</option> <option name="rangeValues">[0,30,70,100]</option> <option name="showSparkline">1</option> <option name="showTrendIndicator">1</option> <option name="trellis.enabled">0</option> <option name="trellis.scales.shared">1</option> <option name="trellis.size">medium</option> <option name="trendColorInterpretation">standard</option> <option name="trendDisplayMode">absolute</option> <option name="unitPosition">after</option> <option name="useColors">1</option> <option name="useThousandSeparators">1</option> </single> </panel> </row> </form>   Default limit of 2 will result in a viz showing a lovely blue background and some values and trendline depending on the random data generated. limit 20 will produce most likely an orange background limit 200 a red background All this is expected and in accordance with the default viz that was produced by using the "Save As Dashboard Panel" option from the base window. A limit of 1 - which results in all data values of 0 gives the green background.  This is still expected. Where I struggle is the limit of 0 (or less) which will give no data as number % 0 is undefined.  The data for such a search has no values in the count column.    So what to do?  The single value viz has decided that null values are nearer max value than min value which makes sense if you use dafault colors because max value is colored red.  But if in your situation your low values are more abberent and you consider null values are abberations you'd want to have the nulls colored like your min value.  Also strange though si the value on the chart shows 0, even if all the values in the data set are null.  Suddenly null became 0 and not undefined, and thus 0 is treated as higher than max instead of lower than min.  I find this to be a mistake - either it's treated as 0 so color it as 0 and show it as 0 or it's treated as null so colour it as null and show it as null (or undefinied or something other than 0) The only workaround I could find (without looking at css chnages) is a bit ugly and may not suit all situations. I cludge the upper limit to some value "higher than I could ever reach" (famous last words) and stick the colour I want to display for no data there.   <option name="rangeColors">["0x53a051","0x0877a6","0xf8be34","0xf1813f","0xdc4e41","0x53a051"]</option> <option name="rangeValues">[0,30,70,100,100000000]</option>   In the real world situation I had, zero values was considered good, and no data at all is also good so the quick fix of the viz as above was enough to allow users to visualise the date. A better solution is to change the base search to something that always returned a 0  rather than null or add a line after the timechart to force nulls to an acceptable value.   I like the latter as it's far more clear what's going on.   | eval count=coalesce(count ,0)   When no data at all is returned by base search (as happened in my real world case) it can be handled the normal way with hidden panel to display when no data returned.  Side note on this: I usually have a panel that displays when there is no data for the base search but there is some data in the index/sourcetype and a different panel when there is no data at all.  This is because on rare occasions you may have a problem with a forwarder or any number of other reasons resulting in events taking longer than expected to appear in an index.  Letting user know this is the case rather than assuming "all's good" is better in my view. In real world data it's ugly to manipulate source into vizualisation just to make it look right.  Sometimes we have to, but here I think the single-value vizualisation needs an option to let the user decide how to display missing or null values.   ... View more

I don't know how to disable this message for my dashboard properly.  I have added to a css style block within my dashboard      .splunk-choice-input-message { visibility: hidden }     This suppresses all of the text beneath all of the inputs in the dashboard which is fine as it's better than causing concern with the "Duplicate values causing conflict" message. So if anyone knows a way to manipulate the CSS to only suppress that message I'd be grateful.  I don't have to allow duplicates in the dropdown and that in general it's probably a good hint but sometimes it just makes sense or so I think to ignore such warnings. I [mis]use the dropdown to also show a relative timeline of events in the order they appear in a an splunk event (which is comprised of many lines of text).  The user can drill down to the specific log line within a splunk event that they they want to examine in detail.  I also realise that I could solve this with condition on change and split the $value$ selected so that I get the id part without breaking the built in idea of duplicates being bad..  I don't know that I should have to do extra calculations just to achieve the simple idea.  Data below is my justification and it works really well for the use case which actually has hundreds of lines in the combo box.       | makeresults | eval events="1147,Event A [1] 1066,Event B [2..3] 1147,Event A [4] 1156,Event C [5..8] 1147,Event A [9] 1073,Event D [10..14] 1050,Event E [15..20] 1073,Event D [21..40] 1156,Event C [41..44] 1050,Event E [45..46] 1147,Event A [47] 1090,Event F [48] 1678,Event G [49] 1090,Event F [50] 1180,Event H [51] 1127,Event I [52] 1097,Event J [53] 1127,Event I [54..55] 1180,Event H [56] 1068,Event K [57..60] 1138,Event L [61..63] 1122,Event M [64]" | rex max_match=0 field=events "(?<event>.*)\n" | table id event | mvexpand event | rex max_match=0 field=event "(?<id>.*),(?<event>.*)"       It's true that the label in this case will be unique and the id will be duplicated.  Yet it's the label that holds the human readable useful data and the id just refers to a lookup key to present. ... View more

When I see this issue it is in a dashboard table visualization not in the search result.  The number is shown correctly as a number (right justified) in search statistics view.  Strings are shown left justified by default and numbers are right.   In my case the issue concerns representing a number as currency in a dashboard. The generating search ends with something like :   | eval Amount=round(Amount,2) | fieldformat Amount=printf("%.2f",Amount)   So there is a clear indication that Amount can only be Null or a number.  The eval is not necessary if you want to keep the original value completely in tact - I left it there to demonstrate as I was trying various things to force the table to display my value how I wished.  I use fieldformat since I wish to be able to drilldown on the actual value of Amount and not the string representation.  Fieldformat works as intended however as OP noted, table visualization doesn't maintain the intended field's right justification. To further enhance my dashboard relating to the "Amount" field I have the following.   <format type="number" field="Amount"> <option name="unit">$</option> <option name="unitPosition">before</option> </format> <format type="color" field="Amount"> <colorPalette type="list">[#F1813F,#B6C75A]</colorPalette> <scale type="threshold">9.999</scale> </format>   My field should be right justified since I have "told" the table visualization it's a number in the specific way that is documented and the base search has resulted in the field being denoted with 'numeric' td class anyhow. By this reasoning it's a bug because "table visualization does not respect numeric field right justification CSS directive". My hack solution for dashboard: Of interest to me is that when I examine the html of the generated dashboard, the field in question is denoted with class=td.numeric which includes text-align:right however it's then overridden by the table class from dahsboard itself.   .table tr, .table td, .table th { font-family: Roboto,Droid,Helvetica Neue,Helvetica,Arial,sans-serif; font-size: 12px; line-height: 16px; text-align: left; padding: 4px 8px; } td.numeric, th.numeric { text-align: right; }​    So this leads to a simple hack which solves the visualization issue for me.  Perhaps it will solve for others.   <row> <html depends="$nothing$"> <style type="text/css"> td.numeric, th.numeric { text-align: right !important; } </style> </html> </row>    I assume the CSS defined within the dashboard xml has precedence over the generated CSS which is very handy indeed.   This will result in any numeric field in a table visualization in a dashboard maintaining the right justification that the developer of the table view in statistics view intended.  Probably when that enhancement was made, no thought was given to the dashboard table visualization issue. Full dashboard example with hack    <dashboard> <label>test3</label> <row> <panel> <table> <search> <query> | makeresults | eval Amount=1234.5678 | fieldformat Amount1=printf("%.2f",Amount) | fieldformat Amount2=printf("$%.2f",Amount) | fieldformat Amount3=printf("%12.2f",Amount) | fieldformat Amount4=printf("$%12.2f",Amount) | eval x1=Amount </query> <earliest>1616708511</earliest> <latest>1616709413.085</latest> <sampleRatio>1</sampleRatio> </search> <option name="count">100</option> <option name="dataOverlayMode">none</option> <option name="drilldown">none</option> <option name="percentagesRow">false</option> <option name="rowNumbers">false</option> <option name="totalsRow">false</option> <option name="wrap">true</option> <format type="number" field="Amount1"> <option name="unit">$</option> <option name="unitPosition">before</option> </format> <format type="color" field="Amount1"> <colorPalette type="list">[#F1813F,#B6C75A]</colorPalette> <scale type="threshold">9.999</scale> </format> <format type="number" field="Amount2"> <option name="unit">$</option> <option name="unitPosition">before</option> </format> <format type="color" field="Amount2"> <colorPalette type="list">[#F1813F,#B6C75A]</colorPalette> <scale type="threshold">9.999</scale> </format> <format type="number" field="Amount3"> <option name="unit">$</option> <option name="unitPosition">before</option> </format> <format type="color" field="Amount3"> <colorPalette type="list">[#F1813F,#B6C75A]</colorPalette> <scale type="threshold">9.999</scale> </format> <format type="number" field="Amount4"> <option name="unit">$</option> <option name="unitPosition">before</option> </format> <format type="color" field="Amount4"> <colorPalette type="list">[#F1813F,#B6C75A]</colorPalette> <scale type="threshold">9.999</scale> </format> </table> </panel> </row> <row> <html depends="$nothing$"> <style type="text/css"> td.numeric, th.numeric { text-align: right !important; } </style> </html> </row> </dashboard>   Note that Amount3 is rendered as string although it's being colored correctly as a number so it's a weird one.  The table visualization is troubled by printf's attempt to left pad the value and ignores the padding however still thinks of the value as numeric in terms of the type="color" format block. Finally my question: Is there something I've missed or a better way to handle this simple requirement?  I want the dashboard table visualization to render numbers the same way as the search statistic view. ... View more

I am sure I am reading the MIB correctly. There appears to be no OID for severity. What methods have sys admins used to work around this? We are having to get custom handler created in the receiving (external) enterprise management tool. An alternative was to just manually edit the MIB to include severity. Seems the easiest but runs the risk of being overwritten during upgrades. ... View more

Duplicate of : How to make Splunk guess the correct date if only time is given? Splunk indexes times in our source and gets the date wrong with no apparent way to override the default. In our sourcetype; - The event contains a timestamp but not a datestamp - fails rule 1 & 2 & 3 below example: 23:59:59.441 Trc interesting event data 00:00:00.742 Trc additional interesting event data The filename of the source contains the date and time that the new log (source) was created - success rule 4? The last modified time is updated correctly example: -rw-r--r-- 1 user user 104857706 Jul 20 07:03 trc_urs_mm_p.20180719_203048_911.log For our needs, Rule 5 or Rule 6 would be preferable. This question is: does anyone have a workaround or override that can be implemented at indextime? I found references here: http://docs.splunk.com/Documentation/Splunk/7.1.2/Data/Configuretimestamprecognition refers to $SPLUNK_HOME/etc/datetime.xml Reading this file I can't see how it would help unless there's a special syntax that can be used to manipulate the guessed date in some way. Note: - We cannot change the log format as it's proprietary software - We could prepend every line of the log with the date by streaming the log in real time through a script but this is ugly, will temporarily double the space required for the logs (minor issue) will increase i/o wait and cpu time (moderate issue) and is another process that could go wrong. - We can try to force the application to start a new log each day at midnight (it normally creates a new log once current log reaches a specified size). If there's no clever Splunk solution available I could ask our team to request a feature but I won't hold my breath to have that happen. Ideally Splunk would let us decide the precedence of the rules per sourcetype, or allow an override along the lines of "If the date is guessed - then if the current event date/time is more than 23.5 hours (configurable) less than the previous date/time, add 1 day the guessed date for this event. In other words, 0:00:00 is the next day when the previous event had timestamp like 23:59:59. Currently in our situation Splunk gets it wrong. http://docs.splunk.com/Documentation/Splunk/6.5.2/Data/HowSplunkextractstimestamps How Splunk software assigns timestamps Splunk software uses the following precedence rules to assign timestamps to events: It looks for a time or date in the event itself using an explicit TIME_FORMAT , if provided. You configure the TIME_FORMAT attribute in props.conf. If no TIME_FORMAT was configured for the data, Splunk software attempts to automatically identify a time or date in the event itself. It uses the source type of the event (which includes TIME_FORMAT information) to try to find the timestamp. If an event has a time and date, but not a year, Splunk software determines the year, as described in How Splunk software determines timestamps with no year, and builds the timestamp from that. If no events in a source have a date, Splunk software tries to find a date in the source name or file name. Time of day is not identified in filenames. (This requires that the events have a time, even though they don't have a date.) For file sources, if no date can be identified in the file name, Splunk software uses the file modification time. As a last resort, Splunk software sets the timestamp to the current system time when indexing each event. Splunk software can extract only dates from a source, not times. If you need to extract a time from a source, use a transform. See Create custom fields at index time. ... View more