anomaly-detection icon indicating copy to clipboard operation
anomaly-detection copied to clipboard

Add validate API blocker/non-blocker request counts to Stats API

Open amitgalitz opened this issue 2 years ago • 5 comments

Is your feature request related to a problem? This can help track how many times users (total count on a cluster level) are creating AD detector with valid or invalid configurations.

What solution would you like? Add metrics for how many times an issue was returned through the validate API and relative to the total calls to the API. Distinguish if the issue was a blocking issue or a non-blocking issue through the relevant type returned with the issue, "detector" for blocking or "model" non-blocking.

amitgalitz avatar Apr 18 '22 18:04 amitgalitz

This looks really interesting. Does this associate the user via their authenticated principal (e.g., who they are via security auth) or does this work a different way? Also, since we have "FEATURE" in the subject, should we add the feature tag?

elfisher avatar Apr 21 '22 12:04 elfisher

@elfisher So this would actually be tracking the total invalid/valid responses on a cluster level and not for each individual user. I will change my wording on the issue to reflect metrics are cluster level. Also now that you point this out I might remove the FEATURE from the subject line because this is more of an add-on to our existing stats API. This issue is relating too adding on validate API responses to our stats API so we can track on a cluster level how many times there are valid or invalid responses in regards to Validation API which validates AD configs.

amitgalitz avatar Apr 21 '22 16:04 amitgalitz

@amitgalitz thanks for sharing the additional details. This looks like something we would want to document since it is data used for monitoring a cluster. Could you open a documentation issue to help track that task?

elfisher avatar May 17 '22 13:05 elfisher

Sounds good, we'll actually be deciding next week if this makes it into 2.1 or 2.2 and act accordingly and change tag here if moved. Should documentation issues be created as I start developing or only after its merged into AD?

amitgalitz avatar May 19 '22 20:05 amitgalitz

Sounds good, we'll actually be deciding next week if this makes it into 2.1 or 2.2 and act accordingly and change tag here if moved. Should documentation issues be created as I start developing or only after its merged into AD?

Personally, I think it gives the most time for planning to open it as the development work begins. Thanks!

elfisher avatar May 26 '22 16:05 elfisher