Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add metrics to range mapper #6030

Merged
merged 2 commits into from
Apr 29, 2022
Merged

Add metrics to range mapper #6030

merged 2 commits into from
Apr 29, 2022

Conversation

ssncferreira
Copy link
Contributor

@ssncferreira ssncferreira commented Apr 26, 2022

What this PR does / why we need it:

  • Refactor ShardingMetrics to MapperMetrics
  • Add MapperMetrics to range mapper: each mapper contains the same set of metrics with a constant label that determines the mapper type, i.e., "shard" and "range" for shardMapper and rangeMapper, respectively.

Note: the metric names were not changed for backward compatibility (see comment for more detail).

For example, for the following configuration:

  • row_shards: 2
  • split_queries_by_interval: 1m

running the instant query bytes_over_time({app="foo"}[5m]) and taking into account that the split by range middleware is executed prior to the sharding middleware (i.e., the downstream queries outputted by the range middleware are inputted to the sharding middleware), the metrics would result in the following values:

  • rangeMapper:
    • loki_query_frontend_shards_total{mapper="range",type="metrics"} 5 - (counter) the query generates 5 downstream queries
    • loki_query_frontend_sharding_parsed_queries_total{mapper="range",type="success"} 1 - (counter) the query is successfully parsed
    • loki_query_frontend_shard_factor_sum{mapper="range"} 5 - (histogram) the query request generates 5 downstream range queries which are passed downwards to the shard mapper
  • shardMapper:
    • loki_query_frontend_shards_total{mapper="shard",type="metrics"} 10 - (counter) each of the 5 downstream queries generated by the split by range middleware generates 2 more downstream queries, one for each shard
    • loki_query_frontend_sharding_parsed_queries_total{mapper="shard",type="success"} 5 - (counter) all the 5 downstream queries generated by the split by range middleware are successfully parsed
    • loki_query_frontend_shard_factor_sum{mapper="shard"} 10 - (histogram) the query request generates 5 downstream shard queries

Which issue(s) this PR fixes:
NA

Special notes for your reviewer:

Checklist

  • Documentation added
  • Tests updated
  • Is this an important fix or new feature? Add an entry in the CHANGELOG.md.
  • Changes that require user attention or interaction to upgrade are documented in docs/sources/upgrading/_index.md

Comment on lines +30 to +48
DownstreamQueries: promauto.With(registerer).NewCounterVec(prometheus.CounterOpts{
Namespace: "loki",
Name: "query_frontend_shards_total",
Help: "Number of downstream queries by expression type",
ConstLabels: prometheus.Labels{"mapper": mapper},
}, []string{"type"}),
ParsedQueries: promauto.With(registerer).NewCounterVec(prometheus.CounterOpts{
Namespace: "loki",
Name: "query_frontend_sharding_parsed_queries_total",
Help: "Number of parsed queries by evaluation type",
ConstLabels: prometheus.Labels{"mapper": mapper},
}, []string{"type"}),
DownstreamFactor: promauto.With(registerer).NewHistogram(prometheus.HistogramOpts{
Namespace: "loki",
Name: "query_frontend_shard_factor",
Help: "Number of downstream queries per request",
Buckets: prometheus.LinearBuckets(0, 16, 4),
ConstLabels: prometheus.Labels{"mapper": mapper},
}),
Copy link
Contributor Author

@ssncferreira ssncferreira Apr 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since these metric names are now shared amongst all mappers, the names should be updated to make them more general, i.e., replacing "shards" with "downstream". However, this would result in a breaking change. This is my preferred option, but don't know if there is a process for "deprecating" metric names as well as the real impact this might have on current users (e.g., dashboards would stop working, ...)

An alternative would be to remove this generalization by keeping the shard and the range mapper (and future mappers) metrics with their own exclusive names. Wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can create a PR or an issue for that and merge it during a 3.0.

@ssncferreira ssncferreira marked this pull request as ready for review April 26, 2022 17:04
@ssncferreira ssncferreira requested a review from a team as a code owner April 26, 2022 17:04
@ssncferreira ssncferreira self-assigned this Apr 26, 2022
Copy link
Contributor

@cyriltovena cyriltovena left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@cyriltovena cyriltovena merged commit 6b6521f into main Apr 29, 2022
@cyriltovena cyriltovena deleted the split_by_range_metrics branch April 29, 2022 14:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants