Skip to content

[HWORKS-2912] Service logs are silently dropped from .services: unbounded Kubernetes pod and node labels exhaust the 1000-field mapping limit - #638

Open
o-alex wants to merge 1 commit into
logicalclocks:mainfrom
o-alex:HWORKS-2912
Open

[HWORKS-2912] Service logs are silently dropped from .services: unbounded Kubernetes pod and node labels exhaust the 1000-field mapping limit#638
o-alex wants to merge 1 commit into
logicalclocks:mainfrom
o-alex:HWORKS-2912

Conversation

@o-alex

@o-alex o-alex commented Aug 25, 2026

Copy link
Copy Markdown
Contributor

Adds a Service Log Labels page documenting which Kubernetes labels are attached to service logs by default, and how to append to or replace that set.

Read docs/setup_installation/admin/monitoring/services-logs-labels.md; the mkdocs.yml change is its nav entry.

Why

The chart change in logicalclocks/hopsworks-helm#2241 stops filebeat attaching every pod and node label to each log document, because each distinct key becomes a field in the shared .services-* index and the index stops accepting documents once it passes 1000 fields. That makes the kept set part of a cluster's configuration surface: an operator who labels their own workloads for routing cannot tell from the outside which keys survive collection, and a label that does not survive fails silently.

The page therefore documents the defaults as tables with a purpose per key (25 pod, 2 namespace, 1 node), the append and replace paths, annotations and the deployment/cronjob names, and the dedotting rule, since searching Dashboards for a dotted key such as kubernetes.labels.app.kubernetes.io/name returns nothing and gives no hint why.

It also carries the warning that four defaults are read by the collection itself rather than by a pipeline, so replacing a base list without them stops filebeat excluding its own logs or stops project namespaces being collected, with no error either way.

Verification

npx markdownlint-cli2 reports 0 errors on the new file. A strict build (uv run mkdocs build -s) completes with 0 errors and 0 warnings and emits the page. Note that the strict build requires uv pip install "git+https://github.com/logicalclocks/hopsworks-api.git@main#subdirectory=python" first, per .claude/CLAUDE.md, otherwise it fails on hopsworks_common in the API reference section.

Risk and rollout

Documentation only. The page describes values that ship in the linked chart PR, so it should land with or after it.

Rollback:

git revert <merge-commit>

@o-alex
o-alex force-pushed the HWORKS-2912 branch 3 times, most recently from 8d790c5 to b21e294 Compare August 31, 2026 14:21
…nded Kubernetes pod and node labels exhaust the 1000-field mapping limit

https://hopsworks.atlassian.net/browse/HWORKS-2912

filebeat attaches Kubernetes metadata to every service log document, and
the chart now keeps only an explicit set of pod, namespace and node labels
so the shared `.services-*` index cannot exhaust OpenSearch's 1000-field
mapping limit and start dropping logs. That makes the kept set part of a
cluster's configuration surface: an operator who labels their own
workloads for routing cannot tell from outside which keys survive
collection, and a label that does not survive fails silently.

Document the default sets as tables with a purpose per key, and the three
lists each dimension takes: the mandatory keys the chart unions in
regardless, the base list that replaces the rest, and the extra list that
appends. Record the traps that produce silent failures rather than errors.
A replacement drops the other default keys, each of which drives a routing
branch. Overriding `logs_locations` drops `addKubernetesMetadata` with it,
since Helm replaces lists, which leaves log lines arriving while every
pipeline branch routing on `kubernetes.*` stops matching. Searching
Dashboards for a dotted key returns nothing because label keys are dedotted
on the document. Annotations and the deployment/cronjob names are covered
as opt-ins, and Services Logs links here, since that is the page a reader
arrives from.

Signed-off-by: Alex Ormenisan <alex@logicalclocks.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@o-alex
o-alex requested a review from manu-sj August 31, 2026 14:36
@o-alex
o-alex marked this pull request as ready for review August 31, 2026 14:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant