issues after v26.01.0 update

[y0d4a]

Hi,

I upgraded to the latest version (26.1), performed a full wipe, and now I’m unable to bring the stack back online.
Specifically, Logstash and Filescan are marked as unhealthy, and OpenSearch is reporting errors.

Logstash log:

[2026-02-10T14:23:20,851][WARN ][logstash.outputs.opensearch] Could not index event to OpenSearch...
"status"=>400,
"error"=>{
"type"=>"mapper_parsing_exception",
"reason"=>"failed to parse field [related.ip] of type [ip] in document with id '260210-xQ8LnQW048njVhYZSSkmsQ'.
Preview of field's value: 'x.x.x.x,x.x.x.x'",
"caused_by"=>{
"type"=>"illegal_argument_exception",
"reason"=>"'x.x.x.x,x.x.x.x' is not an IP string literal."
}
}

Filescan log:

filescan-1 | Please specify at least one prune trigger: threshold (percentage, 1-100) with -t; or, maximum size (gigabytes, >= 1) with -m

Could you help me troubleshoot this?

Thanks.

[mmguero]

This is all after a fresh wipe of Malcolm? Hmmm... that's weird. Local (Malcolm-managed) or remote opensearch instance?

1. I'm not sure about the max_docvalue_fields_search setting being wrong, here, because the template for our network logs index already has the value set to 200. You could try going to the index template (https://<malcolm_ip>/dashboards/app/opensearch_index_management_dashboards#/create-template/malcolm_template I think is the address), then under the Summary tab click Advanced Settings and check the value there:

If that's not already set to something greater than a hundred, you can click the Configuration tab, then down to Advanced Settings and try to change it there, but be careful because a mistake there could probably screw things up pretty bad.

2. As far as that logstash log, one of your logs produced some unexpected data and that log didn't get indexed. Are those values actually x.x.x.x or did you redact them? Does that error message have more information about what the rest of the contents of the log is? Did that message show up once or is it recurring?

3. This last one is actually not fatal but it's easy enough to clean up. Edit your ./config/filescan.env file and look for FILESCAN_PRUNE_THRESHOLD_SIZE. What's it set to? If it's empty, set it to some very large value, even if you don't want it to prune extracted files (e.g., 1TB).

[y0d4a]

I was running version 25.x and upgraded using git.
I performed a wipe and then started the system again.
The wipe was necessary because I previously had disk issues;the disk was replaced, but it caused some corrupted data in PostgreSQL, which has now been fixed.

The x.x.x.x values are redacted IP addresses.

[mmguero]

If you can find the actual log line (like grepping under ./zeek-logs) that spawned the x.x.x.x,x.x.x.x event that didn't get logged I can probably fix it. It sounds very much like this bug. That's stun_nat, but the idea is probably the same.

[y0d4a]

I’m not sure what happened, but this morning everything is working fine. I’m not seeing those errors anymore, maybe it just needed more time to settle down :D