I got an ask from one of my Splunk users wondering if we can expose the Dropped packet count from network interfaces. I took a look at the TA for nix, and it doesn't seem like it is doing that today. Is there an alternate way to gather that information from our *nix based hosts? ... View more

I had an interesting request today from a team who was looking to enhance their Splunk dashboard by allowing for a manual trigger of an Alert. We currently have a custom alert set up that essentially does an snmp trap over to some of our alert monitoring tools. Most teams are using this alert in the typical fashion (i.e. scheduled searches that trigger alert on specific value). However this one team needs more of an ad-hoc alerting. They have their engineers analyze some of the data that they are reporting on, and until they come up with the appropriate algorithms and such to automate via schedules and the like, they would like to have a button that would actually kick off the alert action. Is this possible? ... View more

Hi all; I have to decomission our current deployment server (forwarder configs) and was hoping to get an extra set of eyes on the work that I plan on doing: INSTALL Splunk on new server COPY server classes to new server COPY ALL deployment-apps over to new server UPDATE the app with the client config on the new server to point to the new server UPDATE the app with the client config on the old server to point to the new server RELOAD the old deploy server My expectation here is that the reload will re-push the updated deploymentclient.conf file out to all the servers, which will in turn restart the forwarders and make them connect to the new server. ... View more

Hi folks; I have the following query that i use as a base search to feed a dashboard: index=app_caspectrum sourcetype="spectrum:event" source="prod_spectrum_reporting" | join event_key [ search index=app_caspectrum sourcetype="spectrum:alarm" source="prod_spectrum_reporting" | rename orig_event_key as event_key | join type=left alarm_key [ search index=app_caspectrum sourcetype="spectrum:alarm:activity" source="prod_spectrum_reporting" | rename time as activity_time | rename user as activity_user | transaction alarm_key | eval LastStatus=mvindex(activity_s, -1) | table alarm_key LastStatus ] ] There are several fields that are part of each event that is produced as they are the fields from each subsearch for the related event_key's and whatnot. The problem however, is when I go and 'collect' this data and put it in my summary index, it only seems to be 'collecting' the fields from the first search. The fields that were added as a result of the joins are not being added. I have even tried something silly like this : index=app_caspectrum sourcetype="spectrum:event" source="prod_spectrum_reporting" | join event_key [ search index=app_caspectrum sourcetype="spectrum:alarm" source="prod_spectrum_reporting" | rename orig_event_key as event_key | join type=left alarm_key [ search index=app_caspectrum sourcetype="spectrum:alarm:activity" source="prod_spectrum_reporting" | rename time as activity_time | rename user as activity_user | transaction alarm_key | eval LastStatus=mvindex(activity_s, -1) | table alarm_key LastStatus ] ] | fields condition_name condition_name is a field that is added to each event from one of the join's. Once this is added to a summary index, condition_name isn't there. ... View more