So you've decided that you need an App? Congratulations! Now that you know that you need one, you need to decide on a few more items as well. It is important to do a little bit of planning, as even the simplest Apps can evolve into super-complicated Apps, with dashboards, saved searches, workflows, and more. Never assume "well, this'll just be a quick development", as most of the time, it is not.
First and foremost, try to determine the scope of your App. Once you have the scope planned out, try to limit the amount of scope creep that occurs, if possible. You may just be trying to perform extractions on your data, and if that is your current end goal, stop there. Don't try to build a full-blown suite on your first attempt. Build the IA, then the TA, and then move on from there. Ask yourself these questions as you try to determine your scope:
What am I trying to accomplish? Search-time extractions? Index-time parsing? Dashboards to share?
What users need access to my App? Everybody? Specific roles?
What kind of information will I be presenting? Server based? Metric based?
Who is my target audience? Business users who don't understand Splunk Processing Language (SPL), or technical users who will notice that I didn't convert MB to GB properly?
These questions can help you spark an idea of what internal resources would need to be engaged, as well as any kind of documentation and educational requirements.
Once you have determined the scope of the App, you will need to decide how and from where you will consume the data. Getting data into Splunk can happen in a very wide variety of ways. There is no set manner of input that will work on all data sources. You may have to develop a new script or modular input. Being aware of where your data is coming from is the key to getting it consumed correctly the first time. A few questions you may ask yourself could be:
Why do I need this data? Is it all completely relevant to my use case?
Where is the data? Cloud, SaaS provider, internal network?
How do I get the data? Do I already have a collector script, or do I need to engage an internal resource to write a collector/modular input?
What format is the data? Is it already extracted (or well known, like syslog) or do I need to write custom extractions?
There is a lot of data out in the wild, but not all of it may be relevant to your use case. You may find that of a service that has 100 endpoints available for data collection, you only need 10. Not only will you save on license usage, but your indexers will thank you for it as well.
Another key thought process in App development is how far you want to brand your App. Splunk has a very robust architecture and framework, providing you the ability to customize your Apps extensively. You can override any individual piece of CSS and extend the SplunkJS stack to include any number of different visualizations or third-party libraries. Additional questions you might ponder on would include:
Do I want to brand anything at all, or just stay with native Splunk?
Do I need to engage an internal graphics resource to design and create App icons? App logos?
Am I going for mobile or static desktops? What desktop size is "typical" of incoming users?
To what extent should I customize my App? Do I just change a few colors using native Splunk options or do I override CSS?
Do I need to engage a web designer to build custom CSS or HTML layouts?
There are so many options available to brand your App, but all customizations should conform to the Splunk Branding Guidelines for developers. Follow this URL to Splunk's guidelines:
Once you have the whats and the hows of the data you're going to collect, you need to figure out visualizations. How you display the information is just as important as what data you collect. Splunk comes with a variety of graphs and displays right out of the box, and can be extended quite easily to include some really cool presentations. Some of the questions posed to you might be:
Do you need a programmer to write custom modules or extend SplunkJS views and managers?
What third-party graphing or graphic libraries do you need to document, develop, or get permissions to use?
Do you need to engage a statistician to determine the best and most effective way to display your data? Some stats (such as max, mean, and min) are easy, others (such as confidence intervals and trendlines) are not.
Such a small list of questions hardly precludes any other relevant discussion within your organization. The more internal discussion that can take place, the better and more thought-out your App may turn out.
