Jaeger agent does not fit serverless FAAS (AWS lambda etc)

[sloev]

The pattern of using Jaeger Agents runnning on the same host does not fit (our) usecase of running (python) functions as FAAS in AWS Lambda.
The requirement of running a seperate process is a showstopper.
Is it possible to have the agent running in another host? or in some work-around this issue in some way?

Btw. looking forward to OsCon workshop!!! :-)

[yurishkuro]

That's an interesting use case. The agent was designed to run as a side-car, which is a fairly common way of running infra components to avoid pulling the complexity into client libraries (and having to support that complexity in multiple languages).

Could you elaborate on your architecture? For example:

• do the Python functions make RPC calls to other microservices? If so, how do you solve the discovery / routing problem?
• how do you do other monitoring, e.g. metrics? I assume AWS Lambda provide some metrics for you, but what if you wanted to use an off the shelf metrics solution like statsd or prometheus? They typically also require a side-car agent.

[sloev]

The micrpservices call eachother by a defined internal endpoint specific to the microservice (thru Apigee or AWS ApiGateway) or they call functions (AWS Lambda) directly through their scalable invocation endpoint. About stats; we pull them from AWS or use NewRelic to expose some basics from within the service. My point is: FunctionAsAService is winning teritory and i can say i'm a fan of the simplicity (development and deployment wise) however the paradigm is to only give a function and you will only be billed for the execution time of said function. So fast setup/teardown is key. I am a follower of jaeger and think it is the best opentracing implementation yet but not being able to go serverless is a killer 😊

…

On Sat, May 6, 2017, 20:31 Yuri Shkuro ***@***.***> wrote: That's an interesting use case. The agent was designed to run as a side-car, which is a fairly common way of running infra components to avoid pulling the complexity into client libraries (and having to support that complexity in multiple languages). Could you elaborate on your architecture? For example: - do the Python functions make RPC calls to other microservices? If so, how do you solve the discovery / routing problem? - how do you do other monitoring, e.g. metrics? I assume AWS Lambda provide *some* metrics for you, but what if you wanted to use an off the shelf metrics solution like statsd or prometheus? They typically also require a side-car agent. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/uber/jaeger/issues/146#issuecomment-299657894>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA1TUVVJxfw5qsGc5jlmGOWEWVe5-rDCks5r3Lx1gaJpZM4NS167> .

[vprithvi]

@sloev jaeger-collector now supports receiving spans over HTTP in both jaeger.thrift and zipkin.thrift formats, making the agent optional.

While jaeger's go and java client already support using the HTTP endpoint, jaeger's python client still lacks support. We welcome PRs and would love to help you add support to the python client.

[yurishkuro]

There is an issue in the Python client repo for sending spans over HTTP (jaegertracing/jaeger-client-python#98). I don't think we need anything else on the backend.