Skip to content

Conversation

@janaknat
Copy link
Contributor

This will be followed by infrastructure for other data types.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@janaknat janaknat requested a review from a team as a code owner February 17, 2025 18:40
@wash-amzn
Copy link
Contributor

I recommend thinking about how to do this such that it doesn't require explicit on-boarding for each data type to support analytics rules. The data they output should be self-describing enough that aggregates can be formed generically.

@janaknat
Copy link
Contributor Author

I recommend thinking about how to do this such that it doesn't require explicit on-boarding for each data type to support analytics rules. The data they output should be self-describing enough that aggregates can be formed generically.

I prefer things are explicit. It will help when others are looking to contribute rules.

let all_rules: Rules[] = [
system_info_rules,
cpu_utilization_rules,
perf_stat_rules,
Copy link
Contributor

Choose a reason for hiding this comment

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

Are we planning to have all the rules defined in the code or give also the user the possibility to add/configure/change them?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Currently we want all the rules to be in code.

Copy link
Contributor

Choose a reason for hiding this comment

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

It'd be beneficial if this was somehow discoverable instead of needing it to be added explicitly for every data source.

name: "ipc",
per_run_rule: function* (ruleOpts: RuleOpts) : Generator<Finding, void, any> {
let diff = percent_difference(ruleOpts.base_run_data, ruleOpts.this_run_data);
if (diff > 10) {
Copy link
Contributor

Choose a reason for hiding this comment

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

do we want this % to be fixed?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Currently yes. Maybe once folks use it and get back with details about other units we can change it.

return key_value_map;
}

function percent_difference(v1, v2) {
Copy link
Contributor

Choose a reason for hiding this comment

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

v1 and v2 should be typed as number correct? This function should also return a number.

}

fn get_values(values: Vec<PerfStat>, key: String) -> Result<String> {
fn get_values(values: Vec<PerfStat>, key: String, metrics: &mut DataMetrics) -> Result<String> {
Copy link
Contributor

Choose a reason for hiding this comment

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

Since every data source is going to implement something like this, shouldn't we make a rust trait to hold some of the assumed common functionality every data source needs?

let all_rules: Rules[] = [
system_info_rules,
cpu_utilization_rules,
perf_stat_rules,
Copy link
Contributor

Choose a reason for hiding this comment

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

It'd be beneficial if this was somehow discoverable instead of needing it to be added explicitly for every data source.

@janaknat janaknat merged commit 5894806 into aws:main Mar 13, 2025
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants