Skip to main content
Lantern Home

 

Splunk Lantern

Using best practices for developing Splunk apps

  1. Last updated
  2. Save as PDF

Splunk apps allow you to extend the Splunk platform so you can more easily get value from your data. There are hundreds of apps (supported and not) already on Splunkbase, but as you mature in your practice, you'll likely find you need to develop your own in order to accomplish your use cases efficiently. This article offers a quick list of best practices to use during your app development process so that they function as expected and to help you avoid common pain points.

Ease of use and troubleshooting best practices

Use standard return codes 

In an app, return codes (also known as exit codes) are the numerical values that a script or process sends back to the Splunk engine (specifically splunkd) to indicate whether it ran successfully. Do not use custom codes. The standard is:

  • 0 = success
  • Non-zero = error 

If you set a return code to something else, for example the number of rows a process read, troubleshooting can become difficult, especially if you don't have access to read the source code of the application. 

Place logs wisely

    [1]Always write the logs to /var/login the Splunk platform. This makes debugging easy. For additional logging best practices, see Logging best practices in an app or add-on for Splunk Enterprise.

    Don't access other directories in other apps

    You can share data between apps with a REST endpoint or file, and this is very convenient. However, doing so can cause a number of problems:

    • Troubleshooting the application becomes difficult. It can be hard to figure out what app is referenced.
    • Sharing requires certain assumptions about how the secondary app is being used in the Splunk platform. Your assumptions might be wrong, and if so, you won't get the functionality or results you expect.
    • If app permissions change or the app gets isolated, you can break your entire workflow. 

    Instead of sharing, you should place all knowledge objects inside the app directory.

    Document and test apps

    Add clear documentation and automated tests to ensure your app is reliable, maintainable, and easy to support. People leave roles and organizations, and when they do, it can be hard to maintain or troubleshoot what they developed without clear documentation.

    Security best practices

    Manage knowledge object permissions

    Securely share and control access across users and roles by using RBAC. Managing permissions using role-based access control is more efficient than managing permissions on an app-by-app basis.

    Protect credentials

    Never hard-code credentials in your app. Make sure you store them securely using the encrypted storage options provided. It's important to make this a part of your development practice because even using AppInspect to verify proper password storage isn't fail proof.

    Validate inputs

    Always validate user and external inputs to prevent errors and security vulnerabilities. Make sure data conforms to the form you expect. An attack in an app can bring down a whole Splunk instance. For more information on input validation, see Validate the quality of Splunk apps and add-ons for Splunk Cloud Platform or Splunk Enterprise using Splunk AppInspect.

    Additional resources

    Now that you have an idea of some of the basic principles of building a Splunk app, watch the full .conf25 talk, Splunk extension points: Where to find and how to use them. In the talk, you'll learn about some of the common extension points that you might want to include in your app. 

    In addition, these resources might help you implement the guidance in this article: