# Best practices for maintaining custom Metricbeats

**URL:** <https://discuss.elastic.co/t/best-practices-for-maintaining-custom-metricbeats/346895>\
**Category:** Beats\
**Tags:** metricbeat\
**Created:** [November 10, 2023, 8:23pm UTC](https://discuss.elastic.co/t/best-practices-for-maintaining-custom-metricbeats/346895 "2023-11-10T20:23:05Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Keith\_Wegner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/keith_wegner/32/84080_2.png) [@Keith\_Wegner](https://discuss.elastic.co/u/Keith_Wegner)\
**Post date:** [November 10, 2023, 8:23pm UTC](https://discuss.elastic.co/t/best-practices-for-maintaining-custom-metricbeats/346895/1 "2023-11-10T20:23:05Z")

</div>

My software team has extended Metricbeat a few times, creating new modules/metricsets. We're looking for advice regarding the best way to maintain the Git repository (i.e., keeping with Elastic Beat's main branch). Currently, it's a high frequency of manual merges to avoid drifting too far, where it becomes untenable. We looked at options like Repository Mirroring and Submodules, but aren't sure if any of those options are ideal.

---

<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:** [December 8, 2023, 10:23pm UTC](https://discuss.elastic.co/t/best-practices-for-maintaining-custom-metricbeats/346895/2 "2023-12-08T22:23:59Z")

</div>

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