-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
chore: Remove Atoms #4485
chore: Remove Atoms #4485
Conversation
Signed-off-by: Ana Hobden <operator@hoverbear.org>
Signed-off-by: Ana Hobden <operator@hoverbear.org>
Signed-off-by: Ana Hobden <operator@hoverbear.org>
Signed-off-by: Ana Hobden <operator@hoverbear.org>
Signed-off-by: Ana Hobden <operator@hoverbear.org>
Signed-off-by: Ana Hobden <operator@hoverbear.org>
#[instrument(skip(self, key), fields(key = %key.as_ref()))] | ||
pub fn insert( | ||
&mut self, | ||
key: impl AsRef<str>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Future work we should probably upgrade this to an owned string so we can insert that allocation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed
src/internal_events/elasticsearch.rs
Outdated
@@ -21,7 +20,7 @@ impl InternalEvent for ElasticSearchEventReceived { | |||
|
|||
#[derive(Debug)] | |||
pub struct ElasticSearchMissingKeys { | |||
pub keys: Vec<Atom>, | |||
pub keys: Vec<String>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Event Driven Observability RFC suggests we do not use Vec<String>
here, and a &[&str]]
would be better.
pub struct ElasticSearchMissingKeys { | ||
pub keys: Vec<Atom>, | ||
pub struct ElasticSearchMissingKeys<'a> { | ||
pub keys: &'a [String], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Allowing this instead of a &'a [&'a str]
removes the need for the code that calls this to make an extra allocation through a by_ref()
call.
Signed-off-by: Ana Hobden <operator@hoverbear.org>
Signed-off-by: Ana Hobden <operator@hoverbear.org>
src/sources/docker.rs
Outdated
static ref NAME: Atom = Atom::from("container_name"); | ||
static ref STREAM: Atom = Atom::from("stream"); | ||
static ref CONTAINER: Atom = Atom::from("container_id"); | ||
static ref IMAGE: &'static str = "image"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These should be const
Signed-off-by: Ana Hobden <operator@hoverbear.org>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome!
I focused on src/event
and other non-component or internal events files and just scanned the rest since it seemed to be mechanical.
|
||
#[derive(PartialEq, Debug, Clone, Default)] | ||
pub struct LogEvent { | ||
fields: BTreeMap<String, Value>, | ||
} | ||
|
||
impl LogEvent { | ||
pub fn get(&self, key: &DefaultAtom) -> Option<&Value> { | ||
util::log::get(&self.fields, key) | ||
#[instrument(skip(self, key), fields(key = %key.as_ref()))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see you've been adding these since the introduction of the Lookup
type. Do you recommend we add them to all methods? Or just certain ones? They seem useful for tracing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We haven't really made an architectural call one way or the other. What they do is populate the span: https://tracing-rs.netlify.app/tracing/attr.instrument.html, so if we did wide adoption we might be able to reap some really nice contextual rewards. It's a practice I've been doing in my own code lately. I'm not sure if @lukesteensen has an opinion though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've seen these used as well.
I agree that better instrumentation is a worthy goal, but I would prefer if we at least document how/why we use them, including some best-practices/patterns everyone should follow.
I don't mind if it's in an RFC or a "tracking issue" that contains some context, and a few relevant links.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
better instrumentation is a worthy goal, but I would prefer if we at least document how/why we use them, including some best-practices/patterns everyone should follow.
I agree! I'd also note that we should strive to be as consistent as possible across the codebase. The macro is cool and useful, but right now it mostly tells me which code was written by @Hoverbear 😄
An easy first step would be to open an issue for setting some guidelines around thing kind of instrumentation. We'll want to cover #[instrumented(...)]
vs trace!
vs emit!
, message style, etc in the eventual guidelines, but for now, maybe @Hoverbear can just summarize her current thoughts as a starting point for the conversation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd love to! For now, as a note #[instrument]
just creates a span when the function is entered, with the function args (or as configured) as span items. It's dropped when the function exits. That's all it does. :)
It doesn't log. :)
Signed-off-by: Ana Hobden <operator@hoverbear.org>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks mostly ok, but I added a number of questions.
I am also concerned that, if we are serious about moving to either smolstr or smartstring for keys, we will end up reverting most of these changes and converting all Atom
to SmartString
or whatever.
#[instrument(skip(self, key), fields(key = %key.as_ref()))] | ||
pub fn insert( | ||
&mut self, | ||
key: impl AsRef<str>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed
Signed-off-by: Ana Hobden <operator@hoverbear.org>
@bruceg I feel if we move to smolstr or otherwise, we'll be able to internalize this decision making to the |
* Instrument eventlog Signed-off-by: Ana Hobden <operator@hoverbear.org> * Migrate get Signed-off-by: Ana Hobden <operator@hoverbear.org> * Migrate get_mut Signed-off-by: Ana Hobden <operator@hoverbear.org> * insert and try_insert migration Signed-off-by: Ana Hobden <operator@hoverbear.org> * Migrate remove Signed-off-by: Ana Hobden <operator@hoverbear.org> * wip Signed-off-by: Ana Hobden <operator@hoverbear.org> * Remove atom Signed-off-by: Ana Hobden <operator@hoverbear.org> * fmt Signed-off-by: Ana Hobden <operator@hoverbear.org> * Fixup Signed-off-by: Ana Hobden <operator@hoverbear.org> * Fixups Signed-off-by: Ana Hobden <operator@hoverbear.org> * Fixups Signed-off-by: Ana Hobden <operator@hoverbear.org> * Internal event fixups Signed-off-by: Ana Hobden <operator@hoverbear.org> * remove a comment Signed-off-by: Ana Hobden <operator@hoverbear.org> * Fixup some consts Signed-off-by: Ana Hobden <operator@hoverbear.org> * Fixups Signed-off-by: Ana Hobden <operator@hoverbear.org> * fixup trailing Signed-off-by: Ana Hobden <operator@hoverbear.org> * chore: Fixup Cargo deny Signed-off-by: Ana Hobden <operator@hoverbear.org> * Fixups Signed-off-by: Ana Hobden <operator@hoverbear.org> * fmt Signed-off-by: Ana Hobden <operator@hoverbear.org> Signed-off-by: Brian Menges <brian.menges@anaplan.com>
A component of https://github.com/timberio/vector/blob/c4707947bd876a0ff7d7aa36717ae2b32b731593/rfcs/2020-05-25-more-usable-logevents.md#sales-pitch
Precursor of #2843