Hello Spelunkers
Did anyone tried the approach to import services using recurring import job .
For example , using CSV as definition for , services - dependent services - entities - service template , then import the same on a schedule , to make sure no unwanted changes affect any service design .
I am facing issue while doing the same , "replace" update type not working , its always doing a "upsert" , which means if I remove any entity from CSV its not getting removed from the entity rule ..
is this is a bug or Splunk don't have the conflict resolution applied for "Service import job" , only for "entity import" ... let me know your views ......
Do you specialise exactly which entities you want in the entity filter? and then use scheduled service imports to change that? I have not tried that.
One option as a walkaround could be to have more generic entity filter and instead use info fields of entities to pass the filter or not. I.e. let a scheduled import/update of the entities define whether they qualify for being used by the services.
/Seb
Hello @srauhala_splunk
Thanks for your reply.
Correct, we are trying to use lookup as source for service design, which has all the details (service name//dependent services//entities//service template) .
Now, the problem is, the import job is not "replacing." the entity, which is removed from lookup, instead its always "updating" the event rule.
Example -- A, B, C in the entity list. --> Added D in the lookup and removed C from the lookup --> now we can see, A, B, C, D, in the event rule, which should not be the case.
We have also changed the ..import.type = replace from advance edit, but still issue remains the same.
Okey @taparshi1.
Looking around in the documentation and in the UI this use case does not seem to be supported. Please add it to https://ideas.splunk.com.
However in you situation I would solve it slightly different. You can manage information fields of the entities to achieve the same result.
Service Template: my_database_service_template For example create a service using a service template where you defined a set of entity filters. At the time you run the service import job you will set these filters to match a value from your CSV.
Simple Example:
Service name: my_oracle_db
Service Template: my_oracle_db_service_template
Entity filter: my_entity_type:oracle_db, my_qualifier_info_field:true
With the above setup you can instead manipulate the info field "my_qualifier_info_field" of the entities to activate / deactivate entities from your service. The qualifier for true/false can in turn be managed in a lookup, that in turn are used doing scheduled updates / imports of entities. This decouples the service from fixed list of entity host names and makes it adaptable to entities available that passes the entity filter.
/Seb