Apply Checkmk piggyback name translation to the producing host

Bottom line: Match producer-side translation rules and exact case-sensitive monitored host names before diagnosing orphaned piggyback data; receiving data alone does not create the monitored target.

Source fact: what the authority says

The Checkmk piggyback guide requires the target host to exist in monitoring before its received piggyback data can be processed as that monitored host. Name assignment requires an exact case-sensitive match, and target names beginning with a dot are not processed. The translation rule’s condition must match the producing piggyback host, not the target receiving the translated name. The documented cmk-piggyback list orphans command lists objects with received data but no corresponding monitored host.

What the source does not establish

This article reviews producer-side translation and target identity, not a complete dynamic-host lifecycle. It does not approve automatic host creation, stale-data retention or every distributed forwarding topology.

Applicability questions

• Which host produces the piggyback data and which monitored host should receive it?
• What exact source name and target name are involved, including case?
• Does the translation rule match the producing host?
• What actual orphaned-object evidence exists before changing collection?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends a producer-to-target map with original object name, translated name and monitored target identity in separate columns. Have the monitoring owner reconcile the exact strings before altering collection. Keep an already received object with no matching target as an identity investigation rather than automatically treating it as missing source data.

Review the translation rule on the producer side of the map. Record the actual rule conditions and intended transformation together. Avoid applying the rule only to the target because that is where the desired service should eventually appear; require another operator to identify the producing host from the retained evidence.

Choose a harmless naming fixture that includes a deliberate case difference and an explicitly reviewed translated name. Verify target existence through the managed host workflow. Resolve a dot-prefixed or otherwise unsuitable source name through the supported translation design rather than broadening the test into automatic creation of unrelated hosts.

Preserve the original naming and rule configuration for reversal. Review any proposed transformation that maps several source names to one target with the responsible service owner. Keep stale-data handling, dynamic lifecycle policy and cross-site forwarding outside this naming correction unless they receive their own scoped assessment.

Verification and evidence

Proposed verification: inspect the approved producer’s retrieved data and compare its object name with the target map. Review the documented orphan listing in the test scope, then apply only the authorized producer-side translation. Retain the actual rule match and target identity before interpreting the resulting service population.

Compare the intended target with the deliberately mismatched naming fixture and record actual case-sensitive mapping observations. Keep target creation, data receipt and successful interpretation as separate checkpoints. Preserve sanitized source/target names, rule revision and unresolved orphans without claiming every distributed or automatically created host was covered by the exercise.

Official references

• Checkmk — The piggyback mechanism — official product documentation; confirm the installed release and configuration.

Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.