Building a Technology Add-On (TA)

If one is administering a technology solution for which one wants to forward logs (event data and perhaps metadata) to Splunk, the first thing to do is to look for a TA available from Splunkbase (or GitHub – refine search with “add-on” or “ta”). But if a TA isn’t available for the technology, one can build a TA.

Technology add-ons

A technology add-on (TA) collects and formats incoming data for use in Splunk. TAs are the most common type of add-on and are often referred to simply as “add-ons”, without a specific reference to an add-on type. But there are also “Domain add-ons” (DA) and “Support add-ons” (SA). The visualization below (from Splunk’s ES documentation) can help one understand the relationship among the various add-on types:

A TA can provide a layer of abstraction and normalization between a) data from specific technologies such as McAfee data or Juniper firewall logs and b) Splunk apps (and their reports, alerts, dashboards). TAs can achieve this in part through search-time knowledge mappings that assign fields and tags to the data to be used by the search layer.

Building a TA

• Review our “Getting Data In” doc (for high level overview) and, as appropriate, our HEC (HTTP Event Collector) doc for details on API-based ingestion.
• For development purposes, consider installing your own instance of Splunk Enterprise (as of this writing, any new install provides 60-day trial)…
  • on your desktop/laptop or test server
  • as a Docker container
  • in AWS
  • in Azure
• Splunk Add-on Builder – While not at all required, this app can help streamline the process of building an add-on. Or, to roll your own without Add-on Builder…
  • Review documentation for developing Splunk apps (regrettably, not just for add-ons, so can be a bit overwhelming)
  • Review documentation for vetting apps – especially for Splunk Cloud.
  • NOTE – Management of secure data elements (tokens, API keys, passwords, etc.) is integrated into the Add-On builder as well as helper scripts and variables. If you choose not to use the Add-On builder please take time to familiarize yourself with how to securely store and access this kind of data to ensure that the app is able to be vetted or migrated to other Splunk platforms.
• Naming conventions … for sourcetypes in particular. One of the most important naming decisions for ingesting data (for a TA) is sourcetype name. Sourcetypes will be crucial for your (and your users’) ability to add field transformations (including CIM-compliance / normalization), for example. We promote Splunk’s own naming convention guidance, but we also have some very environment-specific guidance.