In this example, we’ll specify an API base URI and the API version. These will be the universal settings available to all inputs configured using this modular input. These are the global input parameters defined in the Add-on’s setup page. API tokens, etc).Īs this is a simple example, we will simply use “number of records to query each time” as a way to demo.įinally, we’ll define the Add-on Setup Parameters. Generally this would be where user-specific information lives (e.g. There will be one of these for each user-configured input. These are the per-instance variables configured in settings -> data inputs. Now we need to specify the data input properties. NB: Default collection interval is 30 seconds, I adjusted to 300. Follow the workflow to create a custom Python input (Configure Data Collection -> Add Data -> Modular Input Code) Step 4.1 Fortunately, the AoB custom python option provides us helper functions to do these things, as we’ll see later in this example. We’ll want to use checkpointing to see how far we read in previous queries to see if we need to read more, etc. The data itself will be returned in json format. I also notice we need to query max number of records each time, as text. Reading through it the first time I note we don’t need an API token or access key. Here is some documentation about the HackerNews API: For this example, we’ll use HackerNews, because I haven’t previously implemented it and it doesn’t require oAuth (I hope to release a Part V to review oAuth before 2017). The quicker add a data input using a REST API option may be in play. Yet here we are. You know what? This should actually be first, so you can decide how to implement this in AoB. Step 8 – Customizing The Auto Generated Codeĭownload & install Add-on Builder version 2.0, which we’ll henceforth refer to as AoB Step 6 – Custom Code Primer: Single Instance Mode Step 2 – Read through your API documentation If not, that would be a good pre-read too. You may have seen the post announcing Splunk’s Add-on Builder 2.0. They’re well described in those linked docs though, so we start where those stories lead us by expanding on Part III in this Part IV installment. Part III would have therefore described adding a data input by writing your own code. Neither did Leonard Parts I-V.įor a backstory, Part I would have used the Add-on Builder feature to Add a data input using a REST API and Part II would have used the feature to add a data input using shell commands. If you’re looking for Parts I-III of this blog, they do not strictly exist. We’ll additionally explore some caveats between test mode and final-cut behavior. In this post we will create a modular input using some custom code to have more control while also leveraging Splunk Add-on Builder’s powerful helper functions. No no, this post will simply walk you through leveraging Splunk Add-on Builder 2.0 to create custom code to query an API. This post certainly isn’t meant to replace those. There is a veritable cornucopia of useful resources for building modular inputs at, , , and more. NB: Future versions of Add-on Builder will obviate the need for some of the techniques mentioned below, most notably techniques in step #6 & step #8. In this post however, we focus on using an advanced feature of Splunk’s Add-on Builder 2.0 to write custom python while taking advantage of its powerful helper functions. Add-on Builder 2.0 provides capabilities to build modular inputs without writing any code.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |