auxmoney / opentracingbundle-core Goto Github PK

This event listener is bound to the 'kernel.response' event, but the event listener that starts the corresponding span is bound to the 'kernel.controller' event.

In some cases, the response is sent before the controller is reached (when an exception is thrown between the request event and the controller event), making the finish span failing with the message Auxmoney\OpentracingBundle\Service\TracingService: could not finish active span, missing active scope.

Why not add $this->tracing->setTagOfActiveSpan(ERROR, true); in the following locations:

• here if status code >= 500
  

  OpentracingBundle-core/Internal/Decorator/RequestSpanningService.php

  Lines 31 to 34 in a3ab2e3

  	public function finish(int $responseStatusCode): void
  	{
  	$this->tracing->setTagOfActiveSpan(HTTP_STATUS_CODE, $responseStatusCode);
  	}

• here
  

  OpentracingBundle-core/EventListener/ExceptionLogSubscriber.php

  Lines 37 to 49 in 3d68ac4

  	public function onException($event): void
  	{
  	$exception = $this->extractExceptionFrom($event);
  	$this->tracing->logInActiveSpan(
  	[
  	'event' => 'error',
  	'error.kind' => 'Exception',
  	'error.object' => get_class($exception),
  	'message' => $exception->getMessage(),
  	'stack' => $exception->getTraceAsString(),
  	]
  	);
  	}

• here if status code >= 500
  

  OpentracingBundle-core/EventListener/FinishControllerSpanSubscriber.php

  Lines 40 to 49 in a3ab2e3

  	public function onResponse($event): void
  	{
  	$attributes = $event->getRequest()->attributes;
  	// This check ensures there was a span started on a corresponding kernel.controller event for this request
  	if ($attributes->has('_auxmoney_controller')) {
  	$this->tracing->setTagOfActiveSpan(HTTP_STATUS_CODE, $this->getHttpStatusCode($event) ?? 'not determined');
  	$this->tracing->finishActiveSpan();
  	}
  	}

• here if exit code != 0
  

  OpentracingBundle-core/EventListener/FinishCommandSpanSubscriber.php

  Lines 33 to 38 in a3ab2e3

  	public function onTerminate(ConsoleTerminateEvent $event): void
  	{
  	$this->tracing->setTagOfActiveSpan('command.exit-code', $event->getExitCode());
  	$this->tracing->finishActiveSpan();
  	$this->persistence->flush();
  	}

• here if status code >= 500
  

  OpentracingBundle-core/EventListener/FinishRootSpanSubscriber.php

  Lines 33 to 41 in a3ab2e3

  	public function onFinishRequest(KernelEvent $event): void
  	{
  	if (!$event->isMasterRequest()) {
  	return;
  	}
  	$this->tracing->finishActiveSpan();
  	$this->persistence->flush();
  	}

Despite having no consensus on a specification for sampling in general, most tracers are actually providing two basic tracer types:

• constant samplers (always tracing, never tracing)
• probabilistic samplers

Right now, we are enabling the constant samplers (always tracing) by default for tracing implementations. However, as high-traffic projects are going to use this bundle, there will be the need of choosing other strategies (probably at configure-time, maybe even at runtime).

In order to provide this feature to bundle users, we should research how current tracer implementations are handling and passing these configurations and maybe come up with an abstraction.

