Splunk IT Service Intelligence: Dynamic Service Creation Overwrites all KPIs

[sail4lot]

Hi all-

We have a dynamic environment that I was hoping to use the service importer (via a search) to keep updated. The search I have running gives me the services I want each time it runs, but if there already is a service with that name, it seems to recreate the entire service with new KPI references. This results in our glass tables breaking and the KPI ID changing so historical data is lost.

Is this operating correctly? Is there a way to fix it?

We are on 3.1.4 at the moment.

Thanks!

[esnyder_splunk]

Try checking $SPLUNK_HOME/etc/apps/SA-ITOA/local/inputs.conf (or shcluster/apps/itsi/local/inputs.conf if you're on a SHC).

Locate the stanza for the recurring import and make sure 'update_type' is set to UPSERT or REPLACE, and not APPEND. If it's set to APPEND you'll get duplicates.

update_type = APPEND|UPSERT|REPLACE
* The update/insertion method when uploading entities.
* This setting is required, and the input will not run if the setting is
not present.
* APPEND: ITSI makes no attempt to identify commonalities between entities.
All information is appended to the table.
* UPSERT: ITSI appends new entries. Existing entries (based on the value
found in the title_field) have additional information appended
to the existing record.
* REPLACE: ITSI appends new entries. Existing entries (based on the value
found in the title_field) are replaced by the new record value.
* There is no default.

https://docs.splunk.com/Documentation/ITSI/latest/Configure/inputs.conf

[sail4lot]

@esnyder. Thanks for the response.

We've since upgraded to 4.1.2 and look forward to 4.4, but the issue still appears to remain. Specifically, when you set up recurring service imports (as upserts), the KPI and Service Id's appear to get regenerated each time the service import is completed.

To test this, we had created a glass table based off a variety of KPIs for a service we knew would get 'upserted' in the next run. The service itself did not get duplicated (implying an upsert). However, the glass table reverted all KPIs to ad-hoc searches, the IDs for the service KPIs in the itsi_summary index were different, and the kpi history (in SA sparklines) gets zero'd out back to the most recent run.

Could this simply be a bug?