►
From YouTube: 2022-08-03 meeting
Description
OpenTelemetry PHP SIG Meeting
C
B
B
B
E
B
B
F
Yes
bomb
so
now
this
span
processors
are
incorrect
to
incorrect
calls
to
span
exporter
for
splash.
This
is
also
dependent.
Basically,
these
both
are
related,
the
one
which
tobias
is
doing
so
I
made
the
changes
in
bat
span
processor,
and
I
think
tobias
also
is
making
those
changes
in
his
pr.
So
I'm
waiting
for
the
discussion
to
happen
and
for
simple
span
processor.
I
have
already
made
the
changes
so
yeah
we
will
go
through
the
discussion
and
whatever
changes
will
be
needed.
If
any,
I
will
need
that.
B
C
B
A
So
I
have
made
some
changes,
but
still
there's
one
thing
left.
I
had
raised
a
question
regarding
the
testing
issue
with
singleton
said.
So
probably
we
are
going
to
still
face
that,
but
yeah
yeah,
I
think,
tobias,
has
added
the
last
comment.
I
haven't
got
a
chance
to
review
that
so
I'll
have
a
discussion
with
that
discussion
with
him
on
that
as
well.
B
B
All
right,
so
I
think
those
are
all
those
are
all
the
open,
telemetry
php
issues
that
we
have
in
trib
repo.
We
have,
I
think
we
just
have
the
sdk
bundled
profiler
by
j
thomas.
It
looks
like
they
are
they're
working
on
it,
but
it
looks.
It
also
looks
like
a
draft,
so
maybe
we'll
have
to
wait
for
a
little
bit
longer
with
that
one.
B
There's
two
other
implementations
in
there,
the
instrumentation
direct
the
directory
directory
structure
by
corolla,
and
it
looks
like
tmo
and
title-
did
a
good
job
of
teaming
up
on
reviews
for
that,
so
which
I
think
we're
just
waiting
on
curl
up
that
to
finish
for
her.
Oh,
she
might
sparked
us
ready
for
review
so
I'll
make
sure
to
review
that
today.
B
C
B
C
B
B
B
B
A
Okay,
the
link
is
already
in
the
group
link
is
all
I
have
pasted
the
link
in
the
moms
sick
doc
as
well
and
yeah.
Here
we
go
so
basically,
we
are
going
to
present
a
proposal
for
auto
instrumentation
in
hotel
php
and
as
of
now,
the
current
status
of
auto
instrumentation
instrumentation
is
that
we
don't
have
it
for
laravel.
We
have
a
manual
instrumentation.
We
have
a
doc
readme
doc
regarding
that
and
for
symphony.
A
A
So
first
thing
is
regarding
the
language
of
hotel
phps
ticket.
So
this
is,
I
believe
this
is
a
convention
in
the
open,
telemetry
space,
that
let's
say,
if
you
want
to
instrument
xyz
application,
then
we
have
a
hotel,
sdk
or
a
hotel
agent
in
the
same
language,
so
take,
for
instance,
python
or
java,
and
I
believe
same
is
followed
for
php
as
well,
but
using
php
as
a
language
for
hotel,
php
sdk.
A
I
have
seen
and
worked
on
the
extensions
that
whose
source
code
is
purely
in
cc
plus
and
that
allows
us
to
leverage
the
hooks
given
by
php
and
achieve
the
instrumentation
achieve
the
monitoring
that
we
need
that
we
are
targeting
with
this
open,
telemetry
seamlessly
so
yeah.
The
first
proposal
would
be
to
change
the
language
for
hotel
ph.
Basically,
but
it's
it's
just
it's
easier
said
than
done.
A
C
A
C
C
C
Yeah,
so
bob
brett
and
other
probably,
if
you
guys
have
any
context
whether
we
have
taken
the
conscious
decision
earlier
only
like
php
hotels
agents
should
be
on
the
php.
It
was
just
how
it
is
started
and
there
was
no
specific
reason
to
choose
that,
because
the
proposal
which
we
have
again
definitely
one
thing
is
talking
about.
C
Ideally,
we
should
have
written
or
even
if
there
is
opportunity
we
can
still
think
of
writings,
php
hotel
isn't
in
cc
plus
and
then,
if
that
is
not
at
all
possible,
our
community
has
some
other
opinions
against
that.
Then
we
will
be
discussing
about
the
alternative
approach
which
will
have
again
some
challenges
as
well.
So
before
we
move
there,
let's
pause
and
have
some
open
discussion
here.
C
B
Think
that
we
have,
I
think
that
auto
instrumentation
was
never.
As
of
this
point
was
never
intended
to
be
done
in
a
different
language,
because
we
hadn't
run
up,
we
hadn't
run
up
against
any
guardrails
with
not
using
php.
I
think
that
the
standard
practice
for
the
standard
practice
for
implementing
sig's
language
is
to
use
the
language
of
the
sig.
I
don't
know,
I
don't
know
how
the
other
maintainers
will
feel
about
us
using
multiple
languages
in
the
php
sig.
I
think
it
adds
a
lot
of
operational
complexity.
B
If
we
have
to
do
it,
then
we
have
to
do
it,
but
yeah
yeah.
It's
it's
it's
one
of
those
things
like.
I
don't
think
that
we
should
add
more
needless
complexity
to
a
project
that
already
has
that
already
is
a
year
and
a
half
behind
and
has
very
few
contributors.
I
think
adding
more
complexity
would
make
things
very
worse,
but
maybe
it's
something
that
we
need
to
do
to
to
gain
momentum
in
the
community.
I'm
not
really
sure.
C
Yeah,
no,
I
understand
definitely
again
being
from
observability
company
like
app
dynamics.
Definitely
we
had
some
of
these
experiences
and
based
on
that,
definitely
I
think
decision
was
made
while
python
java,
other
agents
has
followed
the
native
language
for
the
implementation,
but
in
php
agent
specifically,
we
have
used
the
c
plus
plus,
as
a
convention
organization
can
add
more
details.
D
So
I've
seen
I've
seen
you
know
things
like
this
done
before.
I'm
thinking
of
sort
of
data
dogs
or
elastics
tracing
asia,
where
there's
a
both
a
php
component
and
a
c
or
c
plus
plus
component,
I
think
for
for
for
users
wanting
to
instrument
their
own
code,
then
having
having
an
implementation
in
in
the
native
languages,
is
very
a
much
lower
barrier
to
entry
and
easier
to
use.
But
I
I
certainly
understand
why
having
a
c
component
that
can
hook
into
the
zend
engine
enables
a
lot
more
things.
E
C
E
D
Yeah,
it
did
almost
have
to
be
a
separate
implementation
of
open
telemetry.
I
I
can't
see
it's
going
going
back
and
and
rewriting
these
and
that's
exactly
right.
I
couldn't
contribute.
Most
of
you
know.
Most
of
the
current
contributors
wouldn't
know
it
yeah
it's
it's.
A
lot
of
rework
it'd
have
to
be
a
very,
very
compelling
argument.
C
Yeah
so
looks
like
mostly
the
point
which
you
guys
are
adding.
We
all
are
in
alignment,
but
let's
again,
let's
kiss
and
cover
some
of
those
slide,
which
is
again
in
the
similar
topic
which,
like
tobias,
was
talking
about
yeah
only
instrumentation
logic
we
can
have
in
cc
plus
plus,
but
so
far
we
haven't
got
the
full
success
or
maybe
some
more
poc
would
be
required.
But
let's
really
discuss
some
of
the
challenges
so
question
you
want
to
cover
the
alternative
approach.
A
Sure
so
yeah,
I
understand
that
having
the
entire
sdk
return
or
rewritten
in
cc
plus
for
hotel
php
might
be
a
tedious
task,
and,
like
you
mentioned
not,
everyone
might
be
familiar
with
the
cc,
plus
plus
as
a
language.
Those
who
are
working
in
php
might
not,
and
that
might
raise
the
entry
for
contribution,
given
that
the
community
is
has
very
less
contributors,
active
contributors
as
of
now
so
yeah.
A
The
only
issue
that
we
are
facing
is
with
the
auto
instrumentation
front
right,
so,
whatever
logic
that
we
have
for
instrumenting
it,
we
can
write
that
in
cc,
plus
plus
compile
its
code,
make
it
as
an
extension
of
php
and
then
hotel
php
can
use
that
extension
to
you
know,
leverage
the
php
hooks
that
we
can
get
this
way.
It
would
make
us
easier
to.
A
We
would
be
generating
a
simple
instrumentation
logic
that
is
written
in
cc,
plus
plus
we'll
compile
it
and
try
to
use
it
with
the
latest
hotel,
bhp,
sdk
and
see
if,
if
this
really
is
the
challenge
for
us
or
not
or
if
it
is,
what
could
be
the
potential
solutions
for
that
so
yeah
that
that
that
was
entire
us
present.
That
was
entire
proposal,
for
this
alternate
approach
that
we
just
write
the
instrumentation
logic
in
cc
plus
yeah
going
forward
this
this.
I
believe
we
already
started
the
discussion
on
that.
A
The
entire
point
of
this
proposal
was
to
personally,
I
believe
that
auto
instrumentation
is
the
aspect
that
I
believe
every
open,
telemetry
agent
or
sdk
should
follow,
because
we
don't
want
our
customers
or
consumers
to
ride
even
a
single
line
of
code
later
on
single
line
of
code.
They
have
to
make
minimal
changes
so
as
to
accommodate
any
of
the
open,
telemetry
sdks
in
in
their
application,
and
that's
where
I
believe
auto
instrumentation
is
the
crucial
aspect
for
that,
and
I
just
wanted
the
discussion
to
go
ahead.
A
I
believe
I
missed
out
the
adobe
tobias's
discussion
on
the
hotel
php
channel.
It
happened
two
months
back
and
I
I
I
think
if
we
had
started
some
discussion
around
that,
then
probably
we
might
be
targeting
auto
instrumentation
for
beta
as
well,
but
nevertheless
it's
never
late.
So
this
these
are.
The
topics
that
we
would
like
to
discuss
within
the
community.
First
is
choice
of
language
for
hotel,
php
sdk,
I
believe
apart,
even
though
cc
plus
provides
an
edge
to
us.
A
The
second
thing
is
this
one:
basically,
we
will
be
working
we'll
be
working
on
a
simple
instrument,
we'll
be
working
on
setting
up
simple
instrumentation
logic,
written
in
cc,
plus
plus,
and
try
to
use
it
with
the
hotel,
php
sdk
and
present.
What
are
the
challenges
that
we
faced
in
that?
What
potenti?
What
could
be
the
potential
issues
that
we
might
face,
and
the
third
thing
that
I
really
would
like
to
discuss
is
about
the
plans
for
instrumentation.
A
C
So
again,
I
think
we
have
already
kind
of
discussed.
You
suggested
right
called
recovery,
so
so
many
things,
probably
since
you
have
done
the
poc
sometime
back,
do
you
agree
with
the
challenge
which
kisan
has
mentioned
about
fetching
the
data
from
between
two
languages
c,
plus
plus
and
the
php?
Have
you
faced
a
similar
kind
of
thing
or
you
got
the
success
using
only
instrumentation
logic
in
c
plus
plus?
Yes,.
C
C
That
way
at
least
multiple
brands
are
working
and
coming
up
with
the
proper
solution
for
the
auto
instrumentation,
because
education,
maintenance
and
auto
instrumentation
is
definitely
one
of
the
basic
aspect
which
any
people
will
expect
from
the
php
hotel
agent,
and
that
is
something
even
though
it
is
not
for
the
beta.
It
should
be
there
immediately
after
the
beta.
E
D
A
C
Yeah
but
again
just
trying
to
bring
the
original
point
in
case
we
identify
this
hook.
Logic
using
c
plus
plus
is
not
scalable
or
it's
not
fully
working.
Do
we
still
have
the
option
open
to
think
about
rewriting
php
hotel
in
c
plus
plus
is
that
is
something
still
can
we
park
and
later
on?
We
can
explore
that.
What
do
you
guys
think
how
much
effort
would
be
needed
if
we
plan
to
do
some
of
those
things.
B
D
A
Okay,
yeah
sure,
so,
basically,
we
have
also
developed
a
monitoring
proprietary
monitoring,
extensions
that
monitors
php
application.
The
entire
source
code
is
written
in
cc
plus
and
we
compile
it
as
an
extension
of
php.
All
the
all
it
is
required
is
for
the
customer
to
install
that
extension
on
their
environment
and
by
when
I
say
installation
all
it
needs
is
in
the
php.ini
file.
Just
include
that
so
file,
the
extension,
that's
it
I'm
not.
A
A
The
original
function
would
still
be
called,
but
it's
just
that
before
and
after
the
original
function
is
called,
we
have
a
wrapper
class
or
you
know
a
wrapper
function
around
that,
basically,
which
is
equivalent
to
what
tobias
mentioned
as
pre
and
post
hooking,
and
in
those
things
we
do
everything
that
we
require
for
monitoring.
We.
Basically,
if
we
want
the
time
we
want
the
time
of
that
entire
request,
then
we
start
and
stop
the
timer
in
pre
and
post
hooking
logic.
A
Let's
say
if
there
is
an
extension,
mysql
extension
and
we
want
to
see
the
host
name
or
port
name
or
any
other
parameters
for
that
mysql
right.
There
are
the
interceptors
written,
which
would
basically
fetch
those
details
for
us,
and
we
have
something
called
as
business
transaction
that
is
equivalent
to
traces
in
open
telemetry.
A
We
put
all
those
details
into
the
business
transaction
and
yeah,
there's
a
back
end
to
which
we
send
it.
So
that's
that's
a
general
overview
of
how
that
php
agent
works.
The
reason
why
I
have
presented
this
is
because
it's
entirely
written
in
cc
plus
plus
and
I
have
experienced
the
edge
or
the
advantage
it
gives
us.
I
believe
I'm
not
saying
that
cc
plus
plus,
is
the
the
perfect
language
for
hotel
php.
A
But
what
I'm
saying
is
that
probably
like,
like
we
mentioned
right,
there
are
certain
challenges,
the
lack
of
contributors
or
anything,
anything
that
could
present.
You
know
a
challenge
if
we
are
shifting
the
entire
language
of
our
implementation,
but
all
I
wanted
to
present
is
that
yes,
cc,
plus
plus
also
has
an
instrumentation.
So
if
we
are
not
writing
the
entire
call
logic
in
that,
if
you
are
just
writing
the
instrumentation
logic
into
that
yeah,
then
it
could
basically
solve
our
quarter.
Instrumentation
issue.
C
Is
mentioned
in
the
chat
application?
You
can
read
out
that
question,
so
what
is
being
asked?
Can
we
have
the
comparison
of
php
implementation
versus
c
plus
plus
implementation
of
the
php
agent?
So
I
think
that
exercise
can
definitely
be
done.
But
after
we
exhaust
all
the
option
of
this
c
plus
plus
extension
or
only
hook
logic
in
the
c
plus
class,
and
if
we
find
there
is
no
way
forward,
then
we
can
have
those
discussion
actually.