# Monitoring systemd services using Metricbeat

**URL:** <https://discuss.elastic.co/t/monitoring-systemd-services-using-metricbeat/198284>\
**Category:** Metrics\
**Created:** [September 5, 2019, 3:26pm UTC](https://discuss.elastic.co/t/monitoring-systemd-services-using-metricbeat/198284 "2019-09-05T15:26:05Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Mohammad\_Etemad](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mohammad_etemad/32/42444_2.png) [@Mohammad\_Etemad](https://discuss.elastic.co/u/Mohammad_Etemad)\
**Post date:** [September 5, 2019, 3:26pm UTC](https://discuss.elastic.co/t/monitoring-systemd-services-using-metricbeat/198284/1 "2019-09-05T15:26:05Z")

</div>

I was wondering if there is a way to monitor Centos services like kubelet, keepalived, even a custom service that I wrote, using Metricbeat or any other Elastic service. i.e. is there a way to have metricbeat run a command like:

> service myService status

and see if the results is running.

Thank you

---

<div class="post-metadata">

**Author:** ![weltenwort](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/weltenwort/32/53885_2.png) [@weltenwort](https://discuss.elastic.co/u/weltenwort)\
**Post date:** [September 5, 2019, 5:28pm UTC](https://discuss.elastic.co/t/monitoring-systemd-services-using-metricbeat/198284/2 "2019-09-05T17:28:54Z")

</div>

Hi @Mohammad_Etemad,

while not directly related to systemd services, the built-in `system` module of metricbeat has a [`process` metricset](https://www.elastic.co/guide/en/beats/metricbeat/current/metricbeat-metricset-system-process.html) that can be enabled. It supports filtering down the reported processes. It also integrates with cgroups, which are the primary process tracking mechanism systemd uses. Since systemd names the cgroups after the units, it should be easy to query the metricbeat results for the processes belonging to a specific service.

---

<div class="post-metadata">

**Author:** ![Mohammad\_Etemad](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mohammad_etemad/32/42444_2.png) [@Mohammad\_Etemad](https://discuss.elastic.co/u/Mohammad_Etemad)\
**Post date:** [September 5, 2019, 5:48pm UTC](https://discuss.elastic.co/t/monitoring-systemd-services-using-metricbeat/198284/3 "2019-09-05T17:48:17Z")

</div>

> [@weltenwort](#):
>
> cgroups

Thank you for the quick reply @weltenwort . I tried this and I do get entries based on the service. But the problem is when the service stops, the entries stop. Is there any way that a field can show the status of the service? So something like the equivalent of heartbeat but instead of tcp/http/... for systemd.

---

<div class="post-metadata">

**Author:** ![weltenwort](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/weltenwort/32/53885_2.png) [@weltenwort](https://discuss.elastic.co/u/weltenwort)\
**Post date:** [September 6, 2019, 3:57pm UTC](https://discuss.elastic.co/t/monitoring-systemd-services-using-metricbeat/198284/4 "2019-09-06T15:57:40Z")

</div>

Good point, depending on the way the results are being queried this might be a problem. Sometimes it is possible to deal with that using the `missing` configuration of the aggregation when querying.

There is an enhancement proposal at [https://github.com/elastic/beats/issues/11846](https://github.com/elastic/beats/issues/11846). Any input you can provide on that issue would help the metricbeat developers to judge the demand and scope for this feature.

In the meantime there might be an improvised way to achieve the same thing using the [execbeat community beat](https://github.com/christiangalsterer/execbeat).

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [October 4, 2019, 3:57pm UTC](https://discuss.elastic.co/t/monitoring-systemd-services-using-metricbeat/198284/5 "2019-10-04T15:57:41Z")

</div>

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