[Yongwook Song]

The testbed is back to normal now. Thank you.

[Yongwook Song]

Thank you for the update Prateek. Yes, we will look into this for solution in next version.

[Yongwook Song]

Thank you for the details. I think it is maybe due to the seccomp policy based on Google search.

https://discuss.elastic.co/t/metricbeat-service-get-stopped-after-service-start/336567/2

https://github.com/elastic/apm-server/issues/6238

I would recommend to follow one of answers in the second link above.

I think you can add “seccomp.enabled: false” on the metricbeat.yml file first to check if seccomp policy is the issue or not.

Here is metricbeat.yml reference example that shows the seccomp option as well. https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-reference-yml.html

Please let me know if this fixes it or not.

Thanks,

-Song

[Yongwook Song]

Could you share logs from the /var/log? There should be metricbeat logs that may have more information about what caused the issue.

-Song

[Yongwook Song]

If all the beats stopped for some reason, you can check the beats log to see what error caused the stop of running.

It may give you some reason in the logs. I would guess possible reasons such as network reset or temporary network connection issue.

If the workers restarted for some reason, then maybe the beats are not enrolled for auto restart when VM restarts. I would recommend to set auto-start of beat services when the VM restart (if that is not enabled).

Thank you.

-Song

[Yongwook Song]

Hi, Prateek.

I do not see your screenshot for some reason. Could you attach the screenshot again if you can? Maybe the screenshot was too large.

Here are things you may check:

• Is the meas_node disk space is nearly full? If so, Elasticsearch may stop ingesting.
• Are the worker’s beats running without any error messages in the beats’ logs?

Thank you.

-Song

[Author]

Posts