I am unaware if this issue has been replicated by support.
SC4S v3.29.0 on OEL(RHEL) 7.9 on Docker and Podman
no PCAP
The issue is not believed to be related to external software.
Data is not lost due to the issue.
systems are 2-8 CPU, 8-32G mem
lastchance is available if needed
There are no customizations for the vmware sourcetypes.
All of the default indexes are created
We noticed last month when we ran the latest image that our vmware logs were misclassified as
index=osnix sourcetype=nix:syslog
Whereas before it was...
index=infraops sourcetype=vmware:esxlog:crond
This appears not to have impacted the other sourcetypes we have seen over the last 24 hours:
vmware:cb:protect
vmware:vgauthsvc.log
vmware-vmsvc-root
vmware-vmtools-root
We first noticed the issue when we were upgrading our sc4s images from v2->v3 a few months ago and believed it was related to 2390 so we downgraded all of our hosts to 2.46.0. We saw that 2390 merged with 2462 and was released with 2465 so we updated last night to the latest rev and the issue still occurred with the cron logs, which is why we wanted to file this report.
Some source data examples of the types of logs which had classifications change are:
Change
Environment="SC4S_IMAGE=ghcr.io/splunk/splunk-connect-for-syslog/container2:2.46.0"
to
Environment="SC4S_IMAGE=ghcr.io/splunk/splunk-connect-for-syslog/container3:latest"
Run searches for:
index=osnix sourcetype=nix:syslog
index=infraops sourcetype=vmware:esxlog:crond
Note the break in logs of the vmware:esxlog:crond logs and the new classification as nix:syslog
If it was some other odd sourcetype we could change it in the splunk_metadata.csv file, but we can't do that for nix:syslog as that is a common catchall.
Please check this GitHub issue that was raised earlier. Since crond is a very generic program, we removed it earlier and also provided a custom local parser that can be used. Please refer to this comment.
I am unaware if this issue has been replicated by support.
SC4S v3.29.0 on OEL(RHEL) 7.9 on Docker and Podman no PCAP The issue is not believed to be related to external software. Data is not lost due to the issue. systems are 2-8 CPU, 8-32G mem lastchance is available if needed There are no customizations for the vmware sourcetypes. All of the default indexes are created
We noticed last month when we ran the latest image that our vmware logs were misclassified as index=osnix sourcetype=nix:syslog Whereas before it was... index=infraops sourcetype=vmware:esxlog:crond
This appears not to have impacted the other sourcetypes we have seen over the last 24 hours: vmware:cb:protect vmware:vgauthsvc.log vmware-vmsvc-root vmware-vmtools-root
We first noticed the issue when we were upgrading our sc4s images from v2->v3 a few months ago and believed it was related to 2390 so we downgraded all of our hosts to 2.46.0. We saw that 2390 merged with 2462 and was released with 2465 so we updated last night to the latest rev and the issue still occurred with the cron logs, which is why we wanted to file this report.
Some source data examples of the types of logs which had classifications change are:
To Reproduce Steps to reproduce the behavior:
If it was some other odd sourcetype we could change it in the splunk_metadata.csv file, but we can't do that for nix:syslog as that is a common catchall.
Thanks! -Tony