feat: Support for metrics custom labels

[yorch]

• Provides support for custom / extra labels for each of the http_* metrics.

Example

promApiMetrics({
    metricsAdditionalLabels: ['user_group', 'role'],
    getMetricsAdditionalLabelValues: (req: Request) => {
        const { userGroup, role } = req.context;
        return {
            ...(userGroup ? { user_group: userGroup } : {}),
            ...(role ? { role } : {})
        };
    }
})

Result:

http_request_duration_seconds_bucket{le="0.1",method="POST",route="/path",code="200",user_group="admin",role="superadmin"} 0
http_request_duration_seconds_bucket{le="0.5",method="POST",route="/path",code="200",user_group="admin",role="superadmin"} 0
http_request_duration_seconds_bucket{le="1",method="POST",route="/path",code="200",user_group="admin",role="superadmin"} 0
http_request_duration_seconds_bucket{le="5",method="POST",route="/path",code="200",user_group="admin",role="superadmin"} 2
http_request_duration_seconds_bucket{le="+Inf",method="POST",route="/path",code="200",user_group="admin",role="superadmin"} 2
http_request_duration_seconds_sum{method="POST",route="/path",code="200",user_group="admin",role="superadmin"} 4.657347321
http_request_duration_seconds_count{method="POST",route="/path",code="200",user_group="admin",role="superadmin"} 2

[yorch]

Not a big fan of the new properties names (metricsExtraLabels, getMetricsExtraLabelValues), so open to suggestions

[kobik]

Thanks for your PR @yorch , much appreciated!

In addition to my comments, we're missing tests for custom labels.

Can you please add the relevant test cases?

[yorch]

@kobik thanks for the review! Addressed the feedback:

• Added input validation
• Added more tests to cover the new options

[yorch]

@kobik let me know if you have any other feedback please! I have a few other changes on my fork that would like to put PRs for.

[kobik]

Thanks @yorch for your work and nice input validation addition!

But you you have created a problem (good one 🙂 ), I meant to add validation only for the new props as adding validation for the older props could be a breaking change.

I'm considering whether to release a new major or wait for more breaking stuff and for now remove the validation from the old props.

[kobik]

Hi @yorch, is this still relevant?

[jbarnaby-medallia]

@kobik sorry for the delay, please let me know if you have any more feedback before this can be merged. thanks!

[yorch]

@kobik had to update package-lock.json as it seems like in the last commit in master, your internal NPM server URL was committed so builds for PRs are failing.

[yorch]

@kobik friendly reminder this is ready :)

[kobik]

@yorch on it

[kobik]

Sorry for the delay, having loaded with work and i wanted to review it again as i didn't remember the changes

[kobik]

@yorch one last thing is adding it to the changelog 🙂

[yorch]

@kobik if I change the CHANGELOG, there are gonna be conflicts with the other PR, so I'll have to resolve conflicts after one of them merges. Why not making those changelog in a different commit?

[kobik]

@yorch you can now rebase

[yorch]

@kobik done

[kobik]

thanks @yorch, much appreciated!