edenfed

As far as I know Pixie use eBPF for generating metrics. Odigos is focused on generating distributed traces which is a different signal that spans across multiple applications

Yes exactly. Odigos plays nice with manual instrumentation, meaning distributed traces will include both automatic and manual spans. Currently there is no way to point manual instrumentation to the destination selected in Odigos but we working on it and should release it soon. Most SDKs have a concept of no-op exporter that way Odigos will be able to pick up the manually created traces and deliver them to the chosen backend

We are actually able to handle the long tail of tracing by leveraging the amazing open source community. For languages like Java we use the automatic instrumentation created by the OpenTelemetry community which is really great and support ton of libraries, you can see a list of supported libraries here: https://github.com/open-telemetry/opentelemetry-java-instrum... This also allows us to support async tracing like doing context propagation over Kafka message is also something we support (depending on the programming language)

Unfortunately not all web frameworks do this automatically. In addition sometimes you may want to propagate ID over non http connections like database drivers or even message queues.

Falco is really cool project but it focuses more on security. Odigos is focused on getting better monitoring signals from your applications, especially distributed tracing

As far as I know cilium does not do automatic context propagation and require code changes to achieve it. Odigos automatically do context propagation

Odigos will be able to instrument both containers each with the relevant instrumentation. As you pointed out, there is currently a bug in the UI that shows just one programming language per pod. Working on fixing it soon

Support for non-Kubernetes environments is something we are planning to release very soon.

Yes we are actually using a combination of env vars / process names / linked libraries and container metadata to detect the language

ECS is definitely on our roadmap!

This is something we are thinking about a lot. We developed multiple mechanisms to make sure we inject the IDs in a safe way. You can see the code here: https://github.com/keyval-dev/opentelemetry-go-instrumentati...

We are actually doing technical deep dive on the next meeting of the OpenTelemetry Go auto instrumentation meeting in Tuesday. Will be happy to share the presentation afterwards.

In addition, we automatically create spans for popular open source libraries in use so you should also expect to see spans for database connections / cloud SDKs/ Kafka clients / etc. Definitely agree that manual instrumentation is very important in addition to the automatic one

If you are thinking on adopting OpenTelemetry, you should check out Odigos: https://github.com/keyval-dev/odigos (I’m the author). This tools handles instrumentation for any application (even including Go) and also manages the collectors pipeline.

Because odigos uses different technologies for instrumentation, it actually depends on the programming language of your applications. Anyway, the performance overhead should be minimal.

I’m currently building a search engine made specifically for developers. We are searching directly in GitHub/StackOverfow/Reddit so SEO is not a problem. You are welcome to try it at https://keyval.dev

Hi HN, My name is Eden and I’m the CTO at keyval. We are building a search engine specifically made for technical questions asked by developers.

Advantages of using keyval: - Driven by your technology stack. We use OpenTelemetry and eBPF to map your existing stack and show you only results that are relevant to the tools and technologies that you are using. - No ads - No SEO - Only trusted sources such as StackOverflow, GitHub and Reddit.

We are just getting started. In the next few days we will also add search directly from command line by piping command output (think `make compile | kv` - for search without having to manually remove your class name from the search query) and searching in Slack and Discord workspaces of popular open source projects.

We worked really hard on this and can’t wait to hear your thoughts.

Hi HN, I am the creator of this project. Will be happy to answer any question you might have.

If you are using Kubernetes, please check out my post on patching log4shell using ephemeral containers in one command: https://medium.com/@edeNFed/patching-log4shell-in-one-comman...

Also recommended by Lunasec's mitigation guide: https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-g...

Hi, Using go pprof requires changing your code (importing net/http/pprof). kubectl-flame aims to profile without requiring code changes, so the current go implementation will be based on eBPF. Glad you liked the tool :)