►
From YouTube: 2022-08-26 meeting
Description
Instrumentation: Messaging
A
A
C
Hi
dmitry,
oh
man,
your
office
looks,
looks
empty
today.
It's.
A
B
A
B
B
C
Gotta
save
the
gotta,
save
that
energy
turn
the
lights
off.
That's
what
they're
doing
behind
you.
C
It
looks
like
maybe
there
was.
C
It
looks
like
maybe
last
week
this
meeting
didn't
happen.
I
don't
think
I
was
there
last
week.
C
Want
to
do
it
myself,
yeah.
I
know
I
do
the
same
thing.
Well,
I
can
share
the
screen
today.
I've
got
it
pulled
up
already
go
ahead
and
instead
of
starting
at
the
top,
I
thought
we
could
start
at
the
where
we
left
off
last
time,
which
I
think
was
here,
but
someone
did
that
once
I'm
gonna
go
to
the
second
page,
I'll
just
go
up
from
the
bottom,
sound
good.
C
Sweet
this
one's
got
a
pr
open
already,
so
I'm
just
going
to
assign
it
to
newly
and.
A
C
B
C
Sweet
right.
B
Okay,
yeah,
let's
assign
to
him
to
them
and
and
probably
p2.
I
believe.
A
A
C
Yeah
he's
assigned
himself
put
that
on
there
and
p2.
C
B
Like
severity
and
that's
mostly,
it
yeah
buddy
yeah,
timestamp,
timestamp,
okay,
cool.
B
C
B
Is
that
we
want
to
automatically
generate
docs
from
config.go,
and
the
docs
should
be
should
be
like
yaml
format
and
with
all
the
like
documentation
about
all
of
the
fields
and
the
faults
currently
is.
It
can
be
with
this
tool
that
pablo
did,
but
it
generates
like
not
very
human,
readable
format,
it's
like
tables
and
so
on.
We
want
to
make
it
like
gotcha.
B
B
It's
do
it,
it
is
enhancement.
Yes,
it
is
an
enhancement,
it's
not
a
bucket,
I
believe,
and
I
would
yeah
I
would
put
because
we
already
have
that.
C
A
C
C
A
A
C
Well,
there
they've
linked
to
something
that's
in
the
trench
but
yeah
I
don't
I
can
put
yesterday,
I'm
just
going
to
also
ping
anthony
and
dimitri
or
not
dimitri,
david.
A
A
B
C
A
C
B
A
A
C
Yeah
so
like
personally,
would
replace
the
entire
attributes
processor,
but
like
community,
like
that's
a
pretty
entrenched
processor,
so
like
I'd
like
to
replace
it
completely
and
have
people
use
the
transform
processor.
But
I
could
also
foresee
a
world
where
the
attributes
processor
just
uses
the
conditions
from
the
telemetry
query
language
package.
I
don't.
A
That
is
focus
on
attributes
if
we
want
based
on
tql
or
whatever
the
transferring
language
or
or
give
them
a
equivalent
of,
like
condition
configuration
in
in
right.
C
That's
why
I'm
working
on
I've
actually
got
a
pr
out
there
right
now
for
a
declarative
syntax
for
the
trans
for
the
telemetry
query
language,
to
make
things
like
this
easier
that
it's
possible
that
the
attributes
processor
sticks
around,
but
it
behind
the
scenes.
It's
updated
to
use
the
telemetry
query
language
and
its
declarative,
syntax
versus,
like
everyone
replacing
all
of
their
processes
everywhere.
I
don't
know
yet.
C
C
B
C
B
C
A
Not
package
with
the
with
that
process.
A
C
A
C
A
C
B
C
A
B
B
So
so
we're
going
to
discuss
now
if
we
have
time
so,
the
idea
is
that
we
we
want
to
introduce
another
receiver
that
takes
metric
from
the
database
and
those
metrics
are
internal,
existing
metrics
and
that's
that
will
be
oracle
db
receiver.
But
we
already
have
like
generic
sql
query
receiver,
that
essentially,
like
you,
provide
some
like
sql
queries
you
get
metrics
from.
So
we
want
to
utilize
that
receiver,
instead
of
instead
of
introducing
new
one
and
like
actually
the
duplicating
all
the
work,
all
the
code,
yeah.
A
B
To
for
database
connection
and
stuff
like
that,
so
we
want
some
interface
that
we
can
use
where
it
will
accept,
like
queries
and
or
metrics
that
we
will
get
the
results
without
and
the
the
question
like.
If
we
go
that
road,
do
we
want
to
have
each
receiver
for
four
different
database
and
reuse,
a
sql
query
receiver?
As
a
library
we
want
to
have
sql
library,
sql,
query
receiver,
with
some
kind
of
presets,
with
some
kind
of
preconfigured
like
options
for
for
system
metrics
or
which
database
something
like
that.
B
C
Would
just
the
config
would
switch
the
driver
kind
of
like
the
resource
detection,
processor
kind
of
like
switches
out?
You
know
what
you're
detecting.
B
But
the
set
of
query
sql
queries
that
we
we
use
to
get
the
internal
metrics
will
be
will
be
different
based
by
by
driver,
but
I'm
thinking
it
can
be
also
different.
Based
on
the
like
database
version
right
postgres
different
postgres
version
can
use
different
different
database
for
internal
metrics
and
things
like
that,
but
that
also
can
be
configured
in
one
and
one
receiver
instead
of
different
receivers.
So
that's
that's
mostly
the
question
here.
C
C
Reducing
components,
that's
why
I
like
the
transform
processor
as
long
as
like
the
configuration
for
that
component,
isn't
really
complicated.
I
guess
like
if
there's
gonna
be
like
totally
different
config
sections
for
the
different
drivers.
That
might
be
an
indicator
that
it
should
be
different
components,
but
if
they
can
be
simply
reduced
and
then
just
have
like
you
know,
flags
that
switch
what
things
are
being
used
and
I
think
a
single
component
could
make
sense.
B
In
that
component,
we
already
have
driver.
We
need
to
specify
which
driver
to
use.
We
probably
will
have
another
version,
I
believe,
but
it's
not
necessary
and
the
only
additional
the
configuration
interface
is
going
to
be
like
scrap
system,
metrics,
true
or
false,
and
likely
it
will
be
false
by
default.
This.
This
is
my
like
my
idea
about
that.
So,
if
you
use
the
same
receiver,
it
will
be
just
additional
one
additional
option
for
so
far
as
boolean
option
and
like
a
set
of
set
of
system
metrics
will
be
predefined
in
the
receiver
itself.