• ensure all auxmoney libraries support opentracing-php v1.0.0
• upgrade to opentracing-php v1.0.0
• disband unmaintained PHP versions
• provide complete tutorial (#8)
• do not run release workflow for release commits, see https://github.com/auxmoney/grafana-waterfall-panel/blob/respect-ci-skip/.github/workflows/release.yml#L9-L25 for an example
• update README reflecting all changes (correct CI badges, remove some quality badges, link to tutorial, ...)
• setup a weekly run for tests

use "if"

In November 2022, PHP 7.4 will reach EOL. We should then drop the support and should refactor to PHP 8-only features, like:

• union types
• attributes (for replacing annotations only viable since Symfony 5.2)
• constructor property promotion
• static return type
• mixed type
• nullsafe operator
• named arguments
• match expression

We can utilize rector to get a good headstart.

Hi everyone! I found your libs by searching for a Jeager solution for PHP. Great work! I am testing right now OpentracingBundle-Jaeger for our Symfony Microservices and I am wondering if I have some misunderstandings about the distributed tracing.

I posted also the issue in Stackoverflow: https://stackoverflow.com/questions/77652397/distributed-tracing-with-jaeger-between-symfony-php-microservices

But also here in short. In Jeager I don't see the nested calls (the stacktrace of all the calls) but see only the main call and thats it. The same also for Commands, when I run some command, then I see only one span and not the class/method calls inside the command.

Do I miss some setting for enabling this? Thanks!

In order to fine tune the meta information provided with tags in the root spans, we should create the possibility to configure these tags easily.

Besides, we should consider an architecture to easily add new tags with dedicated classes and plug them into the configuration automatically.

Root span names have a high cardinality, because they use the plain request URI:

The names should be more generic according to the docs of OpenTelemetry (which is the successor of OpenTracing):

The span name SHOULD be the most general string that identifies a (statistically) interesting class of Spans, rather than individual Span instances while still being human-readable. That is, “get_user” is a reasonable name, while “get_user/314159”, where “314159” is a user ID, is not a good name due to its high cardinality. Generality SHOULD be prioritized over human-readability. — https://opentelemetry.io/docs/reference/specification/trace/api/#span

and:

Many REST APIs encode parameters into URI path, e.g. /api/users/123 where 123 is a user id, which creates high cardinality value space not suitable for span names. In case of HTTP servers, these endpoints are often mapped by the server frameworks to more concise HTTP routes, e.g. /api/users/{user_id}, which are recommended as the low cardinality span names. — https://opentelemetry.io/docs/reference/specification/trace/semantic_conventions/http/#name

I think using the plain URL also might put necessary stress to the Tracing systems.

As an alternative we could replace the URL we with the route name as soon as it is available in the KernelEvents::CONTROLLER event ($event->getRequest()->attributes->get('_route').

Thank you!

With PSR-18, an abstraction for HTTP clients was introduced in October 2018 and is widely accepted.

In order to reduce manual implementation overhead by each bundle user, we can automatically inject the tracing headers to all requests handled by these clients by decorating PSR-18 clients properly.

Ensure all auxmoney libraries support at least opentracing-php v1.0.0.

This is currently blocked by jukylin/jaeger-php#95 .

update documentation to reflect:

• the automatic header propagation for PSR-18
• the limitations of UDP transports (jaeger)
• the new Doctrine-DBAL plugin
• new configuration related to sampling

Hi

First off just a thnk you for this great looking set of bundles - just what I was looking for.

I'm trying to install the following bundles

auxmoney/opentracing-bundle-jaeger
auxmoney/OpentracingBundle-Monolog
auxmoney/OpentracingBundle-Guzzle

but there are version mismatches between them as reported by composer

• Root composer.json requires auxmoney/opentracing-bundle-monolog ^0.4.5 -> satisfiable by auxmoney/opentracing-bundle-monolog[v0.4.5].
  • auxmoney/opentracing-bundle-monolog v0.4.5 requires auxmoney/opentracing-bundle-core ^0.7 -> found auxmoney/opentracing-bundle-core[v0.7.0, ..., v0.7.7] but the package is fixed to v0.8.1 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.

Basically it looks like monolog and guzzle plugins need 0.7 and jaeger needs 0.8. Is there a way to install this, or do the older packages need an update to be compatible?

Thanks

Steve

In order to reduce manual implementation overhead of bundle users, we should generate spans around SQL queries in Doctrine automatically.

I sometimes see errors when the FinishRootSpan event fires here

Could we wrap the call in try catch ? I would prefer drop the span rather than returning a 500 to the caller.

Currently it is not possible to install that bundle with doctrine/dbal 3. Can you add support for that?

- auxmoney/opentracing-bundle-doctrine-dbal v1.2.3 requires doctrine/dbal ^2.11 -> found doctrine/dbal[2.11.0, ..., 2.13.9] but the package is fixed to 3.6.2 (lock file version) by a partial update and that version does not match.

We should add a amqplib/rabbitmq-bundle plugin for opentracing and update our core documentation accordingly.

Relates to auxmoney/OpentracingBundle-amqplib-RabbitMq#2

When using an existing docker network with a Jaeger service named jaeger, calling any script causes the PHP process to segfault:

$ bin/console
Segmentation fault (core dumped)
$

Further investigation showed, that dns_get_record() does not handle this situation well, but gethostbyname() does. Therefore, we should switch the implementation.

We are currently using composer/package-versions-deprecated to enrich traces with the versions of our packages. According to the package maintainer, this can (and should) be replaced with built in tools of composer 2. We should evaluate this and possibly get rid of this dependency in favor of a dependency on composer 2.

In order to show the complete functionality, we should create a tutorial (as wiki page?) on how to set up an example application.

We should include setting up a tracer instance, symfony application and instrumentation. It should also include some fancy screenshots.

I have added Symfony Messenger support for my use case which was not available by making a separate bundle like this.

Is it okay to create an addon like this from your OpenTracing bundle core?

Here is the link https://github.com/ujwaldhakal/symfony-opentracing-messenger. Let me know what you think

HI

I need to put the span context into a queuing system and then continue the span when the message comes off the queue.

I can get the span context fine using tracing->injectTracingHeadersIntoCarrier()

But I've searched around and can't find how to do the extract part so that Tracing knows I want to continue using this span context. Any pointers on how to do that?

Many thanks

Steve

The opentracing specification describes baggage item support for span contexts.

In order to provide this feature to bundle users, we need to extend the Tracing interface accordingly.

I have a use case when my Symfony command are some kinds of worker.
In this context, I want to avoid waiting for my command to finish and only trace the part I want to.
WDYT?

Currently, span types are distinguished only implicitely by operation name and presence or absence of specific tags.

In order to evaluateand filter traces more efficiently, we would like to distinguish between different types of spans explicitely (e.g. with a "opentracing bundle type" tag). This feature should also be implemented across all plugins.

update README reflecting all changes

• correct CI badges (correct links to platforms)
• remove some quality badges (esp. software quality)
• link to tutorial (compare #8 )
• remove obsolete plugins (emagtech)

As we entered a new Symfony support cycle, we should disband Symfony 3.4 support and enable Symfony 5.4/6.0 support.

Do you have an idea of what should be done to support esi requests ?
Currently they are tracked as separate traces, not related to the parent trace.
Thanks

Can only be tackled after #54 and #55 are resolved.