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

Gather BIT metrics [implementation] #3122

Merged
merged 20 commits into from
Jul 11, 2024
Merged

Gather BIT metrics [implementation] #3122

merged 20 commits into from
Jul 11, 2024

Conversation

originalsouth
Copy link
Contributor

Changes

See #3116

Issue link

See #3116

Demo

See #3116

QA notes

Please add some information for QA on how to test the newly created code.


Code Checklist

  • All the commits in this PR are properly PGP-signed and verified.
  • This PR only contains functionality relevant to the issue.
  • I have written unit tests for the changes or fixes I made.
  • I have checked the documentation and made changes where necessary.
  • I have performed a self-review of my code and refactored it to the best of my abilities.
  • Tickets have been created for newly discovered issues.
  • For any non-trivial functionality, I have added integration and/or end-to-end tests.
  • I have informed others of any required .env changes files if required and changed the .env-dist accordingly.
  • I have included comments in the code to elaborate on what is not self-evident from the code itself, including references to issues and discussions online, or implicit behavior of an interface.

Checklist for code reviewers:

Copy-paste the checklist from the docs/source/templates folder into your comment.


Checklist for QA:

Copy-paste the checklist from the docs/source/templates folder into your comment.

@originalsouth originalsouth requested a review from a team as a code owner June 20, 2024 17:03
@ammar92
Copy link
Contributor

ammar92 commented Jun 25, 2024

Quick question: this is supposed to be used during development and not as a publicly available feature flag, right?

Copy link
Contributor

@ammar92 ammar92 left a comment

Choose a reason for hiding this comment

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

Nice work, this will help us improve performance and provide valuable insights 👍 I do have a few questions and remarks to improve this even more.

Also, I still think we should eventually use OpenTelemetry for these kind of benchmarks or metrics gathering. It gives a more standardize way to deal with this and possibly save us a lot of code and effort in developing our own tools. This metric isn't the best example maybe, but it's close to what is possible with OpenTelemetry.

octopoes/tools/analyze-bit-metric.py Show resolved Hide resolved
octopoes/tools/analyze-bit-metric.py Outdated Show resolved Hide resolved
octopoes/tools/analyze-bit-metric.py Outdated Show resolved Hide resolved
@@ -89,3 +89,4 @@ def settings_customise_sources(
DEFAULT_LIMIT = 50
DEFAULT_OFFSET = 0
QUEUE_NAME_OCTOPOES: str = "octopoes"
GATHER_BIT_METRICS: bool = False
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure what the intention is, but usually feature flags are configurable. Perhaps this fits better in the Settings class and documented. This could work if it's only a private debug variable for development, although the location is bit misleading since it's placed next to the constants.

The bool hint is unnecessary here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The intention is to have a developer flag to toggle gathering [bit] metrics (without exposing it to the public). Please let me know what the best way of defining this would be.

octopoes/octopoes/core/service.py Outdated Show resolved Hide resolved
@originalsouth
Copy link
Contributor Author

Thanks @ammar92 for your review. I will address your style and efficiency concerns (whilst resolving the merge conflicts).

Regarding OpenTelemetry, can you elaborate on what you would like to see; where you would like this to go?

@ammar92
Copy link
Contributor

ammar92 commented Jul 4, 2024

Thanks @ammar92 for your review. I will address your style and efficiency concerns (whilst resolving the merge conflicts).

Thanks and welcome back!

Regarding OpenTelemetry, can you elaborate on what you would like to see; where you would like this to go?

Let's meet soon to discuss this. The main message I'd like to convey is that it could provide us with valuable insights into performance, but also how the application functions over time or the scoped timeline of a specific action within the application (e.g. what requests were made, in what order and consumed time).

@stephanie0x00
Copy link
Contributor

@originalsouth Could you also rename the branch from 'feature/3116' to something more descriptive? This will make typing release notes much easier. Thanks!

@originalsouth
Copy link
Contributor Author

originalsouth commented Jul 4, 2024

@originalsouth Could you also rename the branch from 'feature/3116' to something more descriptive? This will make typing release notes much easier. Thanks!

We had this discussion before, branch names do not matter whatsoever and make a whole mess when changing. I can rename it if you insist but I do not see the point.

@underdarknl
Copy link
Contributor

underdarknl commented Jul 9, 2024

@originalsouth Could you also rename the branch from 'feature/3116' to something more descriptive? This will make typing release notes much easier. Thanks!

We had this discussion before, branch names do not matter whatsoever and make a whole mess when changing. I can rename it if you insist but I do not see the point.

Lets keep our branch-names somewhat descriptive. They do matter in the creation of release notes, and when looking at the lists of branches. having said that, there's no need to rename this branch, as I agree that will just make things messy.

@stephanie0x00
Copy link
Contributor

Checklist for QA:

  • I have checked out this branch, and successfully ran a fresh make reset.
  • I confirmed that there are no unintended functional regressions in this branch:
    • I have managed to pass the onboarding flow
    • Objects and Findings are created properly
    • Tasks are created and completed properly
  • I confirmed that the PR's advertised feature or hotfix works as intended.
  • I checked the logs for errors and/or warnings and made issues where necessary

What works:

Ran into some issues while running the scripts, which resulted in a few changes. Those are now fixed and it looks great. Only thing that remains is writing documentation on how to use the scripts. This will be picked up in #3228

What doesn't work:

n/a

Bug or feature?:

n/a

@underdarknl underdarknl merged commit 9b38852 into main Jul 11, 2024
20 checks passed
@underdarknl underdarknl deleted the feature/3116 branch July 11, 2024 09:34
jpbruinsslot added a commit that referenced this pull request Jul 16, 2024
* main: (31 commits)
  Refactor Task List and filters with error handlers for Scheduler  (#1957)
  Fix filtering on plugin_id for normalizers (#3226)
  Implement `structlog` (#3175)
  Gather BIT metrics [implementation] (#3122)
  Add observation data to observation table in OOI detail page (#3186)
  cve-2024-6387 from RickGeex (#3194)
  Recalculate bit when a config object changes (#3206)
  Use more concise regexes (#3181)
  Updated Django (#3217)
  Updated `zipp` (#3215)
  Feature/boefje normalizer config models (#3118)
  Updated `certifi` (#3209)
  Add pluginToggler.js to Aggregate Report (#3202)
  Update to Django 5.0 (#2939)
  Update Dockerfile, fix Sonarcloud issue (#3180)
  Better default list of world writable domains in CSP checker (#3165)
  Update 1.16 release notes (#3195)
  Remove non standard header findings and add deprecated headers findings (#3127)
  Fix/sonarcloud https redirect dockerfiles (#3185)
  Bump docker/build-push-action from 5 to 6 (#3164)
  ...
@originalsouth originalsouth restored the feature/3116 branch July 29, 2024 14:07
@originalsouth originalsouth deleted the feature/3116 branch July 29, 2024 14:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

4 participants