Where I need to keep this JS? In dashboard or in any path?  ... View more

FWIW, it's usually better to ask a new question than to pile on to a 4-year-old thread. To keep only the BAD events, try one of these index=my_index | eval my_check=if(my_field>100,"NOK","OK") | where my_check="NOK" | table _time my_check or index=my_index | where my_field>100 | table _time my_field     ... View more

https://www.splunk.com/en_us/blog/platform/splunking-your-conf-files-how-to-audit-configuration-changes-like-a-boss.html?locale=en_us This will show you how to track conf file changes.  Earlier questions wanted to change control on dashboards which are xml files so it wont work for those. ... View more

Well, it's all complicated and performance tuning searches might be a huge headache. As a rule of thumb it's usually better to avoid subsearches and it's best to leave as much work to the indexers as you can (so you can benefit from parallelization). So that's why I was pointing out that there should be a better way to do what you're trying to do than use map. But, having said that: 1) Sometimes map-based solution can be good enough (I have such solution at home - I wrote a map-based search way back when I was learning SPL and since the subsearch is only run twice, it's not worth the time needed to rework the search to touch it). 2) Sometimes map can be the only reasonable solution (if indeed the outer search results  narrow down the subsearch parameters that the stats- or anything-else-based approach would mean too much searching from raw events and digging through too much data. So just get to know your job inspector and use it 🙂 One could argue about the readability argument though since often what is "readable" for a non-splunk-experienced people is simply something that is written with a completely different paradigm in mind and is simply not the way it's done in SPL. Like typical overuse of the "join" command by people coming to Splunk from relational database environments. ... View more

Hello richgalloway, Thanks are not enough for the help provided by this forum and your replies, I will try the "done" tag. thanks again, eholz1 ... View more

I further confirmed that the problem can be reproduced reliably by reloading the web page of the dashboard. When there is already working visualization, once I reload, then the visualization will be gone.  ... View more

Hi @yshen, if you're not fluent in SPL I hint to follow the Splunk Search Tutorial (https://docs.splunk.com/Documentation/Splunk/latest/SearchTutorial/WelcometotheSearchTutorial) because searches are the base of everything in Splunk! Anyway the choose between lookup and summary index depends on some factors: if you have many cases Summary is more efficient, if for the check the time isn't relevant, lookup is the easier way. Anyway, you have to take your alert and add at the end the command | outputlookup your_alerts_Lookup.csv append=true then when you run an alert you can search on the lookup. It's difficoult to give you more help because it depends on the use cases. For this reason I hinted to learn SPL, so develop this solution will be very easy. Ciao. Giuseppe ... View more

Thanks for the perfect solution! ... View more

I also note that with Splunk SDK (Python), at the end of the embedded query, using 'fields' to select the returned fields, it does not work as I desired with all fields returned. But 'table' would result in only the listed fields returned. ... View more

With hint by https://splunk-usergroups.slack.com/team/UB5DA9L02, it turns out that as the sourcetype is only known in the context of my application ics_analytics, in the service definition with SDK, I must indicate the application context with app= argument. Here is the corrected service definition:   service = client.connect( host= 'splunk.bart.gov', app='ics_analysis', port = '8089', username = 'userid', password = 'secrete', )   once the sourcetype is properly declared to be known, the same code as above would be able to retrieve the field value of ENTRY. Here is the link to the relevant documentation: https://docs.splunk.com/DocumentationStatic/PythonSDK/1.6.16/client.html#splunklib.client.Service This is post is a capture of Slack discussion: https://splunk-usergroups.slack.com/archives/C04DC8JJ6/p1649351828984919?thread_ts=1649265592.685629&cid=C04DC8JJ6         ... View more

Hi @yshen, good for you, see next time! Ciao and happy splunking. Giuseppe P.S.: Karma Points are appreciated 😉 ... View more

For the record, I ran into a case, when I run into the error message. It was when I needed to replace an existing csv file for lookup.  I forgot to delete the existing one, and hoping the new file will override the existing one. It turned out that Splunk just complained without clearer indication of my offense. It would have been more helpful with more concrete error diagnose. ... View more

I've understood the example of how to display an icon and how to make it disappear. Now I need to figure out how to implement the drill-down on the icon displayed.  Any suggestion would be appreciated.  The more I study it, the more I feel that this is a generic requirement of placing single value visualization on a schematic diagram against a feature value, at the position specific to the feature value. Therefore, I raised an "idea" here: https://ideas.splunk.com/ideas/EID-I-945 Please review, comment, and support, if you agree. Thanks!     ... View more

@gcusello Thanks for the pointer.  My problem is a real one that I need for some field troubleshooting. Maybe, my framing of my problem could be simplified. But it's what I can do at the moment. Maybe, once I know the solution, then the problem statement might be simplified.  The extraction of the fields of DEVICE, ATTRIBUTE, etc. has already been done in the respective sourcetype. Your suggestion of using transaction with startwith and endwith might work sometimes.  But I eventually need to identify those event groups that have subsets of the expected events. For example,  Certain group may only has event of    "SOR_RESTRICT_STATUS.STATE"    so the transaciton may need to startwith    "SOR_RESTRICT_STATUS.STATE"   as well.  Likewise, some other subset may only have    SOR_A_STATUS.STATE OR SOR_B_STATUS.STATE   so the transaction may need also to endwith    SOR_A_STATUS.STATE OR SOR_B_STATUS.STATE   by this school of thought, the eventual transaction definition would be like:   transaction DEVICE startswith="SOR_A_STATUS.STATE OR SOR_B_STATUS.STATE OR SOR_RESTRICT_STATUS.STATE" endswith="SOR_A_STATUS.STATE OR SOR_B_STATUS.STATE OR SOR_RESTRICT_STATUS.STATE"   I have tried how it would up with the same condition for startwith and endwith I am concerned that it would lose the expected differentiation for the transactions.  Maybe a question to experts. ... View more

It took me at least 5 hours of experiment to make sure that I'm not making a mistake. It's really frustrated and disappointed by such mystery and arbitrary behavior without any hint of error message! A great company can do better. I wish customers should not always be treated as a victim of hidden secrete! So the moral of the story, a base search must explicitly specify all the fields that will be used by the searches using the base search by command fields or table. ... View more

Your question was very clear, and I just had to make it that way. I hope it is the same for others. ... View more

can anyone advise on this ? regards Altin ... View more

@yshen  There are a number of ways to solve this, but it's still not clear when you talk about "sometimes" or "ever". Your example data is only 16 Sep, however, the basic solution to hanging on to the raw data is to use eventstats/where, like this   | makeresults | eval _raw="Temperature=82.4, Location=xxx.165.152.17, Time=Wed Sep 16 07:43:01 PDT 2020, Type=UPS; Temperature=84.2, Location=xxx.165.152.48, Time=Wed Sep 16 07:43:01 PDT 2020, Type=UPS; Temperature=82.4, Location=xxx.165.154.21, Time=Wed Sep 16 07:43:01 PDT 2020, Type=UPS; Temperature=82.4, Location=xxx.165.162.22, Time=Wed Sep 16 07:43:01 PDT 2020, Type=UPS; Temperature=77.0, Location=xxx.165.164.17, Time=Wed Sep 16 07:43:01 PDT 2020, Type=UPS; Temperature=75.2, Location=xxx.165.170.17, Time=Wed Sep 16 07:43:01 PDT 2020, Type=UPS; Temperature=77.0, Location=xxx.165.208.12, Time=Wed Sep 16 07:43:01 PDT 2020, Type=UPS; Temperature=73.4, Location=xxx.165.48.20, Time=Wed Sep 16 07:43:01 PDT 2020, Type=UPS; Temperature=75.3, Location=xxx.165.52.13, Time=Wed Sep 16 07:47:01 PDT 2020, Type=TempSensor; Temperature=77.9, Location=xxx.165.52.14, Time=Wed Sep 16 07:47:01 PDT 2020, Type=TempSensor; Temperature=76.3, Location=xxx.165.54.24, Time=Wed Sep 16 07:47:01 PDT 2020, Type=TempSensor; Temperature=83.8, Location=xxx.165.48.20, Time=Wed Sep 16 07:47:01 PDT 2020, Type=TempSensor; Temperature=73.8, Location=xxx.165.36.21, Time=Wed Sep 16 07:47:01 PDT 2020, Type=TempSensor" | eval x=split(_raw,";") | mvexpand x | rename x as _raw | extract | fields - _raw | eventstats max(Temperature) as mt by Location | where mt>83   which will leave you 3 rows and then you can do what you want with that. However, it's not clear if, say, the location "Temperature=76.3, Location=xxx.165.54.24", recording the 76.3 on 16th September, but which had recorded 83.1 on 4th July 2002, should be in the 'hot locations'. (assuming of course you have data going back that far). If so, then the solution would have to change, as it is unlikely to be practical to search that much data with eventstats. Instead you would be better off doing a daily search to find temps that day that exceeded your threshold, or even just the max temp for each location and save that max to a lookup file for the location. Then when doing the 'find me raw data for hot locations' query, you would then do the basic search for all data for your period, then lookup the location from the lookup and make the check there, for example base_search | lookup location_list.csv Location OUTPUT locationHistoricalMaxTemp | eval maxTemp=max(locationHistoricalMaxTemp, Temperature) | eventstats max(maxTemp) as mt by Location | where mt>83 What this is doing is getting the currently saved historical max from your lookup based on location, then assuming you update that lookup at the end of the day, so the current Temp might be higher, the maxTemp will pick the highest of either today's or the historical, then the eventstats/where comes into play to find the rows from hot locations. Hope this answers what you're trying to do.     ... View more

@isoutamo Thanks for the license information! ... View more

I wish there is a way that is less impacting to the service than restarting the forwarder. ... View more

Hi @yshen , I understand your point now. Try below with your log events I am assuming your _time field has format like : 2020-08-23T03:04:05.000-0700 and it represents the start time in each log event. your base search.... | transaction Agent_Hostname alarm startswith="raised" endswith="cleared" |eval end=_time+duration, start=_time |eval end=strftime(end,"%Y-%m-%dT%H:%M:%S.%3N-0700"),start=strftime(start,"%d-%m-%Y %H:%M:%S.%3N-0700") | table start,end ,Agent_Hostname , alarm, duration   Try and let me know.   ... View more

@thambisetty  I further studied your example,  I experimented line by line,  Here is my annotation of your example:     index=snmptrapd sourcetype=trapParsed critical # filter the events contain "critical" | fields Agent_Hostname,alertStatus_1,status, temperatureVlaue # select the fields | rename Agent_Hostname as Location # rename the field | eventstats latest(_time) as latest_time by Location # compute the lasets(_time) and add latest_time to the events | where latest_time=_time # select the events' whose _time equals to latest_time | stats latest(*) as * by Location # what's the purpose? Seems redundant? | convert ctime(latest_time) # convert the format of lastest_time to be readable     It seems to me that line of  stats latest(*) as * by Location basically for each Location value, get the latest event for all the fields selected above. By the state above it,  where latest_time=_time effectively for each value of Location there will be only  events whose _time value equals to the lastes_time for the Location value, unless there are multiple events for the same value of Location with the same _time, usually there will be only one event for the Location value. Even if there were multiple events for the same Location value, and the same _time equaling to the laste_time, it seems  stats latest(*) as * by Location will select the latest for the value combinations of all the selected fields for each Location value? So it sounds the purpose of this statement is to remove duplicate events for each Location value? Thanks again! ... View more