About thesplunkmonkey

thesplunkmonkey · ‎09-15-2022

Switch up the order of things a bit, and this should work for you: | streamstats sum(diff) as FinalDiff by X_Request_ID |where FinalDiff> 1.0

thesplunkmonkey · ‎09-15-2022

Switch the order up a bit and it should work for you. | stats sum(diff) as FinalDiff by X_Request_ID |where FinalDiff>1

thesplunkmonkey · ‎09-15-2022

Yes, use the cookie insert persistence for your LTMs and topology at the GTM. In that way you'll be routed to the same data center with subsequent calls and then the cookie insert persistence will keep you pinned to the same SH in that site with subsequent calls. Your LB admin should know how to do the configs for that type of persistence for whatever particular type of LB you're running.

thesplunkmonkey · ‎09-08-2022

Any time! Once you have had a chance to implement, and assuming it works for you, consider dropping back in and accepting that solution so others can reference it. And if not, please let us know that too.

thesplunkmonkey · ‎09-08-2022

Interesting. I haven't seen this exact logo change (splunk>enterprise to splunk>cloud), but I have seen it change before for other Splunk products, i.e. Splunk> hunk. I'm not sure, but it could be related to something in your license. When I've seen it change to the hunk logo, it ended up being due to a stanza in the license file referencing hunk, even though we weren't using it. In fact, when we saw the hunk change, it was actually due to a demo license file included with the product and we just needed to delete that file. In this case I would first look in the license files that may exist on your search heads and on the license manager to see if there is any reference to Splunk Cloud on any of those. All that being said, you may consider opening a new question as this seems like a separate topic from the original post.

thesplunkmonkey · ‎09-06-2022

Yes, exactly. If you are using a global LB to balance between LTMs, you'll want to make sure that your persistence is set properly at both the global and local levels so that not only do you stay pinned to the same data center, but also the same host in that data center.

thesplunkmonkey · ‎09-06-2022

I generally hate recommending any solution that includes any sort of subsearch due to the performance hit, but here is one potential option for you. index=<my index> sourcetype=oracle:query source=<source> earliest=-5m | stats sum(OUT_CUSTS) as CURRENT_OUT by DISTRICT | append [ index=<my index> sourcetype=oracle:query source=<source> earliest=-1d | bin span=5m _time | stats sum(OUT_CUSTS) as CURRENT_OUT by DISTRICT, _time | stats max(OUT_CUSTS) as PEAK_OUT by DISTRICT] | stats values(PEAK_OUT) as PEAK_OUT, values(CURRENT_OUT) as CURRENT_OUT by DISTRICT | sort by DISTRICT | fields DISTRICT, CURRENT_OUT, PEAK_OUT

thesplunkmonkey · ‎09-06-2022

I'm not entirely clear on whether you need the line to change value or be drawn straight across like in the graphic you attached. For a static value, following the rest of your search that generates the above chart, do an eval to set a new field value to the limit your wanting to graph. For example: <YOUR SEARCH> | eval limit=300 Then under the format, Chart Overlay, click in the Overlay box and select the Limit field. This will draw that value across the chart. If you need that line's value to change depending on other factors, including time, you can just add the appropriate calculation to limit= <calculation>.

thesplunkmonkey · ‎09-06-2022

Since you're using a cluster, ensure that your sessions are persistent for UI traffic. If you look in the developer tools in your browser, you may see 404 messages being thrown for various authentication related items. This occurs when the user has logged in, but subsequent calls by the UI itself are made as the user back to the VIP and get routed to different members in the cluster that don't have the rest of your session info. Refreshing sometimes will help temporarily in this scenario if all calls happen to hit the same member.

thesplunkmonkey · ‎09-13-2019

Anytime, Dom -- that's great, glad I could help!

thesplunkmonkey · ‎09-13-2019

It may just be a typo on your comment above, but i see the path is different (reportes-splunk vs resports-splunk) from the original post. If that's a typo in the actual inputs.conf file, that could be an issue. For now, i'll assume it's just a typo on here and move on. 🙂 This may be a silly question, but after you pushed out the update to inputs.conf with the new paths, did you also either restart the UF or ensure that the inputs configs are reloaded? Are you dropping the files on a server running a UF, on an HF, or on an indexer directly? The first 256 bytes of the file are used by splunk to determine of the file it's reading is a match to a file it's already indexed. I know you say that the data is different in the reports, but do they perhaps have the same header on the report that is long enough that the first 256 bytes of the file are all the same, and therefore splunk is ignoring it because it already matches what it's got for a file in it's fishbucket? Have you checked your date/time values on the reports to ensure that they are correct, the timezone is correct, etc? If that's wrong, you could be seeing your data indexed either in the past or the future, and outside of your expected search date/time range which may make it appear to be missing. Looking forward to your response.

