Add support for dimensions to metrics

[tj-wazei]

Add custom dimension support to the Metrics class.

Changes:

• New migration V17 adds a nullable dimensions TEXT column to metric_events & migrates all the postfixed metrics with dimensions
• New count(String event, Map<String, String> dimensions) overload which serializes dimensions as JSON into the new dimensions column
• Existing count(String event) is unchanged (delegates to the new overload with an empty map)

Example usage:

metrics.count("tag", Map.of(
  "method", "use", 
  "id", "learn"
)) ;

Migration:

local database before:

local database after:

[christolis]

Looking good at a first glance. What I am about to ask shouldn't really affect the functionality of what you created, but wouldn't the term "metadata" be a more fitting name than "dimensions"? It took me some time to figure out what "dimensions" stands for here, though this could just be me that has never seen it named that way. Just my two cents. ~Chris

[SquidXTV]

Looking good at a first glance. What I am about to ask shouldn't really affect the functionality of what you created, but wouldn't the term "metadata" be a more fitting name than "dimensions"? It took me some time to figure out what "dimensions" stands for here, though this could just be me that has never seen it named that way. Just my two cents. ~Chris

See CloudWatch for example, it also uses the term dimension for metrics:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension

[Zabuzard]

its the idiomatic name. ive worked with google analytics and matomo for tracking stuff, they all called it dimensions.

but yeah, the code should have some javadoc to explain what it is, such as "to track additional info, e.g. metadata"

[christolis]

On 3/23/26 22:28, Connor Schweighöfer wrote: See CloudWatch for example, it also uses the term **dimension** for metrics: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension

Thank you for the resource Squid, I didn't know about that. :) ~Chris

[tj-wazei]

Hi @Zabuzard, this is ready for another review. I have tested including tested in Grafana and we'll need to update the queries for some of the graphs e.g.

for the /tag (Total) graph, the query goes from:

Before:

SELECT
  substr(event, length('tag-') + 1) AS tag,
  COUNT(*) AS count
FROM metric_events
WHERE event LIKE 'tag-%'
GROUP BY tag
ORDER BY count DESC;

After:

SELECT
  json_extract(dimensions, '$.id') AS tag,
  COUNT(*) AS count
FROM metric_events
WHERE event = 'tag'
GROUP BY tag
ORDER BY count DESC;

for the Slash Commands (Total):

Before:

SELECT
  substr(event, length('slash-') + 1) AS slash,
  COUNT(*) AS count
FROM metric_events
WHERE event LIKE 'slash-%'
GROUP BY slash
ORDER BY count DESC;

After:

SELECT
  json_extract(dimension, '$.name') AS slash,
  COUNT(*) AS count
FROM metric_events
WHERE event = 'slash'
GROUP BY json_extract(dimension, '$.name')
ORDER BY count DESC;

The key thing here is that we're just using json_extract(dimension, '$.key') to extract the value which was previously postfixed. Super simple stuff

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud