Troubleshooting Manual

 


How to file a great Support case

How to file a great Support case

This page is a work in progress.

When you're contacting Support, you can save time by starting out with everything we'll need!

Here are some ideas to get you started.

Describe the issue

Where does the issue occur? On a forwarder? On an indexer?

What elements are present for the issue? What's the timeline leading to the error? What processes are running when the error appears?

What behavior do you observe, compared to what you expect? Be specific - for example, how late is "late"?

Try to classify the problem:

  • Is it a searching issue? These include Splunk Web, management, roles, apps, views and dashboards, search language.
  • Is it a back end issue? These problems could include crashing, OS issues, REST API, or SDK.
  • Is it a configuration issue? These include extractions, input configurations, forwarding, apps disabling, or authentication.
  • Is it a performance problem?

Send diagnosis files

Most often, a support case is opened in response to a functional problem, i.e. Splunk has been configured to do 'something' but it is behaving in an unexpected way.

Splunk Support needs both the context of the problem and insight into the instance that is not performing as expected. That insight comes in the form of a "diag," which is essentially a snapshot of the configuration of the host server, the Splunk instance, and the recent logs of that instance.

Whether your problem is with a Universal Forwarder, an Indexer a Search Head or a Deployment Server instance, send us your diag! If you have a forwarder and a receiver that aren't working together correctly, send us diags of both! (If you have many forwarders, just send one representative forwarder diag.)

The diag tarball or .zip does not contain any of your indexed data, but if you do have concerns then please go ahead and extract yourself to examine the contents. Read about making a diag in this manual.

Please note that Splunk Support might request another diag after recommending a change or update to the instance. This is done to ensure the change has been applied and verify the impact, if any, to the instance. It is not unusual to have multiple updated diags for a single case.

Splunk Support also understands that it is not always straightforward to collect a diag from certain machines, due to a variety of restrictions. If this is the case with your environment, please detail that in your case and we will adjust our approach & requests accordingly.

This documentation applies to the following versions of Splunk: 4.2.3 , 4.2.4 , 4.2.5 , 4.3 , 4.3.1 , 4.3.2 , 4.3.3 , 4.3.4 , 4.3.5 , 4.3.6 , 4.3.7 , 5.0 , 5.0.1 , 5.0.2 , 5.0.3 , 5.0.4 , 5.0.5 , 5.0.6 , 5.0.7 , 5.0.8 , 5.0.9 , 6.0 , 6.0.1 , 6.0.2 , 6.0.3 , 6.0.4 , 6.0.5 , 6.1 , 6.1.1 , 6.1.2 , 6.1.3 View the Article History for its revisions.


You must be logged into splunk.com in order to post comments. Log in now.

Was this documentation topic helpful?

If you'd like to hear back from us, please provide your email address:

We'd love to hear what you think about this topic or the documentation as a whole. Feedback you enter here will be delivered to the documentation team.

Feedback submitted, thanks!