# Enrich existing ContainerLog records without dropping rows that lack inventory matches

> How should missing Image and Name values be recovered when querying existing ContainerLog records?

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-204-enrich-existing-containerlog-records-without-dropping-rows-that-lack-inventory/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:28:32+00:00
- Modified: 2026-09-10T01:20:45+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: IT
- Reading time: 2 minutes

## What you need to know

How should missing Image and Name values be recovered when querying existing ContainerLog records?

## Potentially affected

Existing Azure Monitor ContainerLog records with omitted image or container-name fields and associated inventory tables.

## DSE recommendation

Preserve the original log population while adding inventory context, and keep unmatched metadata explicitly unavailable.

## Article

## Source facts

Azure Monitor’s ContainerLog troubleshooting guidance explains that Image and Name are not populated on every log line by default. It retrieves Image and ImageTag from ContainerInventory, and the name from KubePodInventory’s ContainerName, matching by ContainerID. The example uses left-outer joins so logs survive missing inventory metadata. Microsoft discourages enabling per-line enrichment on clusters above fifty nodes because it adds API-server calls and increases each collected line’s size. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/containers/container-insights-troubleshoot).

## Applicability

This is a query review for existing ContainerLog data, not a recommendation to deploy that schema for new collection. Start by confirming the actual table and the inventory records available for the investigation’s time range.

## DSE recommendation

Preserve the original log population while adding inventory context, and keep unmatched metadata explicitly unavailable. Review the ContainerID relationship and time selection instead of silently substituting a current container name. Have the query owner state whether the chosen inventory row is appropriate for the historical question. Avoid enabling broader collection merely to make a report look complete.

## Verification

Compare the un-enriched and enriched log counts using a fixed scope and time range. Inspect examples with matching inventory, missing inventory and multiple inventory observations. Confirm the result neither loses original events nor multiplies them unexpectedly through the join. Keep the selected matching logic and unmatched rows visible in the review evidence. A populated name should represent the chosen inventory relationship, not an unsupported claim about every event’s original runtime context.

## Official references

[Microsoft Learn: Container log troubleshooting](https://learn.microsoft.com/en-us/azure/azure-monitor/containers/container-insights-troubleshoot). Source reviewed September 9, 2026.

## Primary reference

- Name: Troubleshoot collection of container logs in Azure Monitor - Azure Monitor | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-monitor/containers/container-insights-troubleshoot
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Enrich existing ContainerLog records without dropping rows that lack inventory matches,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-204-enrich-existing-containerlog-records-without-dropping-rows-that-lack-inventory/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.