Skip to content

Deployment Configuration

values.yaml is the main point of SC4SNMP management. The most important variables are already there from the very beginning after executing:

microk8s helm3 inspect values splunk-connect-for-snmp/splunk-connect-for-snmp > values.yaml

The whole file is divided into the following components:

  1. scheduler - more detail scheduler configuration
  2. worker - more detail worker configuration
  3. poller - more detail poller configuration
  4. sim - more detail sim configuration
  5. traps - more detail trap configuration
  6. mongodb - more detail mongo configuration
  7. redis - more detail redis configuration

Shared values

All of the components have the resources field for adjusting memory resources:

  resources:
    limits:
      cpu: 1000m
      memory: 2Gi
    requests:
      cpu: 1000m
      memory: 2Gi

More information about the concept of resources can be found in the kuberentes documentation.

Update Inventory and Profile

Inventory and profiles in values.yaml is quite expensive from the Splunk Connect for SNMP perspective. It requires several checks before applying changes. SC4SNMP was designed to prevent changes in inventory and profiles task more often than every 5 min.

When changing inventory or profile needs to be applied in values.yaml following steps need to be done:

  1. Edit values.yaml
  2. Check is inventory pod is still running by an execute command
microk8s kubectl -n sc4snmp get pods | grep inventory

If the command does not return any pods, follow the next step. In another case, wait and execute the command again until the moment when inventory job finishes.

If you really need to apply changes immediately, you can get around the limitation by deleting inventory job, with:

microk8s kubectl delete job/snmp-splunk-connect-for-snmp-inventory -n sc4snmp

After running this command, you can proceed with upgrading without a need to wait.

  1. Run upgrade command described in Installation Guide

NOTE: If you decide to change frequency of the profile without changing inventory data, the change will be reflected after next walk process for the host. Walk happens every walk_interval or on any change in inventory.