(feat): Add Sumo Logic scaler

[mittalvaibhav1]

Add Sumo Logic scaler to scale based and logs and metrics from Sumo Logic

1. Issue: Support Sumo Logic scaler #6734
2. Docs PR: (feat): Add sumologic scaler documentation keda-docs#1566

Checklist

• When introducing a new scaler, I agree with the scaling governance policy
• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added
• Changelog has been updated and is aligned with our changelog requirements
• A PR is opened to update our Helm chart (repo) (if applicable, ie. when deployment manifests are modified)
• A PR is opened to update the documentation on (repo) (if applicable)
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

[mittalvaibhav1]

where can we put these credentials? And for this to work, the query should return some data. Is the expectation here to setup a account with constant ingestion such that the query always work ?

[rickbrouwer]

My feedback will focus on the possibility of using TypedConfig.

This scaler does not use the new TypedConfig pattern available in the scalersconfig package. The metadata is manually parsed in parseSumoMetadata instead of declaratively with tags.
You can also store the defaults here, like:

	// Connection settings
	Host      string `keda:"name=host,      order=triggerMetadata"`
	UnsafeSsl bool   `keda:"name=unsafeSsl, order=triggerMetadata, optional"`

	// Authentication
	AccessID  string `keda:"name=access_id,  order=authParams"`
	AccessKey string `keda:"name=access_key, order=authParams"`

	// Query configuration
	QueryType        string            `keda:"name=queryType,        order=triggerMetadata, enum=logs;metrics"`
	Query            string            `keda:"name=query,            order=triggerMetadata, optional"`
	Queries          map[string]string `keda:"name=query.*,          order=triggerMetadata, optional"`
	ResultQueryRowID string            `keda:"name=resultQueryRowID, order=triggerMetadata, optional"`
	Quantization     time.Duration     `keda:"name=quantization,     order=triggerMetadata, optional"`
	Rollup           string            `keda:"name=rollup,           order=triggerMetadata, default=avg"`
	ResultField      string            `keda:"name=resultField,      order=triggerMetadata, optional"`
	Timerange        time.Duration     `keda:"name=timerange,        order=triggerMetadata"`
	Timezone         string            `keda:"name=timezone,         order=triggerMetadata, default=UTC"`
	QueryAggregator  string            `keda:"name=queryAggregator,  order=triggerMetadata, enum=Latest;Avg;Sum;Count;Min;Max, default=Sum"`

	// Scaling parameters
	ActivationThreshold float64 `keda:"name=activationThreshold, order=triggerMetadata, default=0"`
	Threshold           float64 `keda:"name=threshold,           order=triggerMetadata"`

Also there is a some of manual validation logic that can be handled automatically with TypedConfig.

Furthermore, I would keep GetMetricsAndActivity cleaner like the other scalers, like this:

// GetMetricsAndActivity retrieves metrics from sumologic
func (s *sumologicScaler) GetMetricsAndActivity(ctx context.Context, metricName string) ([]external_metrics.ExternalMetricValue, bool, error) {
	num, err := s.executeQuery(ctx)
	if err != nil {
		s.logger.Error(err, "error getting metrics from sumologic")
		return []external_metrics.ExternalMetricValue{}, false, fmt.Errorf("error getting metrics from sumologic: %w", err)
	}

	metric := GenerateMetricInMili(metricName, num)
	isActive := num > s.metadata.ActivationThreshold

	return []external_metrics.ExternalMetricValue{metric}, isActive, nil
}

func (s *sumologicScaler) executeQuery(ctx context.Context) (float64, error) {
	return s.client.GetQueryResult(
		s.metadata.QueryType,
		s.metadata.Query,
		s.metadata.Queries,
		s.metadata.ResultQueryRowID,
		s.metadata.Quantization,
		s.metadata.Rollup,
		s.metadata.ResultField,
		s.metadata.Timerange,
		s.metadata.Timezone,
		s.metadata.QueryAggregator,
	)
}

Further, I am very curious to see how the Multi-Metrics Query Trigger is viewed by the community/maintainers (because of this discussion)

[mittalvaibhav1]

Thanks for reviewing! I'll try out the things you mentioned above.

Further, I am very curious to see how the Multi-Metrics Query Trigger is viewed by the community/maintainers (because of #6697)

I see, it's a bit similar but the use-case is different. In Sumo Logic's case, that is how you write chained queries. Unlike prometheus where you can just let's say divide two metrics to calculate % utilisation or something, in Sumo Logic you have to define those metrics in separate queries and write another query which can reference those queries to do the chained calculation. The backend does all the calculation and we just pick result of the chained query via the input resultQueryRowID and ignore the rest.

For example -

query.A: "metric=requests_total | rate"
query.B: "metric=request_capacity"
query.C: "(#A / #B) * 100 along service"
resultQueryRowID: "C"          # Which query result to extract

Here, we are just interested in the result of query.C but the system expects the input this way. Unlike the usecase in #6697, this is just a single trigger.

[mittalvaibhav1]

I'll try out the things you mentioned above

Done!
Looks much cleaner now. Thanks!