Upgrade - Syslog (QRadar) | Outcold Solutions

In most cases, an upgrade is just a new Collectord image - but if you want the new features that ship with a release, you’ll also need to update your configuration. Track what’s new on our blog and in the Release history. The manifests are rendered from the Helm charts in outcoldsolutions/collectord-helm-charts, which has a commit for each chart version: compare the collectord-syslog chart’s values.yaml between two of them to see what changed in the configuration.

If you get stuck, or want a hand planning an upgrade, contact support - we’ll help and guide you through it.

Upgrade from version 26.04 to 26.10

Version 26.10 brings together work we started in 2019 that kept waiting on other changes. For the syslog forwarder, it brings one DaemonSet instead of two, which reads the API server’s audit logs by default, journal lines sent once instead of twice now that /var/log/syslog and /var/log/messages are no longer read (Host logs says how to read them again), and Collectord pods the kubelet doesn’t evict when a node runs short of disk. We held each new input to what it adds to what your SIEM receives, and an upgrade keeps sending your data to the same syslog server.

Upgrade the collectorforkubernetes image (on OpenShift, collectorforopenshift) to version 26.10.X. Collectord now runs as one DaemonSet instead of two, so read the steps for your deployment method before you upgrade.

With Helm

helm upgrade removes the -master DaemonSet. Until its pod on a control-plane node stops, the new DaemonSet pod there may restart a few times with the data path ./data/ is locked by another collectord instance; it then continues from the same state, so file positions carry over.
Values under collectord.daemonsetMaster and collectord.configMap.daemonsetMasterAdditionalFiles are no longer read: move them under collectord.daemonset and collectord.configMap.daemonsetAdditionalFiles.
The DaemonSet now runs under the built-in system-node-critical priority class and the addon under system-cluster-critical, and the chart deletes the <release>-critical PriorityClass (collectorforkubernetes-syslog-critical). To keep the old class, set collectord.priorityClass.name to its name.

With the manifest

Download the 26.10 manifest, collectorforkubernetes-syslog.yaml (on OpenShift, collectorforopenshift-syslog.yaml), and set your values in it again, as Installation shows: the license, the cluster name and the syslog output in 001-general.conf.
Carry over your changes. For each key you changed in the old manifest’s 002-daemonset.conf, 003-daemonset-master.conf or 004-addon.conf, set it in the matching section of the new file; what you changed in 003-daemonset-master.conf goes into 002-daemonset.conf.

Apply it:

bash

1kubectl apply -f ./collectorforkubernetes-syslog.yaml

On OpenShift:

bash

1oc apply -f ./collectorforopenshift-syslog.yaml

Delete the old DaemonSet and PriorityClass right away. kubectl apply doesn’t delete what the manifest no longer contains:
bash
```
1kubectl delete daemonset collectorforkubernetes-syslog-master -n collectorforkubernetes-syslog
2kubectl delete priorityclass collectorforkubernetes-syslog-critical
```
On OpenShift:
bash
```
1oc delete daemonset collectorforopenshift-syslog-master -n collectorforopenshift-syslog
2oc delete priorityclass collectorforopenshift-syslog-critical
```
Until you delete the old DaemonSet, its pods keep the control-plane nodes on the old configuration, and the new DaemonSet pod on each of them restarts with the data path ./data/ is locked by another collectord instance. Delete it only after applying the new manifest: the old manifest’s DaemonSet skips the control-plane nodes, so without the new one nothing collects there, the API server’s audit logs included.
On OpenShift, remove the privileged SCC. The manifest now carries its own SecurityContextConstraints, so the privileged SCC you granted its service account can go: oc adm policy remove-scc-from-user privileged system:serviceaccount:collectorforopenshift-syslog:collectorforopenshift-syslog.

Upgrade from version 25.10 to 26.04

Upgrade the collectorforkubernetes image (on OpenShift, collectorforopenshift) to version 26.04.X. Review the Kubernetes configuration or OpenShift configuration reference for any new fields you want to pick up.

Upgrade from version 5.24 to 25.10

Upgrade the image to version 25.10.X. The version scheme switches from semver (5.X) to YY.MM in this release.

Upgrade from version 5.23 to 5.24

Upgrade the image to version 5.24.

Older versions

For Collectord versions from 5.20 to 5.23, see the Monitoring Kubernetes upgrade guide - the same Collectord binary powers both products and the per-version upgrade notes apply equally, with one exception: there’s no Splunk app to upgrade in lockstep, so you can upgrade the agent image whenever you’re ready.

If you run a version before 5.20, contact support - we’ll help you plan the upgrade and guide you through it.