I got nothing wrong.  Step 2 is not possible.  Yes, you can change the name of the index, but an event cannot be written to a metric index without conversion.  The fact that step 1 works perfectly tells me the data is an event rather than a metric. Splunk has a tendency to overload terms.  in this case, "metric" can refer to a numeric value in an event or it can refer to a specific format of data (also numeric) that only a metric index can store.  it's the format (or lack of it) that's causing the error message. ... View more

One cannot redirect event data to a metrics index.  Doing so will produce the error message you see.  Data in a metrics index must be in a specific format - that is what makes them so fast.  It is possible, however, to convert an event into metrics at index time.  See https://docs.splunk.com/Documentation/SplunkCloud/9.3.2408/Metrics/L2MConfiguration I must point out a fundamental flaw in the plan to have only two indexes for each customer.  It means that all data will have the same retention period and (more seriously) all data will be visible to all users in that company.  It's unlikely all of a company's data will have the same security and retention requirements. ... View more

There is a long list of things that potentially could go wrong depending on what you do to the server to harden it.  It's hard to be specific about the results if you can't be specific about the changes.  We're all volunteers here, so try to meet us halfway. ... View more

Contact Splunk Education ([email protected]) for assistance. ... View more

Check the ulimits settings to make they meet or exceed Splunk's recommendations. Verify THP is disabled. If both of the above pass then open a case with Splunk Support. ... View more

Search for both apps at the same time and let the stats commands sort them out. index=... (payload.appName=app1 OR payload.appName=app2) | bin span=1d _time | rename payload.appName as appName | stats ... by appName | eval ... | where ... | sort ... | streamstats ... by appName | eval ... | stats avg(...) as avg_app1 max(...) as max_app1 count(...) as count1_app1 count(...) as count2_app1 by _time appName | rename avg_app1 as "Average App 1" ... | fields "Average App 1" ... ... View more

If your problem is resolved, then please click the "Accept as Solution" button to help future readers. ... View more

If your problem is resolved, then please click the "Accept as Solution" button to help future readers. ... View more

I didn't make it clear, but my example code is more pseudo-code than pure SPL, since I don't know exactly what to look for to locate "Close" or "Create" messages.  However, you should be able to fix your problem by replacing where with search. ... View more

Try to avoid using the transaction command because it's very non-performant.  Try this, instead.  Search for all Create and Close events then keep only the most recent for each alert.id/alert.message pair.  Throw out the Close events and what's left will be Creates without a Close. index=foo ("Create" OR "Close") ```Select the most recent event for each id/message ``` | dedup alert.id alert.message ```Discard the Close events``` | where NOT "Close" ... View more

@pedropiin wrote: But I'm aware this is definitely not the optimal way as, to my understanding, this will go through all the instances and count the ones > 10, then will go through all the instances again counting the ones > 15 and so on.  I'm not convinced this is correct.  Have you looked at the job inspector stats for this search?  I think you'll find it's not that inefficient.  Any attempt to "chain" filters is likely to perform much worse. ... View more

What have you tried so far?  How did those results not meet expectations? Have you experimented with https://regex101.com? ... View more

The rest command is processed by the local search head and all search peers, but not by heavy forwarders.  That's the way searches work.  No query is sent to a HF. ... View more

Thanks.  Please answer the other three questions. ... View more

What constitutes a match between LKUP_DSN and DS_NAME?  How much of DS_NAME is allowed to vary? ... View more

There is no need to test.  Splunk will only parse an event as JSON if the *entire* event is nothing but pure well-formed JSON.  It can't parse part of the event or extract a field and parse that.  Of course, you can do those things yourself in a query, but Splunk won't do it automatically. ... View more

If your problem is resolved, then please click the "Accept as Solution" button to help future readers. ... View more

Tell us more about the partial match on LKUP_DSN.  What is it matched against?  What part needs to match? ... View more

A Trial license is included in the Splunk Enterprise download. ... View more

Unless there was an error copying into the post, the event does not parse because it is not well-formed JSON. Also, the sourcetype attribute in props.conf is better placed in inputs.conf.  It's redundant in props. ... View more

The StatusMsg field is being created on the fly, but it has to come from *somewhere*.  The OP has a list of possible messages, but there is no indication of when each is used. <<some expression>> refers to a Boolean check that decides when to set StatusMsg to a specific string.  The expression probably will need to test the values of other fields (perhaps Host and/or ConnName).  You know your data better than I do so I can't be more detailed than that. ... View more

If you need to match the LKUP_DSN field in the subsearch with the DS_NAME field in the main search then LKUP_DSN must renamed to DS_NAME. source="*ACF2DS_Data.csv" index="idxmainframe" earliest=0 latest=now [search source="*DSN_LKUP.csv" index="idxmainframe" earliest=0 latest=now | rename LKUP_NAME as DS_NAME | fields DS_NAME | format ] | table TIMESTAMP, DS_NAME, JOBNAME ... View more