Skip to content

Cloud Health Dashboard Step 0: Set up Metrics Registry. #10478

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

Merged
merged 17 commits into from
Feb 22, 2022

Conversation

davinchia
Copy link
Contributor

@davinchia davinchia commented Feb 19, 2022

What

Set up a Metrics Registry. The purpose of this registry is to better enforce metrics -> application relationship, metric -> description relationship, provide a central location where folks can understand what metrics OSS AB emits, and enforce some standards.

Past experience has shown me that metrics emission can quickly get out of hand: 1) unclear what is emitted 2) similar metrics emitted in multiple places 3) not clear what metrics corresponds to what application.

This is my attempt to provide a framework for us to operate in.

Let me know if folks think this provides more complexity than is useful.

I've added the KubePodProcess metric in here to demonstrate/test how everything will work in practice.

How

  • Introduce the AirbyteApplications and the AirbyteMetricsRegistry enums to make it clear what applications are emitting metrics, and what metrics are related to what application.
  • Revamp the DogStatsDMetricsSingleton to handle publishing when publish is both true and false. Add a test case to confirm this.
  • Revamp the DogStatsDMetricSingleton to interface with the AirbyteApplication interface and the AirbyteMetricRegistry class to enforce the contracts.
  • Add the KubePodProcess metric to demonstrate how this is all meant to be used.

Recommended reading order

  1. AirbyteApplication.java and AirbyteApplications.java to understand how applications are tracked.
  2. AirbyteMetricRegistry.java to understand how this fits in with everything.
  3. 'KubePodProcess.java` to see how metrics are meant to be used.
  4. Everything else.

🚨 User Impact 🚨

Are there any breaking changes? What is the end result perceived by the user? If yes, please merge this PR with the 🚨🚨 emoji so changelog authors can further highlight this if needed.

Pre-merge Checklist

Expand the relevant checklist and delete the others.

New Connector

Community member or Airbyter

  • Community member? Grant edit access to maintainers (instructions)
  • Secrets in the connector's spec are annotated with airbyte_secret
  • Unit & integration tests added and passing. Community members, please provide proof of success locally e.g: screenshot or copy-paste unit, integration, and acceptance test output. To run acceptance tests for a Python connector, follow instructions in the README. For java connectors run ./gradlew :airbyte-integrations:connectors:<name>:integrationTest.
  • Code reviews completed
  • Documentation updated
    • Connector's README.md
    • Connector's bootstrap.md. See description and examples
    • docs/SUMMARY.md
    • docs/integrations/<source or destination>/<name>.md including changelog. See changelog example
    • docs/integrations/README.md
    • airbyte-integrations/builds.md
  • PR name follows PR naming conventions

Airbyter

If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.

  • Create a non-forked branch based on this PR and test the below items on it
  • Build is successful
  • Credentials added to Github CI. Instructions.
  • /test connector=connectors/<name> command is passing
  • New Connector version released on Dockerhub by running the /publish command described here
  • After the connector is published, connector added to connector index as described here
  • Seed specs have been re-generated by building the platform and committing the changes to the seed spec files, as described here
Updating a connector

Community member or Airbyter

  • Grant edit access to maintainers (instructions)
  • Secrets in the connector's spec are annotated with airbyte_secret
  • Unit & integration tests added and passing. Community members, please provide proof of success locally e.g: screenshot or copy-paste unit, integration, and acceptance test output. To run acceptance tests for a Python connector, follow instructions in the README. For java connectors run ./gradlew :airbyte-integrations:connectors:<name>:integrationTest.
  • Code reviews completed
  • Documentation updated
    • Connector's README.md
    • Connector's bootstrap.md. See description and examples
    • Changelog updated in docs/integrations/<source or destination>/<name>.md including changelog. See changelog example
  • PR name follows PR naming conventions

Airbyter

If this is a community PR, the Airbyte engineer reviewing this PR is responsible for the below items.

  • Create a non-forked branch based on this PR and test the below items on it
  • Build is successful
  • Credentials added to Github CI. Instructions.
  • /test connector=connectors/<name> command is passing
  • New Connector version released on Dockerhub by running the /publish command described here
  • After the new connector version is published, connector version bumped in the seed directory as described here
  • Seed specs have been re-generated by building the platform and committing the changes to the seed spec files, as described here
Connector Generator
  • Issue acceptance criteria met
  • PR name follows PR naming conventions
  • If adding a new generator, add it to the list of scaffold modules being tested
  • The generator test modules (all connectors with -scaffold in their name) have been updated with the latest scaffold by running ./gradlew :airbyte-integrations:connector-templates:generator:testScaffoldTemplates then checking in your changes
  • Documentation which references the generator is updated as needed

