Add temporal metric coverage up to version 1.29.2

[ddog-nasirthomas]

What does this PR do?

This change adds support for Temporal v1.29.2 metrics. Temporal now appends the unit of measurement to the metric suffix. This PR adds the new metric suffixes and maps them to the existing metrics we currently support.

The following suffixes have been added:

• Milliseconds
• Seconds
• Bytes

It also introduces new server metrics that were not previously included in the integration. All added metrics were sourced directly from the Temporal repo.

Motivation

While working on a support issue we noticed that some latency metrics were missing. Upon further investigation, temporal now appends the suffix to metric names when submitting. Example visibility_persistence_latency becomes visibility_persistence_latency_milliseconds. Customers who may have upgraded to a later temporal version, no longer emit the metric names without the suffixes resulting in metrics not being pulled in for the integration

I confirmed the logic by referencing the code below:

These are the metric suffixes that temporal uses here

The units are applied to the metric here

Then the suffix is appended here

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Add the qa/skip-qa label if the PR doesn't need to be tested during QA.
• If you need to backport this PR to another branch, you can add the backport/<branch-name> label to the PR and it will automatically open a backport PR once this one is merged

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.04%. Comparing base (34cfce2) to head (cc6406f).
⚠️ Report is 2 commits behind head on master.

Additional details and impacted files

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[datadog-datadog-prod-us1]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: cc6406f | Docs | Datadog PR Page | Was this helpful? Give us feedback!}

[steveny91]

How would this work? I see you're mapping both to service.latency, but the scale of these are 1000 fold apart?

[ddog-nasirthomas]

In Temporal if the user has recordTimerInSeconds then they send it as seconds. https://github.com/temporalio/temporal/blob/main/common/metrics/config.go#L65-L68

That is then used here to determine either milliseconds or seconds. Here

func (omp *otelMetricsHandler) Timer(timer string) TimerIface {
	if omp.recordTimerInSeconds {
		return omp.timerInSeconds(timer)
	}
	return omp.timerInMilliseconds(timer)
}

Does it make sense to just add a separate metric for seconds? I can see why mapping it to the same latency metric could cause confusion

Review from urseberry is dismissed. Related teams and files:

• documentation
  • temporal/metadata.csv

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a694b99441

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".