Metricbeat shows containers as host in APM UI

hi,
I am trying to monitor a microservices application deployed in docker with APM on elastic cloud.

When I start metricbeat with the system and docker modules enabled, it shows me the containers as if they were hosts.



My metricbeat configurations are as follows:

metricbeat.yml

# =========================== Modules configuration ============================

metricbeat.config.modules:
  # Glob pattern for configuration loading
  path: ${path.config}/modules.d/*.yml

  # Set to true to enable config reloading
  reload.enabled: false

# ======================= Elasticsearch template setting =======================

setup.template.settings:
  index.number_of_shards: 1
  index.codec: best_compression
  #_source.enabled: false

# ================================= elastic cloud =================================

# You can find the `cloud.id` in the Elastic Cloud web UI.
cloud.id: "deploy_name:cloud_id"

# The cloud.auth setting overwrites the `output.elasticsearch.username` and
# `output.elasticsearch.password` settings. The format is `<user>:<pass>`.
cloud.auth: "user:password"

# ================================= Processors =================================

# Configure processors to enhance or manipulate events generated by the beat.

processors:
  - add_host_metadata: ~
  - add_cloud_metadata: ~
  - add_docker_metadata: ~
  - add_kubernetes_metadata: ~
  - add_fields:
      fields:
        application: sockshop

modules.d/docker.yml

- module: docker
  metricsets:
    - container
    - cpu
    - diskio
    - event
    - healthcheck
    - info
    - memory
    - network
    - network_summary
  period: 10s
  hosts: ["unix:///var/run/docker.sock"]

I would like them to appear as containers, so that when I click on investigate within a transaction it will take me to the metrics page of the container. does anyone know what I am doing wrong?

thanks in advance.

Hi @irivas95 ,

I'm suspecting that you are running into a current limitation of the APM Java agent where it is unable to discover that it is running inside a container. The agent cannot handle cgroupsv2 properly at the moment (GH issue).

Could you tell us what operating system and version you are using? It would be great if you could verify whether your system uses cgroupsV2, for example using the approach explained here.

thanks Jonas,

the operating system of the machine on which I have the containers deployed is Debian 11 bullseye.

if I launch the command:

grep cgroup /proc/filesystems

I see the following:

nodev   cgroup
nodev   cgroup2

so I understand that if you are using the cgroups that you mention.

I also checked the documentation of Debian 11, indeed the defaults where changed from cgroupsv1 to cgroupsv2.

So unfortunately I think there is not much we can do here except waiting until we add the cgroupsv2 support to the agent. You can follow the issue from my previous response to track our progress.

Thanks for your help jonas,
I will keep an eye on the progress with the issue.

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.