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

feat(monitors): Ingestion for basic check-in payloads #1886

Merged
merged 10 commits into from
Mar 2, 2023
Merged

Conversation

jan-auer
Copy link
Member

@jan-auer jan-auer commented Feb 27, 2023

This adds ingestion for cron monitor checkin payloads through Relay. Initially, this just covers creating and updating checkins, but not monitors. Rate limits can be set and enforced, but there will be no outcomes tracked.

  • New data category
  • New item type
  • Crate for cron-specific logic
  • Rate limiting support
  • Limit for item sizes
  • Validator function in processing mode
  • Kafka topic (defaulting to ingest-monitors)
  • Kafka producer (for now as msgpack)
  • Schema implementation
  • Normalization from the cron PUT payloads

Follow-up:

  • Track outcomes
  • Define rate limiting semantics
  • Add a cron endpoint

See getsentry/sentry#45079 for the consumer.
Requires https://github.com/getsentry/ops/pull/6226

@jan-auer jan-auer self-assigned this Feb 27, 2023
Copy link
Contributor

@olksdr olksdr left a comment

Choose a reason for hiding this comment

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

overall LGTM, but I would rename all the Checkin to CheckIn , checkin to check-in, and Cron to CronMonitor

relay-crons/src/lib.rs Outdated Show resolved Hide resolved
relay-crons/src/lib.rs Outdated Show resolved Hide resolved
relay-common/src/constants.rs Outdated Show resolved Hide resolved
relay-crons/src/lib.rs Outdated Show resolved Hide resolved
relay-kafka/src/config.rs Outdated Show resolved Hide resolved
let mut checkin = serde_json::from_slice::<Checkin>(payload)?;

// Missed status cannot be ingested, this is computed on the server.
if checkin.status == CheckinStatus::Missed {
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if there will be cases we want to allow the user to send missed checkins.

This is fine for now


/// Identifier of the monitor for this checkin.
#[serde(serialize_with = "uuid_simple")]
monitor_id: Uuid,
Copy link
Member

Choose a reason for hiding this comment

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

I believe this is going to become monitor_slug as I mentioned to you.

Let me get confirmation for getsentry/sentry#45166 first though.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sounds good. I'd propose we merge as-is and follow up with a set of PRs for Relay + Sentry once this has cleared up.

Comment on lines 65 to 66
/// Status of this checkin. Defaults to `"unknown"`.
status: CheckinStatus,
Copy link
Member

Choose a reason for hiding this comment

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

Don't we need a #[serde(default)] here to derive the default in case the field is missing from the payload?

Copy link
Member Author

@jan-auer jan-auer Feb 28, 2023

Choose a reason for hiding this comment

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

I've had this discussion with @cleptric . The current endpoint requires this field. We're thinking about making it optional as long as we can still break this API. @evanpurkhiser would you like it to be optional right away?

relay-crons/src/lib.rs Outdated Show resolved Hide resolved
@jan-auer jan-auer changed the title feat(crons): Ingestion for basic cron payloads feat(monitors): Ingestion for basic check-in payloads Feb 28, 2023
@jan-auer
Copy link
Member Author

I've updated naming to be consistently:

  • monitor / monitors for everything that regards the product, the general topic (Kafka) and the data category
  • CheckIn / check_in for the check-ins. This is chosen over MonitorCheckIn for brevity and also because it is more consistent with other models we have at Sentry (e.g. we have spans, not TransactionSpan). Replays are more of an exception here. Also, it's shorter.

* master:
  doc(py): Add changelog entries (#1900)
  fix(build): Run check when PR is ready for review (#1899)
  chore(project_local): Allow to follow symlinks for projects configs (#1891)
  ref(project): Skip serializing default fields (#1887)
  chore(build): Run changelog check for draft PRs (#1897)
  chore(sentry): Add environment config option (#1890)
  feat(scrubbing): Scrub `span.data.http.query` with default scrubbers (#1889)
@jan-auer jan-auer marked this pull request as ready for review March 2, 2023 08:45
@jan-auer jan-auer requested a review from a team March 2, 2023 08:45
Copy link
Member

@jjbayer jjbayer 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, but please do see comments, especially about outcomes.

check_in.status = CheckInStatus::Unknown;
}

Ok(serde_json::to_vec(&check_in)?)
Copy link
Member

Choose a reason for hiding this comment

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

@jan-auer did you still want to make this copy-on-write?

Copy link
Member Author

Choose a reason for hiding this comment

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

No, I intentionally removed that because we always need to normalize the status enum.

Copy link
Member

Choose a reason for hiding this comment

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

Right, because the deserializer maps to Unknown, gotcha. You could even remove the Missed variant then, though it also makes sense to keep that explicit.

InProgress,
/// Monitor did not check in on time.
Missed,
/// No status was passed.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
/// No status was passed.
/// No status was passed.
///
/// When we enable check-in deserialization in external relays, this should become `Unknown(String)` for forward compatibility.

Copy link
Member Author

Choose a reason for hiding this comment

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

Not necessarily, that depends on the kind of normalization we're doing in external Relays. It may be safer to keep it as "Unknown" rather than applying the wrong normalization (same to the metrics extraction version).

true
}
Err(error) => {
// TODO: Track an outcome.
Copy link
Member

Choose a reason for hiding this comment

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

Are we OK with not tracking outcomes here?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, the backend also doesn't track outcomes yet, and it's not yet clear whether we want to track per check-in update or only per check-in.

@jan-auer jan-auer merged commit 719d39a into master Mar 2, 2023
@jan-auer jan-auer deleted the feat/crons-mvp branch March 2, 2023 09:48
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