# Using datadog tracer with Nameko
**URL:** https://discourse.nameko.io/t/using-datadog-tracer-with-nameko/243
**Category:** googlegroup
**Created:** [March 5, 2018, 8:46pm UTC](https://discourse.nameko.io/t/using-datadog-tracer-with-nameko/243 "2018-03-05T20:46:11Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@Moussa\_Idardar](https://discourse.nameko.io/u/Moussa_Idardar)
#### Post date: [March 5, 2018, 8:46pm UTC](https://discourse.nameko.io/t/using-datadog-tracer-with-nameko/243/1 "2018-03-05T20:46:11Z")
Hello all,
I would like to use datadog tracer with Nameko, and I couldn't find the way
to do it especially the code responsible for running the entrypoints (
worker\_setup and worker\_result doesn't do that )
have someone done this before/or does someone know how to do?
---
### Author:  [@Jakub\_Borys](https://discourse.nameko.io/u/Jakub_Borys)
#### Post date: [March 5, 2018, 9:04pm UTC](https://discourse.nameko.io/t/using-datadog-tracer-with-nameko/243/2 "2018-03-05T21:04:44Z")
Hi,
I think you're looking to use DataDoog's python custom tracer as described
here [http://pypi.datadoghq.com/trace/docs/#custom](http://pypi.datadoghq.com/trace/docs/#custom)
If so, you can take inspiration from nameko-tracer and create similar
dependnecy that instead of writing to a logger would call tracer.trace
etc: [https://github.com/Overseas-Student-Living/nameko-tracer/blob/master/nameko\_tracer/dependency.py](https://github.com/Overseas-Student-Living/nameko-tracer/blob/master/nameko_tracer/dependency.py)
> **···**
>
> On Monday, March 5, 2018 at 8:46:11 PM UTC, jackal wrote:
>
> > Hello all,
> >
> > I would like to use datadog tracer with Nameko, and I couldn't find the
> > way to do it especially the code responsible for running the entrypoints (
> > worker\_setup and worker\_result doesn't do that )
> >
> > have someone done this before/or does someone know how to do?
---
### Author:  [@Ondrej\_Kohout](https://discourse.nameko.io/u/Ondrej_Kohout)
#### Post date: [March 13, 2018, 6:41pm UTC](https://discourse.nameko.io/t/using-datadog-tracer-with-nameko/243/3 "2018-03-13T18:41:10Z")
Hi, we also use DataDog here at Student.com, but we don't have yet DD
integrated with Nameko for collecting application metrics. We trace our
entrypoint using Nameko Tracer
\<[https://github.com/Overseas-Student-Living/nameko-tracer>](https://github.com/Overseas-Student-Living/nameko-tracer>); and transport
and inspect them in ELK setup. We are also thinking of sending traces to DD
in addition to existing ELK solution.
I had a quick look on the Python DD tracer and it looks like there are
number of ways how to integrate it with Nameko services or to Nameko itself.
For causal tracing I would try the wrap decorator and wrap service
entrypoints directly, I suppose it would trace them on entry and on exit:
class Service:
@tracer.wrap()
@rpc
def say\_hello(self):
pass
Another approach would be to go a bit deeper to Nameko framework and to
write a dependency provider which inspects each worker before and after
entrypoint execution and use ddtrace API to send traces to dd agent. Same
inspection is already done by Nameko Tracer
\<[https://github.com/Overseas-Student-Living/nameko-tracer/blob/master/nameko\_tracer/dependency.py>](https://github.com/Overseas-Student-Living/nameko-tracer/blob/master/nameko_tracer/dependency.py>);
as Jakub pointed out in his reply. One of the features of Nameko Tracer is
that it separates the metrics collection from structuring, formatting and
transporting it to desired destination by using standard Python logging
mechanisms - loggers, handlers, formatters and filters. So the whole thing
is quite modular and can be configured by users the standard way. I would
prefer extending Nameko Tracer with a new ddtrace
\<[https://github.com/DataDog/dd-trace-py>](https://github.com/DataDog/dd-trace-py>); loggin handler as it will make the
solutions nicely pluggable and users would have the ability to configure
their tracing by logging configuration they understand. So there is an
option to extend Nameko Tracer to include logging handler for communication
with DD agents using the ddtrace API or the other option would be to write
similar dependency provider from scratch. Various tracers have various
APIs, various ways of structuring their metrics and number of different
ways of transporting them to their destination.Not talking about the
visualisation part .) There is the Opentracing \<[http://opentracing.io/>](http://opentracing.io/>);
project which tries to solve this problem and which implementation would
also be a nice contribution to Nameko tracer.
With datadog extension of Nameko Tracer enabling DD tracing for all
entrypoints of a Nameko service may be just a config change:
# config.yaml
LOGGING:
version: 1
formatters:
tracer:
(): nameko\_tracer.formatters.DataDogFormatter
handlers:
tracer:
class: nameko\_tracer.handlers.DataDogHandler
formatter: tracer
loggers:
nameko\_tracer:
level: INFO
handlers: [tracer]
There is yet another way how to collect Nameko entrypoint metrics for DD
agents which may be a bit controversial but which looks like the preferred
way of adopting DD tracing by various framework users. DDtrace has monkey
patches for many existing libraries and frameworks. These patch existing
libraries to be able to set tracers at any point of the lib's work
execution. That way framework users only import and run patching function
and all the magic is done behind the scene.
from ddtrace import patch\_all
patch\_all()
It is handy for users, but it's monkey patching with all its risks and
unpleasant surprises. As it does not use libs API, but rather lib
internals, it is much harder to maintain and requires deep understanding of
the patched lib. On the other hand, some of the most popular python
libraries are also based on monkey patching and on magics done behind the
scene (pytest, eventlet, gevent, ...).
I think that all of the three approaches are valid. We already had a chat
about writing the DD extensions to Nameko Tracer
\<[https://github.com/Overseas-Student-Living/nameko-tracer>\](https://github.com/Overseas-Student-Living/nameko-tracer>%5C). The monkey
patching probably should be a PR to ddtrace/contrib
\<[https://github.com/DataDog/dd-trace-py/tree/master/ddtrace/contrib>](https://github.com/DataDog/dd-trace-py/tree/master/ddtrace/contrib>); .
Ondrej
> **···**
>
> On Monday, 5 March 2018 20:46:11 UTC, jackal wrote:
>
> > Hello all,
> >
> > I would like to use datadog tracer with Nameko, and I couldn't find the
> > way to do it especially the code responsible for running the entrypoints (
> > worker\_setup and worker\_result doesn't do that )
> >
> > have someone done this before/or does someone know how to do?
---
### Author:  [@Jukowitz](https://discourse.nameko.io/u/Jukowitz)
#### Post date: [April 3, 2018, 7:19pm UTC](https://discourse.nameko.io/t/using-datadog-tracer-with-nameko/243/4 "2018-04-03T19:19:18Z")
It's not Datadog, but the people at Scout reached out to me, and they
raised an enhancement request for their Python APM.
>
>
> Instrument \[Nameko\](https://github.com/nameko/nameko), a Python framework for bu…ilding microservices.
Could do with more upvotes 🙂
> **···**
>
> On Monday, March 5, 2018 at 12:46:11 PM UTC-8, jackal wrote:
>
> > Hello all,
> >
> > I would like to use datadog tracer with Nameko, and I couldn't find the
> > way to do it especially the code responsible for running the entrypoints (
> > worker\_setup and worker\_result doesn't do that )
> >
> > have someone done this before/or does someone know how to do?
---
### Author:  [@Raymond\_A\_Botha](https://discourse.nameko.io/u/Raymond_A_Botha)
#### Post date: [March 9, 2018, 12:26pm UTC](https://discourse.nameko.io/t/using-datadog-tracer-with-nameko/243/5 "2018-03-09T12:26:08Z")
I'm also quite interested in this, if this can be done open source I'd like
to contribute, else I'll be creating this dependency.
> **···**
>
> On Monday, March 5, 2018 at 11:04:44 PM UTC+2, Jakub Borys wrote:
>
> > Hi,
> >
> > I think you're looking to use DataDoog's python custom tracer as described
> > here [http://pypi.datadoghq.com/trace/docs/#custom](http://pypi.datadoghq.com/trace/docs/#custom)
> >
> > If so, you can take inspiration from nameko-tracer and create similar
> > dependnecy that instead of writing to a logger would call tracer.trace etc:
> > [https://github.com/Overseas-Student-Living/nameko-tracer/blob/master/nameko\_tracer/dependency.py](https://github.com/Overseas-Student-Living/nameko-tracer/blob/master/nameko_tracer/dependency.py)
> >
> > On Monday, March 5, 2018 at 8:46:11 PM UTC, jackal wrote:
> >
> > > Hello all,
> > >
> > > I would like to use datadog tracer with Nameko, and I couldn't find the
> > > way to do it especially the code responsible for running the entrypoints (
> > > worker\_setup and worker\_result doesn't do that )
> > >
> > > have someone done this before/or does someone know how to do?
---
### Author:  [@geoffjukes](https://discourse.nameko.io/u/geoffjukes)
#### Post date: [August 21, 2019, 3:30am UTC](https://discourse.nameko.io/t/using-datadog-tracer-with-nameko/243/6 "2019-08-21T03:30:43Z")
ScoutApp has released support for HTTP endpoints:
>
The Documentation hasn’t been merged yet, but it looks pretty straightforward. I’ll be setting this up now!