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

fix: update prom rule to use range query #4461

Merged
merged 10 commits into from
Feb 11, 2024
Merged

Conversation

srikanthccv
Copy link
Member

@srikanthccv srikanthccv commented Jan 30, 2024

Summary

Fixes #4038
Fixes #3917

What do we support today:

Instant query with only At least once comparison condition.

Screenshot 2024-02-01 at 9 07 30 AM

Issues with the current promql alerts

  • On average, In total and All the times are not supported
  • Evaluation of the range is not supported.
  • Inconsistent exp with the other two modes of alert creation.

What users see in the chart UI when working with promql comes from the Range query API. They expect the same when creating alerts. For instance, there is no way to set an alert if the latency is greater than 800ms for the last 10 minutes. It's common to have occasional spikes and triggering alerts with At least once can be noisy.

This PR moves to RangeQuery instead of InstantQuery.

Summary by CodeRabbit

Summary by CodeRabbit

  • New Features
    • Introduced Prometheus-specific evaluation windows for alert rules.
    • Enhanced alert query functionality to support time range and interval parameters.
  • Refactor
    • Improved clarity and extensibility of alert rule options rendering.
    • Updated alert rule logic to handle different match types and comparison operations more effectively.
  • Tests
    • Added new tests for evaluating Prometheus rules based on various scenarios.
  • Documentation
    • Updated comments for better clarity in code documentation.

@github-actions github-actions bot added the bug Something isn't working label Jan 30, 2024
Copy link

coderabbitai bot commented Jan 30, 2024

Walkthrough

The recent changes focus on enhancing support for PromQL based alerts, specifically by introducing more flexible evaluation windows and improving the logic for handling alerts. This includes changes to how alert queries are run, the introduction of more sophisticated comparison and match types, and improvements to the clarity and functionality of the code. These updates aim to address specific issues related to PromQL alert evaluation times and discrepancies in lookback deltas between different types of queries.

Changes

Files Summary of Changes
frontend/src/container/FormAlertRules/RuleOptions.tsx Renamed and refactored functions for better clarity; introduced handling for Prometheus evaluation windows.
pkg/query-service/.../engine.go & pkg/query-service/rules/promRule.go Enhanced logic for PromQL alert queries, including changes to function signatures and the introduction of new methods for better flexibility and accuracy.
pkg/query-service/rules/promrule_test.go Added tests for new alert evaluation logic.
pkg/query-service/rules/thresholdRule.go Minor comment update for improved clarity.

Assessment against linked issues

Objective Addressed Explanation
PromQL based alerts should support flexible evaluation times (#4038)
Address lookback delta discrepancy between RangeQuery and InstantQuery for PromQL (#3917)
Ensure new alert logic accurately reflects Prometheus For functionality (#4038) The changes indicate an effort to support more flexible times, akin to the For logic in Alertmanager, but the specifics of implementation need to be reviewed in-depth to confirm complete alignment.

Poem

In the code arena where rivals clash, 🏈🐇
Changes dance like a touchdown bash. 💃
With each play and call, a victory to chase,
For alerts in PromQL, a new playbook to embrace. 🚀

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>.
    • Generate unit-tests for this file.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit tests for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai generate interesting stats about this repository from git and render them as a table.
    • @coderabbitai show all the console.log statements in this repository.
    • @coderabbitai read src/utils.ts and generate unit tests.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • The JSON schema for the configuration file is available here.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json

CodeRabbit Discord Community

Join our Discord Community to get help, request features, and share feedback.

@srikanthccv srikanthccv marked this pull request as ready for review February 1, 2024 03:44
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Review Status

Actionable comments generated: 5

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between 64307f3 and 1145dd6.
Files selected for processing (5)
  • frontend/src/container/FormAlertRules/RuleOptions.tsx (4 hunks)
  • pkg/query-service/pqlEngine/engine.go (3 hunks)
  • pkg/query-service/rules/promRule.go (7 hunks)
  • pkg/query-service/rules/promrule_test.go (1 hunks)
  • pkg/query-service/rules/thresholdRule.go (1 hunks)
Files skipped from review due to trivial changes (1)
  • pkg/query-service/rules/thresholdRule.go
Additional comments: 3
frontend/src/container/FormAlertRules/RuleOptions.tsx (1)
  • 174-175: The use of renderPromEvalWindows in renderPromRuleOptions correctly implements the PR's objective to introduce Prometheus-specific evaluation windows. However, as mentioned earlier, the current implementation does not differentiate the options from the standard evaluation windows. Ensure the options provided by renderPromEvalWindows are tailored to Prometheus-specific needs or clarify the need for this separation.
pkg/query-service/rules/promRule.go (2)
  • 119-121: The use of a unit converter in the targetVal method to handle different units of measurement is a good enhancement, ensuring that alert thresholds are correctly interpreted regardless of the unit specified. This change supports the PR's objective to enhance alert evaluation logic.
  • 336-348: The introduction of matchType and compareOp methods in promRule.go improves code readability and maintainability by encapsulating the logic for retrieving the match type and comparison operation from the rule condition. This is a positive change that aligns with best practices for code organization.

pkg/query-service/pqlEngine/engine.go Show resolved Hide resolved
pkg/query-service/rules/promrule_test.go Show resolved Hide resolved
pkg/query-service/rules/promRule.go Show resolved Hide resolved
pkg/query-service/rules/promRule.go Show resolved Hide resolved
@ankitnayan
Copy link
Collaborator

On average, In total and All the times are supported

You mean not supported in the issue description?

@srikanthccv
Copy link
Member Author

Yes

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Review Status

Actionable comments generated: 0

Configuration used: CodeRabbit UI

Commits Files that changed from the base of the PR and between 1145dd6 and 33ff8cd.
Files selected for processing (1)
  • pkg/query-service/rules/thresholdRule.go (1 hunks)
Files skipped from review due to trivial changes (1)
  • pkg/query-service/rules/thresholdRule.go

@srikanthccv
Copy link
Member Author

The comments are non-blocking. I will merge this for now and address them in follow up PR.

@srikanthccv srikanthccv merged commit 260d21a into develop Feb 11, 2024
12 checks passed
@srikanthccv srikanthccv deleted the use-range-query-promql branch February 11, 2024 17:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
3 participants