thesplunkmonkey · ‎09-13-2019

As long as the path you are putting in your monitor stanza matches the path and pattern that would include those older files, it should read them in. So, for example, if you have files in /ijk/lmn/ called opt.log, opt1.log, opt2.log qrs.log, qrs1.log, etc, then your monitor stanza should be something like... [monitor:///ijk/lmn/] ...in order to pick up all of the files inside of the lmn directory. In that example of files I list above, and the example of the monitor stanza you stated in your last comment, you would be missing all of the older files because you have it watching only a specific filename (/ijk/lmn/opt.log). If you have files that are perhaps log rotated to a different filename, like adding a .1, .2, .3, etc to the end, or have a dated file that rotates on a regular basis, then you'll need to account for those file name differences. something like [monitor:///ijk/lmn/opt*.log] may be appropriate. The default for ignoreOlderThan is to be unset, meaning there is no threshold and no files are ignored for modification time reasons. So otherwise, your stanza settings should be fine. You may also need to consider if the older files may appear to be identical to the new files as far as their content goes. By default, the input only performs CRC checks against the first 256 bytes of a file. This behavior prevents the input from indexing the same file twice, even though you might have renamed it, such as log rotation, for example. So if your log files happen to have a long 'header' in them that is the same for every file, they may be seen as 'identical'. in that case you may need to set a crcSalt attribute on your stanza to have it consider the files different if the filenames are different. in that case you'd use crcSalt = <source> (literally the string '<source>'). Just be careful if your filenames start out with otp.log and when rolled end up becoming a file called opt1.log, for example, because then your files will be indexed a second time when they role.

thesplunkmonkey · ‎09-13-2019

Hey @dominiqued, just checking in to see if that worked out for you or you have any follow up questions.

thesplunkmonkey · ‎09-13-2019

Hey @alex387, just following up to see if you got the answer you need.

thesplunkmonkey · ‎09-12-2019

Yes. If you want those older files, then you would leave off the ignoreOlderThan attribute that I mentioned. It will read in and index all files, old and new, that match your monitor stanza path, generally reading in the oldest files first and moving forward through the newer files.

thesplunkmonkey · ‎09-11-2019

It's hard to say given the limited information. But you seem to be lacking a couple if /. Monitor stanza should be monitor:// followed by the monitored path /data01/reports-splunk. Try: [monitor:///data01/reports-splunk] If that's not it, please provide some more info about the files being monitored.

thesplunkmonkey · ‎09-11-2019

My preference has always been to perform the base installation of the UF on the clients with the deployment server defined (as your seem to be doing), and then as opposed to placing any other configs directly on the server, push all of your inputs and configs by way of your deployment server. You can define serverclasses based on OS, and push base windows inputs out to all of your windows servers. For example: serverclass.conf [serverClass:WindowsServers] machineTypesFilter=windows* whitelist.0=* [serverClass:WindowsServers:app:BaseWindowsInputsApp] restartSplunkd=1 And then define your inputs.conf and wmi.conf or other config files in the BaseWindowsInputsApp, to be pushed out by the Deployment Server as the UFs phone home after initial installation. Doing it this way allows you to more easily change the configs on the fly as needed without having to touch them again with SCOM.

thesplunkmonkey · ‎09-11-2019

There is! Check out this doc: https://docs.splunk.com/Documentation/Splunk/7.3.1/Admin/Inputsconf [script://<cmd>] interval = [<decimal>|<cron schedule>]

thesplunkmonkey · ‎09-11-2019

Depending on how you set up your inputs, and how much historical data is on the source system, what you are probably seeing is the older data being indexed and splunk gradually moving it's way forward in time through the files. If you continue to search periodically, you will probably see new data coming in as time goes on as splunk reads those older files and gets it indexed in. Unless you have a truly enormous amount of historical data, or you have issues with bandwidth from the UF, you should see it start to catch up. You could also try running a real-time search to watch as new events are coming in, if you have access to run that type of search. I wouldn't recommend running it long term or across a large amount of data, but it can be helpful for watching these types of ingestion situations to ensure that you're still getting data in, and that it hasn't stalled. If you want to have your input stop looking at the older files, you can set a limit on the input. For example, if you want it to only go back a maximum of 5 hours, you can do something like this. inputs.conf [monitor:///path/to/files] ignoreOlderThan = 5h https://docs.splunk.com/Documentation/Splunk/7.3.1/Admin/Inputsconf

thesplunkmonkey · ‎09-06-2019

Not within the same cluster. You would need to split your sites into different clusters. A & B with one cluster master, and C with a separate cluster master. You can still search both, as if they are 'all the same' from the search head perspective. Just add stanzas for both of the cluster masters in server.conf [clustering] mode = searchhead master_uri = clustermaster:clusterAB, clustermaster:clusterC [clustermaster:clusterAB] master_uri = https://master_for_site_AB.com:8089 multisite = true [clustermaster:clusterC] master_uri = https://master_for_site_C.com:8089 multisite = true I would suggest using multisite, even for the Site C Only cluster, in case you want to stand up additional sites for that cluster later, or want to merge them later (If don't want a bunch of standalone buckets to deal with in that situation). In order to split those forwarders out to the various sites on the indexer side, you can use a deployment app for the UFs that includes an outputs.conf file which would have a different [tcpout] stanza between the two apps. For example: SiteAB_Outputs_app inputs.conf: [tcpout] defaultGroup=AB_indexer_group [tcpout:AB_indexer_group] server= siteA_idx_1:8089,siteA_idx_2:8089,siteB_idx_3:8089,siteB_idx_4 (etc...) SiteC_Outputs_app inputs.conf [tcpout] defaultGroup=C_indexer_group [tcpout:C_indexer_group] server= siteC_idx_1:8089,siteC_idx_2:8089,siteC_idx_3:8089,siteC_idx_4 (etc...) serverclass.conf [serverClass:SiteAB_Outputs] whitelist.0=uf_hostname1 whitelist.1=uf_hostname2 ...etc... up through 100 [serverClass:SiteAB_Outputs:app:SiteAB_outputs_app] restartSplunkd=1 [serverClass:SiteC_Outputs] whitelist.0=uf_hostname101 whitelist.1=uf_hostname102 ...etc... up through 200 [serverClass:SiteC_Outputs:app:SiteC_outputs_app] restartSplunkd=1 Or if you have some other way to identify those UFs in order to split them, like perhaps using a clientName value, or wildcarding the hostname, or by OS, etc, you could use that instead of the individual whitelist.# whitelisting. Or even use an 'external' whitelist file similar to this: [serverClass:SiteC_outputs] whitelist.from_pathname = /path/to/whitelists/filename.list filename.list host1 host2 host3 host4 ...etc...

thesplunkmonkey · ‎09-04-2019

In your input form you are using the element to trigger setting the tokens. While this works great on a single form/dashboard, it doesn't work when pulling the values of the form in from a url because there is no CHANGE event to trigger the condition. The page is simply loaded with the values set. However, you CAN do what you're looking for, if I understand it correctly. First of all, if you also want to be able to manipulate the panels from the dropdown on dashboard2, then keep everything that you have in place on the second dashboard. That should all work fine. But to do what you're asking to pull the values essentially from a URL you need to change what you're doing with dashboard1. Instead of passing just passing the value of the TYPE field, you also need to pass the token you want set into the second dashboard to have them influence the show/hide condition of the panels. These should be added to the URL for the drilldown from dashboard1. <dashboard> <label>Dashboard1</label> <row> <panel> <table> <search> <query></query> <earliest>-60s</earliest> <latest>now</latest> </search> <option name="drilldown">cell</option> <option name="refresh.display">progressbar</option> <drilldown> <link target="_blank">/app/*/island_branches_wip__drilldown_lbil_dashboard?form.tkntime.earliest=$earliest$&form.tkntime.latest=$latest$&form.type=Island+Island&show_islandisland=true</link> </drilldown> </table> </panel> </row> </dashboard> In the above xml, you'll notice that I added "&show_islandisland=true" to the URL. I set the value to true, but that isn't really what matters. You could set that to anything you want and it will work. But the presence of that token in the URL will cause the panel that depends on that token to appear. In the example Dashboard1 above, you could change the URL to call Dashboard2 below with any of the following to get the appropriate panel. <link target="_blank">/app/*/island_branches_wip__drilldown_lbil_dashboard?form.tkntime.earliest=$earliest$&form.tkntime.latest=$latest$&form.type=Island+Island&show_islandisland=true</link> <link target="_blank">/app/*/island_branches_wip__drilldown_lbil_dashboard?form.tkntime.earliest=$earliest$&form.tkntime.latest=$latest$&form.type=UK+Island&show_ukisland=true</link> <link target="_blank">/app/*/island_branches_wip__drilldown_lbil_dashboard?form.tkntime.earliest=$earliest$&form.tkntime.latest=$latest$&form.type=Island+UK&show_islanduk=true</link> . <form> <label>Dashboard2</label> <fieldset submitButton="false"> <input type="dropdown" token="type" searchWhenChanged="true"> <label>Island Branch Type Search</label> <default>*</default> <choice value="Island Island">Island+Island</choice> <choice value="Island UK">Island+UK</choice> <choice value="UK Island">UK+Island</choice> <change> <condition value="Island Island"> <set token="show_islandisland"></set> <unset token="show_islanduk"></unset> <unset token="show_ukisland"></unset> </condition> <condition value="Island UK"> <unset token="show_islandisland"></unset> <set token="show_islanduk"></set> <unset token="show_ukisland"></unset> </condition> <condition value="UK Island"> <unset token="show_islandisland"></unset> <unset token="show_islanduk"></unset> <set token="show_ukisland"></set> </condition> </change> </input> </fieldset> <row> <panel depends="$show_islanduk$"> <event> <search> <query>|your queryhere</query> <earliest>-1m</earliest> <latest>now</latest> </search> </event> </panel> <panel depends="$show_islandisland$"> <event> <search> <query>|your queryhere</query> <earliest>-1m</earliest> <latest>now</latest> </search> </event> </panel> <panel depends="$show_ukisland$"> <event> <search> <query>|your queryhere</query> <earliest>-1m</earliest> <latest>now</latest> </search> </event> </panel> </row> </form>

thesplunkmonkey · ‎09-03-2019

There's other ways to do this, but here's one possibility for you -- Based on your sample data, it seems you would know the possible values ahead of time. If that's the case, you could use an eval to assign the value to a field you want. ... | eval field2=if(field1 == "Failed", field1, "") | eval field3=if(field1 == "Success", field1, "") | table ip field2 field3 This would give you the following, given the data you provided. ip field2 field3 1.1.1.1 Success 2.2.2.2 Failed 1.1.1.1 Failed

thesplunkmonkey · ‎09-03-2019

In authorize.conf (or through UI) create a new role for your AD group to map to. In authentication.conf (or through UI) map that other AD group to that role that will be used to restrict access. This role will be different from YOUR role, which will not be restricted (I will assume the ADMIN role here) but you'll need to know your role as well. authorize.conf [role_admin] #other configs that are relevant to your environment [role_restricted_access_role_name] importRoles = appropriate_roles_for_your_environment #other configs that are relevant to your environment authentication.conf [roleMap_AD_Strategy_Name] admin = YOUR_AD_GROUP_NAME restricted_access_role_name = RESTRICTED_AD_GROUP_NAME Then you'll need to set up metadata configs that will allow you to limit who can have read access in each of those apps. Inside of the app that you don't want to have this restricted group view, make a metadata folder, and then add a default.meta file. $SPLUNK_HOME/etc/apps/RestrictedSearchHeadAppName/metadata/default.meta [] access = read : [ admin, other_allowed_roles ], write : [ admin, other_allowed_roles ] With the above configs, anyone in the admin and other_allowed_roles roles and associated AD groups would have both read and write access to the RestrictedSearchHeadAppName app, but anyone that is in the restricted_access_role_name role would not be able to access or even see that search head app.

Posts	24
Solutions	4
Karma Given	0
Karma Received	4
Member Since	‎07-12-2019

Online Status	Offline
Date Last Visited	‎07-24-2023 11:25 AM

Re: How to run comparison after a group by?

Re: How to persist fields after group by command?

Re: Why is Splunk is not showing the menu and the ...

Re: Why is Splunk is not showing the menu and the ...

Re: Why is Splunk is not showing the menu and the ...

Re: Why is Splunk is not showing the menu and the ...

Re: How to get a peak count while still including ...

Re: How to add a horizontal line to a column chart...

Re: Why is Splunk is not showing the menu and the ...

Re: Deployment Splunk Universal Forwarder

Re: Why does my Splunk is not indexing all the fil...

Re: Why is newly configured ingestion not showing ...

Re: Deployment Splunk Universal Forwarder

Re: Extract multiple values from a single field in...

Re: Why is newly configured ingestion not showing ...

Re: Why does my Splunk is not indexing all the fil...

Re: Deployment Splunk Universal Forwarder

Re: Remote Script execution crontab ?

Re: Why is newly configured ingestion not showing ...

Re: Multi site cluster (3 sites) with a site separ...

Re: Drilldown to hidden/show panels not showing ba...

Re: Extract multiple values from a single field in...

Re: How do I restrict which apps are visible to a ...