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

Azure Log Analytics scaler #1061

Closed
spoplavskiy opened this issue Aug 30, 2020 · 3 comments
Closed

Azure Log Analytics scaler #1061

spoplavskiy opened this issue Aug 30, 2020 · 3 comments
Labels
feature-request All issues for new features that have not been committed to Hacktoberfest needs-discussion scaler
Milestone

Comments

@spoplavskiy
Copy link
Contributor

spoplavskiy commented Aug 30, 2020

In standard AKS setup, Log Analytics takes central part in storing OMS agent metrics, logs from pods, during building a monitoring dashboards and generate alerts. Also, OMS agent could be configured to scrap Prometheus metrics, so they also can be landed in Log Analytics workspace. Advantage of using Container Insights (OMS agents) is that "It just works", you don't need to support it, and in many cases even configure it. So, with Log Analytics and Container Insights there is complete monitoring story in place, but the question is, how to use this data to scale deployments? And as of now, the answer is - you can't do this.

To fill this gap, I have started to develop Log Analytics scaler and here I would like to use community experience and knowledges to better understand potential requirements and limitations.

Use-Case

  • Use Log Analytics query to retrieve required metric will be used by Keda and HPA to scale deployments.
  • Potentially, use Log Analytics query to retrieve threshold will be configured during scaler creation.

Requirements and limitations

  • Authorisation using AAD Service Principal
  • Automatic tracking token expiration and reclaim it, when needed.
  • Query should return the following datatypes: real, int, long (use this as a reference for LA datatypes). At the end, scaler will convert it to int64. This will be a part of query result validation.
  • Query should return one table with one row.
  • Cell # 1 will be used as metric, cell # 2 can be used as threshold (optional). So, in a moment of creating instance of scaler, threshold could be retrieved from ScalerObject metadata, or from LA query result.

If you have any good proposals\suggestions for LA scaler, feel free to put them in comments.

Thank you!

@spoplavskiy spoplavskiy added feature-request All issues for new features that have not been committed to needs-discussion labels Aug 30, 2020
@tomkerkhove
Copy link
Member

I like the idea! Are you willing to contribute this?

@spoplavskiy
Copy link
Contributor Author

spoplavskiy commented Sep 4, 2020

I like the idea! Are you willing to contribute this?

@tomkerkhove , Yep, the first version to try is here: #1085

@tomkerkhove
Copy link
Member

This is done, thanks man!

@tomkerkhove tomkerkhove added this to the v2.0 milestone Sep 10, 2020
SpiritZhou pushed a commit to SpiritZhou/keda that referenced this issue Jul 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request All issues for new features that have not been committed to Hacktoberfest needs-discussion scaler
Projects
None yet
Development

No branches or pull requests

2 participants