In Metricbeat, we can use add_cloud_metadata processor to enrich each event with instance metadata from the machine’s hosting provider. We also collect these metadata when running specific public cloud provider Metricbeat modules individually without the add_cloud_metadata processor.
For example, add_cloud_metadata processor should collect cloud.instance.id when we run Metricbeat on AWS EC2 instance. Metricbeat aws ec2 metricset also collects cloud.instance.id as a part of the event.
Cloud metadata like cloud.instance.id will be the important field that connects events sent from inside the host and outside the host. This issue is to track the investigation work on verify if cloud metadata are collected properly using add_cloud_metadata processor for different hosts/public cloud providers.
cc @exekias @sorantis
In Metricbeat, we can use
add_cloud_metadataprocessor to enrich each event with instance metadata from the machine’s hosting provider. We also collect these metadata when running specific public cloud provider Metricbeat modules individually without theadd_cloud_metadataprocessor.For example,
add_cloud_metadataprocessor should collectcloud.instance.idwhen we run Metricbeat on AWS EC2 instance. Metricbeataws ec2metricset also collectscloud.instance.idas a part of the event.Cloud metadata like
cloud.instance.idwill be the important field that connects events sent from inside the host and outside the host. This issue is to track the investigation work on verify if cloud metadata are collected properly usingadd_cloud_metadataprocessor for different hosts/public cloud providers.aws ec2metricset vs running system module withadd_cloud_metadataprocessor on EC2 instancegooglecloud computemetricset vs running system module withadd_cloud_metadataprocessor on GCP VMazure compute_vmmetricset vs running system module withadd_cloud_metadataprocessor on Azure VMcc @exekias @sorantis