…cation and metrics, and metrics and description.
@github-actions github-actions bot added area/platform issues related to the platform area/scheduler labels Feb 19, 2022
@davinchia davinchia changed the title Cloud Health Step 1 Cloud Health Dashboard Step 0: Set up Metrics Registry. Feb 21, 2022
@davinchia davinchia temporarily deployed to more-secrets February 21, 2022 07:41 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 21, 2022 07:41 Inactive
@github-actions github-actions bot added the area/worker Related to worker label Feb 21, 2022
@davinchia davinchia temporarily deployed to more-secrets February 21, 2022 08:13 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 21, 2022 08:13 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 21, 2022 08:32 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 21, 2022 08:32 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 21, 2022 09:50 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 21, 2022 09:50 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 21, 2022 11:27 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 21, 2022 11:27 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 21, 2022 11:51 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 21, 2022 11:51 Inactive
@davinchia
Copy link
Contributor Author

Confirmed the Kube Pod Process metric is showing up in dev-1

Screen Shot 2022-02-21 at 7 52 18 PM

@davinchia davinchia temporarily deployed to more-secrets February 21, 2022 15:11 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 21, 2022 15:12 Inactive
@davinchia davinchia marked this pull request as ready for review February 21, 2022 15:17
@davinchia davinchia requested a review from pmossman February 21, 2022 15:17
Copy link
Contributor

@cgardens cgardens left a comment

Choose a reason for hiding this comment

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

Looks good!

I want to call out the env var parsing. It feels like we are going backwards on our initiative to not access env vars from within the codebase. See comment below.

* Enum containing all applications metrics are emitted for. Used to initialize
* {@link DogStatsDMetricSingleton#initialize(AirbyteApplication, boolean)}.
*
* Application Name Conventions:
Copy link
Contributor

Choose a reason for hiding this comment

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

calling out the convention is great! thank you.

throw new RuntimeException("You cannot initialize configuration more than once.");
}

if (!publish) {
Copy link
Contributor

Choose a reason for hiding this comment

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

it's a little hard for me to understand the different configurations.

  1. line 43: if not publish then create the singleton but it won't publish anywhere
  2. line 49: create singleton specifying dd host and port
  3. line 55: ??? not sure.

it might be useful to have comments either in initialize or javadocs comments for the constructor to understand what each of these configurations mean.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

you are right, I've added comments and doc strings. Does this make more sense?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

some of this is invalidated by the env var change. please take another look

Copy link
Contributor

Choose a reason for hiding this comment

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

nice!

instancePublish = publish;
statsDClient = new NonBlockingStatsDClientBuilder()
.prefix(appName)
.hostname(System.getenv("DD_AGENT_HOST")) // Matches Airbyte Cloud Datadog env vars.
Copy link
Contributor

Choose a reason for hiding this comment

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

why are we parsing env variables here? is there a reason we wouldn't pass this through EnvConfigs like we do with other env variables? In october there was a big refactor to make sure we weren't paring env variables anywhere in the code base but centralize it all through EnvConfigs and push it to the top of the application. I want to make sure we don't revert those efforts.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

good question. my initial thoughts were to place this in the constructor for convenience and also expose a flexible constructor to allow injecting (keeping our clean up in mind). I was also thinking of 'hiding' the variables for monitoring since they are cloud specific.

on second thought, no reason to keep this away from OSS users. we can put it in the env vars like you pointed out and document this for OSS folks with Datadog. How is that?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

made the changes - looks much cleaner now

Copy link
Contributor

Choose a reason for hiding this comment

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

nice!

}

/**
* Submit a single execution time aggregated locally by the Agent. Use this if approximate stats are
Copy link
Contributor

Choose a reason for hiding this comment

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

as a developer reading this, it's not clear what we mean for approximate versus precise stats and when i should use which method. can you add more clarity, please?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've updated this. Is this clearer?

Copy link
Contributor

Choose a reason for hiding this comment

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

better. i guess i'm still not clear on why i would ever use the non-precise one.

@davinchia davinchia temporarily deployed to more-secrets February 22, 2022 04:48 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 22, 2022 04:48 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 22, 2022 05:29 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 22, 2022 05:30 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 22, 2022 05:50 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 22, 2022 05:50 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 22, 2022 11:23 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 22, 2022 11:24 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 22, 2022 11:43 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 22, 2022 11:43 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 22, 2022 14:37 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 22, 2022 14:37 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 22, 2022 14:53 Inactive
@davinchia davinchia temporarily deployed to more-secrets February 22, 2022 14:54 Inactive
@davinchia
Copy link
Contributor Author

@cgardens I'm going to merge this in first to minimise any git management while I continue working on metrics. Please lmk if you disagree with anything - very happy to make changes.

@cgardens
Copy link
Contributor

looks good to me. i had the one open question on when to use the two different time measurements but definitely not blocking

@davinchia
Copy link
Contributor Author

davinchia commented Feb 22, 2022

I would use the histogram for the following reasons:

  1. there will only be one agent emitting the type (for accuracy).
  2. control over what kind of percentiles to emit - DD provides set percentiles when the metric is calculated globally.
  3. save cost by saving on number of DD metrics needed.

would it be helpful to add ^ to the docstring?

@cgardens
Copy link
Contributor

yes! great. thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/platform issues related to the platform area/scheduler area/worker Related to worker
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants