►
From YouTube: 2020-09-30 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
A
A
Hi,
do
you
want
to
introduce
yourself?
I
don't
think
we've
met.
B
B
So
right
now
we're
just
looking
through
other
logging,
libraries
that
exist
in
c,
plus,
plus
and
seeing
all
of
the
features
that
they
have
and
we're
like
compiling
a
big
list
of
features
that
we
want
to
have
for
our
own
logging
library.
A
A
So
that's,
I
guess
different
from
what
we
wanted
to
do
for
most
of
the
languages
where
there
is
more
or
less
standard
logging
library,
which
it
is
not
the
case
for
c
plus
plus,
as
far
as
I
know,
so
that
may
be
one
of
the
languages
where
you
actually
rightfully
need
to
go
and
implement
a
new
one
yeah,
but
I'd
like
to
maybe,
if
you're
doing
any
sort
of
design
for
the
logging
library
within
the
c
plus
plus
sig.
A
I
I'd
like
to
maybe
be
involved
in
that
the
part
of
that
discussion.
What
do
you
guys
want
to
do
right
right
is
there
is,
when
is
the
class
last
week.
A
A
Almost
so
I'm
putting
here
in
the
zoom
chat,
this
is
the
higher
level
understanding
of
how
we
we
think
the
logs
in
open
parameters
should
work
there
are.
There
are
some
references
to
also
people.
How
think
we
think
the
local
libraries
should
be
up
there.
B
Yes,
yeah,
I
remember
just
looking
at
this
document.
I
just
forgot
yeah.
I
remember
reading
that
for
languages
with
the
really
specified
logging
library
that
it
would
be
better
just
to
create
like
an
extender
for
that,
so
we
don't
have
to
implement
everything
ourselves
but
yeah.
I
don't
think
c
plus
has
one
of
those
libraries
right
right.
A
C
One
consideration
I
definitely
would
put
in
as
you
design
this
is
to
separate
the
logging
transfer
from
the
logging
user
interface
so
make
sure
that,
like
because
there's
a
bunch
of
stuff
that
just
you're
taking
a
long
log
entry
and
passing
it
off
to
wherever
you're
going
to
export.
If
you
make
that
a
different
unit,
then
you
know
the
actual
log.debug
call
yeah,
then
that
allows
that
piece
to
be
used
by
other
libraries
as
well.
So
if.
B
B
Of
having
like
a
provider
class
and
then
the
actual
logger
class,
so
the
provider,
it
would
kind
of
like
return,
a
logger
which
you
could
write
to.
But
then
the
implementation
of,
where
it's
being
written
to,
would
be
put
in
inside
the
provider,
which
I
think
is
how
c-sharp
does
it
in
the
I-logger
class.
C
Okay,
so
yes,
but
so
that's
actually,
so
if
you
have
it
as
a
provider
that
returns
a
logger,
so
the
provider
returns
your
user
interface.
Basically,
then
your
base
that
that's
basically
that
coupling
I'm
talking
about
right
right
so
in
in
you
know,
I
guess
you
could
use
that
as
an
adapter
as
well,
but
there's
a
lot
of.
C
We
can
definitely
talk
about
it,
but
trying
to
trying
to
think
about
it
in
terms
of
like
another,
another
c,
plus
plus
logging
library.
You
know
how
do
you
also
give
them
the
leg
up
so
that
they
can
also
output
to
open
telemetry
and
they.
A
Yeah,
so
I
think
that's
important
right.
You
are
implementing
a
login
library,
so
the
end
users
can
use
that
right,
but
think
of
some
other
login
libraries,
other
c
plus
hospitality,
libraries
who
may
be
interested
in
adding
support
for
sending
logs
to
open,
telemetry
or
in
open
planetary
compliance.
A
A
A
B
A
E
E
E
So
if
anyone
is
curious,
then
I
have
described
what
I
was
doing,
but
essentially
for
the
past
couple
of
weeks,
I
was
working
on
some
extensions,
open,
telemetry
collector,
adding
support
for
locks
to
some
of
the
processors,
and
I
realized
that
we
already
have
some
nice
capabilities
with
open,
telemetry
collector
for
locks,
so
maybe
we
could
try
and
enabling
it
and
running
it
as
a
part
of
a
pretty
standard
processing
chain
for
logs,
so
for
for
kubernetes,
one
of
the
ways
to
collect
locks.
E
E
Then
it
goes
through
some
filters
which
extract
some
metadata
attacks
from
kubernetes
influent
bit
and
then
it
might
be
configured
to
send
it
to
elasticsearch,
and
I
think
this
in
this
example
only
elasticsearch,
so
what
I
have
done
in
my
example,
I
have
changed
two
of
these
configuration
entries.
I
have
removed
filters
and
I
have
changed
output
to
send
it
to
an
open,
telemetry
collector
instance,
which
has
forward
protocol
now.
E
One
challenge,
if
we
want
to
have
kubernetes
metadata
tagging,
is
how
to
associate
each
lock
with
the
source
with
the
pot,
essentially
so
typically
for
for
traces.
We
either
have
this
information
coming
from
the
client
or
we
can
associate
them
then
source
connection
ip
address,
and
that
way
I
know
which
port
is
the
source
of
the
data
for
locks.
E
It
won't
work
because
if,
if
flunk
bit
is
running
in
in
in
in
demand
set
setting,
then
it
can
is
collect
logs
from
several
thoughts,
but
fortunately
we
have
one
source
of
the
information,
the
name
of
the
fire
with
with
the
lock
so
whenever,
when,
whenever
a
fluid
bit
is,
is
looking
at
this
data,
the
file
name
actually
contains
the
name
of
the
port,
the
name
of
the
id
of
the
container
and
other
information
which
are
put
into
fluent.attack
value
so
recently
it
I
think
it's
not
merged
yet,
but
the
pr
is
ready.
E
One
of
our
colleagues
was
working
on
attributes
processor
for
logs,
so
I'm
using
this
attribute
processor,
I
have
defined
an
action
that
takes
this
fluent
attack.
Key
and
using
regular
expression
extracts
some
information,
so
I'm
extracting
pod
name
here-
name,
space,
name,
container,
name,
container
id
and
and
etc,
and
this
actually
works.
So
I
have
my
small
toy
docker
desktop
with
kubernetes
running
locally.
E
We
have
the
original
lock,
but
we
we
have
this
fluent
attribute
and
it
was
nicely
expanded
into
these
attributes,
the
pod
name,
namespace
name,
container
name
and
etc.
However,
this
brings
to
two
questions.
The
first
one
is
that
our
kubernetes
processor
we
have
right
now
it
can
match
only
pot
ip,
not
pod
name,
it's
it's
simple
thing
to
change
it
to
pod
name,
but
I
just
wanted
to
check.
What's
your
opinion
on
that,
if
that
fits
the
the
processor
how
how
how
it
works.
E
The
second
challenge,
perhaps
more
interesting,
is
that
with
logs
typically
we're
getting
attributes
at
the
log
level
and
most
of
our
processors
or
many
of
our
processors
are
working
with
resources
and
resources,
at
least
for
data
coming
from
fluent
bit,
will
be
empty.
So
I
was
wondering
if
maybe
we
should
create
another
processor
for
logs,
but
maybe
not
only
for
logs,
that
could
group
the
records
by
some
attributes.
E
So,
for
example,
I
could
define
that
I
want
to
group
all
records
having
the
same
fluent
attack
together
or
maybe
any
other
attribute,
and
having
those
two
things.
We
could
pretty
much
replace
fluentd
for
many
of
them.
Workloads
where
it's
being
used
with
open,
telemetry
collector,
which
I
think
is,
is
critical,
so
yeah.
A
Yeah,
this
is
very
nice.
Thank
you.
So
a
couple
comments
on
the
first
of
all
the
names
of
the
attributes.
I
think
we
could
use
the
open
telemetrics
conventions
so,
for
example,
pod
name
in
open
telemetry,
it's
k8s.
exactly
we
could
do
that
now.
A
B
A
E
C
A
I
think
it's
reasonable.
Do
we
do
we
all
only
get
cold
name
and
namespace?
Is
there
a
uid
of
the
code?
Maybe
that's
that's
a
single,
better
identification
right
for
the
code.
E
A
Reasonable
that's
you're
right.
That
should
be
easy
to
do.
We
should
just
just
need
to
maintain
another
map
from
the
name
to
the
to
the
fold
information,
whether
it
should
be
a
configuration
or
push
option
or
no,
I
don't
know-
maybe
we'll
need
to
think
about
that.
Do
we
automatically
decide
how
we
identify
the
port?
Is
it
based
on
ip
address
based
on
name?
Maybe
it's
optional.
I
don't
know,
but
sounds
reasonable,
so
yeah.
A
E
And
this
brings
yeah
if,
because
this
brings
another
problem,
when
we
are
using
regular
expressions
in
attributes
to
extract
this
information,
where
we
are
limited
to
only
certain
characters
in
them
in
the
capture
group
names,
and
I
think
that
we
cannot
use
a
dot.
So
we
cannot
use
them
the
names
that
are
matching
the
conventions.
E
A
A
E
Yeah
yeah-
I
was
thinking
about
this
too,
and-
and
the
last
item
is
this
grouping
and
capability,
because
all
those
attributes
are
at
the
record
level
rather
than
resource
level,
and
I
think
that
well,
we
can
change
the
behavior
to
attack
the
the
at
the
record
level,
but
perhaps
it
will
be
better
to
move
those
attributes
to
to
resource
because
for
many
lock
formats
this
will
be
always
the
case
that
the
resource
will
be
empty
and
we'll
just
get
records
of
attributes,
and
that
might
be
a
common
scenario.
Yeah.
A
So
that's
essentially
a
grouping
by
certain
attributes
right
that
you
would
want
to
extract
as
a
resource.
I
think
that's
reasonable
too,
that
that
can
be
a
processor.
How
widely
will
it
will
be
used?
I
don't
know,
but
in
this
particular
case
I
think
that's
what
we're
getting
and
probably
for
many
of
other
log
sources
right,
because
they
are
flattened
when
we
read
them,
they
also
come
without
a
resource.
So
that's
yeah.
I
think
that
that
would
be
useful
to
us.
Okay,
great,
thank
you.
So
one
other
comment
regarding
the
chart.
A
We
have
very
recently
created
a
new
repository
for
help,
charts
at
open,
telemetry
and
victory
already
added
there
a
help
chart
for
open
planetary,
collective
deployment,
which
currently
supports
traces
and
metrics.
Only
that
particular
chart
the
configuration
specifies
only
traces
and
metrics.
We
could
add
logging
support
like
what
you
did
right.
Look
at
that
login
support
to
that
as
well.
The
only
concern
I
would
have
is
that
for
logging
we
also
include
fluent
bit,
which
is
an
additional
dependency
which
may
not
be
always
desirable.
A
So
perhaps
maybe
it's
a
variation
of
the
chart
if
it's
possible
to
configure
it
not
to
let's
say
I
don't
need
logging,
I
want
to
use
the
that
regular
chart,
but
I
only
want
to
use
traces
and
metrics,
so
I
don't
want
to
deploy.
I
don't
want
to
have
the
little
bit
part
of
it.
If
we
could
do
if
we
could
make
it
an
option
in
the
chart,
then
that
would
be
great
to
have
one
chart
where,
where
you
would
plug
it
in
you
get
all
three
signals.
A
Otherwise,
maybe
it's
an
additional
separate
alternate
chart
with
all
three
signals,
but
what
I'm
saying
is
that
there
is
a
repository
we
have
a
place
already
for
for
this
sort
of
things,
so
I
think
it
would
be
very
beneficial
to
whatever
you're
doing
to
try
to
put
the
in
that
particular
repository.
So
we
have
the
official
openclimatry
chart
for
for
the
collector.
E
Yeah,
absolutely
and
with
home,
chart
it's
fairly
easy
to
to
toggle
options,
so
it
can
be
like
turned
off
by
default,
for
example,
and
enabled
only
for
someone
that
want
to
play
with
it,
at
least
in
the
initial
phase.
Okay,
I
think.
D
Yeah
I
mean
again
tigran
to
your
point.
This
is
alita,
that's
a
good
idea,
but
it's
just
that.
Isn't
this
experimental
still
or
you
know.
A
C
A
D
Yeah
I
mean
maybe
we
could
mark
and
help
chart
development.
You
know
like
a
developer
version
and
just
have
it
available.
There.
A
Yeah,
I
think
it
would
be
useful
to
also
check
what
dmitry
does
he,
I
think,
just
yesterday.
I
believe
he
mentioned
he
wanted
to
do
something
like
this.
He
may
already
also
have
something
there
so
just
just
to
make
sure
there's
no
duplicate
I'll.
Send
you
the
link
to
the
the
new
repository
for
help
charts.
You
can
create
an
issue.
Maybe
there
and
you
can
have
a
discussion
in
the.
A
D
So
tigran
just
just
wanted
to
again
say
hi
to
david
as
lspm.
We
were
on
a
thread
earlier
and-
and
you
know,
as
as
you
may
know,
two
of
our
interns-
I've.
We
have
been
working
with
riley
and
max
on
the
c,
plus
plus
team
and
c
plus
plus
sig,
to
identify
a
logging
implementation
and
work
on
it
with
two
of
our
interns
working
there.
D
So
again
would
definitely
like
to
learn
from
david's,
and
you
know,
pmm's
in
implementations
and
was
wondering
what
is
the
best
way
to
coordinate
that,
because
we
do
have
an
regular
sync
on
the
c
plus
plus
sig.
But
again
it
is
more
towards
also,
you
know,
adding
to
the
logging,
spec
and
and
having
initial
pocs
that
actually
can
add
value
back
to
the
overall
spec.
A
Yeah,
we
just
had
that
very
brief
discussion
around
that.
So
we
I'd
like
to
attend
whenever
there
is
a
discussion
in
c
plus
plus
c
about
vlogging
I'd
like
to
attend
that,
okay,
to
see
how
I
can
help.
I
also
have
the
the
the
the
design
dock.
A
So
I
will
have
a
look
at
the
c
plus
faster
library,
design.
Docker
I'll
have
asked
that
okay
and
do
definitely
attend
this
particular
meeting,
and
we
can.
E
A
Being
seen
around
what
is
happening,
there's
also
the
the
ongoing
implementation
that
david
works
on
for
java.
I
believe
for
c
plus
plus
it's
going
to
be
somewhat
different,
because
there
is
no.
D
A
Want
to
do
full
loading
libraries,
but
yes,
I'll,
have
a
look
at
the
design.
I
will
just
just.
Let
me
know
if
you
can.
E
D
A
We
were
somewhat
in
somewhat
frozen
state
because
of
the
efforts
to
release
the
traces
and
specs,
and
hopefully
that's
almost
out
of
the
way,
and
we
can
then
work
more
on
the
logging
aspects.
This
is
very
good.
D
So
tigran
also
on
another
aspect.
I
don't
know
if
our
interns
highlighted
that,
but
it
is,
we
have
a
also
would
like
to
kind
of
build
out
an
exporter
for
logging
for
c
plus
plus
right
now
for
elasticsearch
and
specifically
the
open
source
version
of
elasticsearch.
So
that's
also
one
of
our
goals
in
terms
of
having
an
you
know,
data
sync
and
and
again
was
wondering
if
that's
something
that
you
know
we're
starting
to
think
about
or
too
early.
D
A
Yeah,
I
think,
that's
that's
absolutely
highly
desirable.
Actually
right.
We
want
to
have
as
many
exporters
as
we
want.
So
that's
very
welcome.
If
you
want
to
contribute
something
like
that,
we
definitely
want
to
have
any
questions.
D
I
mean
we'll
we
will.
We
are
planning
to
you
know
as
we
implement
the
log.
The
mvp,
at
least
for
the
logs
you
know
on
is
support
in
c
plus
plus
at
least
to
test
it
out,
have
an
elasticsearch
exporter
with
developed
with
it,
which
our
interns
are
going
to
work
on.
So
again
that
could
be
easily
extended
for
the
collector.
Also,
that
is
another,
you
know,
version
of
it,
but
of
course,.
C
D
F
Yeah,
if
you
want
to
write
an
exporter
right
now,
you
can
there
already
are
exporters
in
the
collector
I
mean
the
only
thing
worth
noting
is
given
that
it's
not
stable,
there
could
be
breaking
changes,
there's
just
the
maintenance
of
it,
but
exporters
already
exist.
Definitely
desirable
shouldn't
need
to
wait.
You
can
definitely
get
started
now.
If
you
wanted
to.
D
Yeah
yeah,
I
mean
we
have
been
building
exporters
in
for
the
collector
for
metrics,
so
totally
understand.