Accessing "period" module config from inside a module

[themanwithanrx7 (Andy Snowden)]

Hello,

I've been working on writing a few company-specific modules for metricbeat and have a question about the best way to access the config.

I know that inside of the New func of a metricset module I can define a struct and pass it to base.Module().UnpackConfig() to get the config for that specific module. I've used that approach in the past to define custom settings. In this specific module I want to access the "period" configuration and I was wondering if that was already parsed somewhere else in beats.

Ideally I'd like to just receive the number of seconds in the interval regardless of what is defined in the config. Ex 300 vs 5m

I can write a parsing function but I don't want to duplicate code if it already exists somewhere else.

Thanks!

[andrewkroh]

The period is accessible through BaseMetricSet using base.Module().Config().Period. The type is time.Duration so you can call base.Module().Config().Period.Seconds() to get the value as seconds.

Needing to know the period inside of the metricset could be an indicator that you are using the framework incorrectly. Since the periodic fetching is handled automatically by the framework usually metricsets have not need for the period value.

[themanwithanrx7 (Andy Snowden)]

Thanks for the answer,

After making the post I found a code example in github that uses time.Duration like you mentioned. In terms of needing the duration we're running a SQL query to a custom database pulling metrics. We specifically want to access every row that was created between X time and X time. So specifically between CURRENT_TIMESTAMP and ( CURRENT_TIMESTAMP - INTERVAL period_convered_into_seconds.

Would base.Module().Config().Period.Seconds() be more efficient than defining a strut and calling base.Module().UnpackConfig ?

[andrewkroh]

@themanwithanrx7

Would base.Module().Config().Period.Seconds() be more efficient than defining a strut and calling base.Module().UnpackConfig ?

I can't say definitively without benchmarking it. But most likely it is more efficient since the config does not need to be unpacked again. The module config gets unpacked once at startup.