![]() It would make sense to include lookups and some dashboards, prebuilt panels, modular alerts, modular visualizations.Example: Splunk Common Information Model (CIM).An SA could include lookup and summary generators to normalize and aggregate the data from many authentication systems and ask generic questions for reporting and alerting. Let’s say we’re building a security monitor and considering whether authentication attempts seem malicious or not. This includes supporting libraries and searches needed to manage a class of data. If they don’t, then they don’t need to be on Forwarders, unless there are index-time operations Many TA’s include all the IA stuff mentioned above.It would make sense to include lookups and nf.You should absolutely have nf, nf, nf, nf.Maybe goes on Forwarders and Indexers? Definitely goes on Search Heads.Example: Splunk Add-on for Symantec Endpoint Protection.A TA would be able to translate the field names provided by a vendor to field names expected by your users, as well as recognizing and tagging specific event types. In practice, many TA’s also include data collection inputs. This includes and configures knowledge management objects. It would make sense to include a binary folder, and some dashboards to do setup and configuration with.In practice, these are rare and the functionality is usually stuffed into a TA. This includes and configures data collection inputs only. Here are the possible types: IA: Input Add-on If you want to follow the best possible practice, buy Kyle Smith’s book and read that. However, these rules are breached as often as they are observed, and Splunk themselves are the most likely to ignore all of this guidance. Since I helped to write these definitions in the first place, I feel confident in stating what they should be. Right now, it’s here, but don’t be surprised if that breaks: Their definitions are not entirely well established, and have come and gone in official documentation. This is where the Splexicon definitions start and stop. ![]() The Add-on refers to administrator-only components. The App refers to the visible front-end app that a user will interact with. This is why you see the terms “App” and “Add-on” in Splunk. If you want to distribute components in a large environment, if you want to depend on shared components, if you want to avoid huge multi-function monoliths, then you start dividing apps into different types. If you just want to put some stuff together and run it on your laptop, you’re done at this point. You can put anything in them: code, knowledge management configuration, dashboard elements, libraries, binaries, images, whatever. They’re containers that you put splunk objects into. Splunk apps are folders in $SPLUNK_HOME/etc/apps. The confusion roots back to fundamental disagreements on approach that are encoded into every product the company has ever shipped, so it’s tough to recommend a meaningful change. If you’re still confused… it’s not just you. What are Splunk Apps and Add-ons? What’s the difference? Note, this is old stuff now… but legacy lives on even when new solutions become available. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |