Skip to content

Why is INDEXED_EXTRACTIONS = json the default configuration? #16

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mlhdeveloper opened this issue Dec 19, 2024 · 3 comments
Open

Why is INDEXED_EXTRACTIONS = json the default configuration? #16

mlhdeveloper opened this issue Dec 19, 2024 · 3 comments
Assignees

Comments

@mlhdeveloper
Copy link

https://github.com/cisco-en-programmability/splunk-apps/blob/e3479b7487a3403c0b357ff95a48023593d5dd18/Splunk-TA-cisco-dnacenter/default/props.conf#L8C1-L8C21

I'm pretty sure this doesn't follow best practices to index every field from every Cisco DNA event?

Additionally, removing that setting creates a separate problem because then the events are ingested as a JSON array which doesn't seem to be easily broken into separate events... Why wouldn't you have the script parse the results into separate JSON events first?

@mlhdeveloper
Copy link
Author

I guess no one's monitoring this repo? Unfortunate.

@zapodeanu
Copy link

The Add-on will index all data collected from Catalyst Center issues APIs. My index has the issues split, one event includes one issue:

Image

@mlhdeveloper
Copy link
Author

@zapodeanu It does index the events individually for me with the default add-on configuration. However, I'm wondering why it's configured to use INDEXED_EXTRACTIONS as the default setting, since one of Splunk's main selling points is search-time field extractions (e.g. this mention of search time extractions being preferable: To avoid this, make sure you configure field extractions only at search time (which is generally preferable) or only at index time.). It seems like we're needlessly eating up disk space by default, and there doesn't seem to be a way to configure it to not index every field without altering the scripts within the add-on, which would be a non-trivial task, and, I believe, be overwritten by any add-on updates.

@bvargasre bvargasre self-assigned this Mar 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants