-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[metricbeat/aws] When running Metricbeat from GCP cloud.* fields get overwritten #11305
Comments
Side note- I would bet that it has the same problem when running from any provider for which Metricbeat picks up the |
@jamiesmith I assume in your Metricbeat config you have I think we need to add an option to the @webmat That reminds me a lot of our |
Yes, that was the case (it is on by default). Probably need to have the docs updated, and I will update the AWS blog that went out yesterday to include that tidbit. Thanks! |
Agree, the short term solution is update our docs accordingly. Thanks for updating the blog post. |
@ruflin how's this for a disclaimer:
|
@jamiesmith SGTM. Perhaps you could even say |
@ruflin @jamiesmith Thanks for the temporary fix here. In this case, if we add an option in |
Perhaps we could look at the defaults for these processors from a different angle, too. When Metricbeat is monitoring a host external to itself, perhaps it should by default not run add_host_metadata nor add_cloud_metadata? |
@webmat I think there are cases where the same MB instance monitors a local and remote host. And even if it's separate, how do we tell the difference on startup to magically enabled it? My preference is to have a decision event based. @kaiyan-sheng I think the challenge you mention here is that Metricbeat is running as an observer. If we need the cloud data for the observer (which I'm not sure we need) we could add it under |
Well we could beef up all of the Or alternately we could try to go the road of detecting whether the monitored address is local or remote (one of the host's IPs => add_host_metadata, a domain or an unknown IP => add_observer_metadata). Although this detection will look like magic, and confuse people when it's not working (e.g. monitoring a virtual IP assigned to the local host, but invisible locally, like an AWS elastic IP). |
Interesting idea about adding it to each module instead of having it globally. But I still think it would need user interaction so we are in the same situation like now. |
+1 on changing |
Working with snapshot & beta for 7.0, have ES running on cloud, with the AWS metricbeat module enabled. The dashboards get put out there, and I see one entry. Took me a while, but it turns out that for the
cloud.*
fields it is picking up the info from the GCP VM that I am running it from, rather than what it's getting for each individual EC2 instance. All of the visualizations are keyed off ofcloud.instance.id
It still has the aws info in the
![image](https://user-images.githubusercontent.com/220994/54602363-e64cb200-4a17-11e9-9f3b-f565c1f90079.png)
aws.ec2.instance.*
fields. Note that the key on the legend is 827... (EC2 instances all start with i-)But the data still has the AWS info:
![image](https://user-images.githubusercontent.com/220994/54602445-1ac06e00-4a18-11e9-9c83-9cde8ccae198.png)
Compare the first picture with the same snapshot when running the exact same config & start command from my laptop:
![image](https://user-images.githubusercontent.com/220994/54602549-59eebf00-4a18-11e9-88cc-c4451796fa53.png)
(ignore the fact that there aren't lines yet, they take several minutes to show-- just look at the legend)
./metricbeat modules enable aws
./metricbeat -E setup.dashboards.enabled=true -e
Using the cloud config, the relevant/modified parts of the metricbeat.yml are:
I have my AWS credentials sourced in the environment:
env | grep AWS
then start via
./metricbeat -E setup.dashboards.enabled=true -e
.These are the fields which it is overwriting:
The text was updated successfully, but these errors were encountered: