oteps
opentelemetry-lambda
Our great sponsors
oteps | opentelemetry-lambda | |
---|---|---|
4 | 8 | |
316 | 243 | |
1.9% | 4.5% | |
5.3 | 9.3 | |
9 days ago | 3 days ago | |
Makefile | Go | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
oteps
-
OpenTelemetry in 2023
Oh nice, thank you (and also solumos) for the links! It looks like oteps/pull/171 (merged June 2023) expanded and superseded the opentelemetry-proto/pull/346 PR (closed Jul 2022) [0]. The former resulted in merging OpenTelemetry Enhancement Proposal 156 [1], with some interesting results especially for 'Phase 2' where they implemented columnar storage end-to-end (see the Validation section [2]):
* For univariate time series, OTel Arrow is 2 to 2.5 better in terms of bandwidth reduction ... and the end-to-end speed is 3.1 to 11.2 times faster
* For multivariate time series, OTel Arrow is 3 to 7 times better in terms of bandwidth reduction ... Phase 2 has [not yet] been .. estimated but similar results are expected.
* For logs, OTel Arrow is 1.6 to 2 times better in terms of bandwidth reduction ... and the end-to-end speed is 2.3 to 4.86 times faster
* For traces, OTel Arrow is 1.7 to 2.8 times better in terms of bandwidth reduction ... and the end-to-end speed is 3.37 to 6.16 times faster
[0]: https://github.com/open-telemetry/opentelemetry-proto/pull/3...
[1]: https://github.com/open-telemetry/oteps/blob/main/text/0156-...
[2]: https://github.com/open-telemetry/oteps/blob/main/text/0156-...
-
Grafana Phlare, open source database for continuous profiling at scale
https://github.com/open-telemetry/oteps/issues/139
It takes a lot of time and effort to bake a cross-vendor cross-language standard.
-
Faster Protocol Buffers
This. The statelessness of the OTLP is by design. I did consider stateful designs with e.g. shared state dictionary compression but eventually chose not to, so that the intermediaries can remain stateless.
An extension to OTLP that uses shared state (and columnar encoding) to achieve more compact representation and is suitable for the last network leg in the data delivery path has been proposed and may become a reality in the future: https://github.com/open-telemetry/oteps/pull/171
opentelemetry-lambda
-
Did OpenTelemetry deliver on its promise in 2023?
I mean, sure, you can improve performance a bit by increasing the RAM/compute capacity on the Lambda. But it always adds a pretty steep overhead right now, no matter how much capacity you throw at it.
https://github.com/open-telemetry/opentelemetry-lambda/issue...
https://github.com/aws-observability/aws-otel-lambda/issues/...
-
Instrumenting AWS Lambda functions with OpenTelemetry SDKs
OpenTelemetry AWS Lambda repository
- OpenTelemetry in 2023
-
Serverless Spy Vs. Spy Chapter 3: X-Ray vs Jaeger - Send Lambda traces with open telemetry
With the sample apps from the opentelemetry-lambda repository the Lambda part itself was easy to implement. What took me some time was to provide the jaeger Fargate service with IaC ouside of an k8s environment. But with ECS and ServiceDiscovery that was easy in the end. This should be even more simple in an EKS environment with the jaegertracing helm-charts.
-
AWS Lambda tracing with OpenTelemetry and OpenSearch
OpenTelemetry recently released https://github.com/open-telemetry/opentelemetry-lambda, but they also have this in the official docs https://opentelemetry.io/docs/instrumentation/js/serverless/. What do you consider to be the better option?
-
Serverless Spy Vs. Spy Chapter 2: AWS Distro for OpenTelemetry Lambda vs X-Ray SDK
opentelemetry-lambda
-
How to Instrument AWS Services with OpenTelemetry
You don’t have to create an opentelemetry configuration file such as this for each of your lambdas. In fact, you shouldn’t. In AWS, you can use Lambda Layers. You can define the OpenTelemetry tracing piece of code as a Lambda layer and use it in any Lambda you want. Furthermore, OpenTelemetry went ahead and implemented this opentelemetry-lambda layer for us. All we need to do is use it with our config.
-
Struggling to connect the dots - ADOT with Lambda using aws-otel-nodejs Lambda layer, not sure how to go from here to using custom instrumentation (e.g. instrumentation-pg, instrumentation-graphql, etc).
Sorry you're having trouble working with the ADOT Lambda Layers :(. Have you had a chance to open an issue on the GitHub repo for OTel Lambda or ADOT Lambda? You should add your expected vs your actual output!
What are some alternatives?
zipkin-api - Zipkin's language independent model and HTTP Api Definitions
terraform-aws-lambda - Terraform module, which takes care of a lot of AWS Lambda/serverless tasks (build dependencies, packages, updates, deployments) in countless combinations 🇺🇦
b3-propagation - Repository that describes and sometimes implements B3 propagation
deploy-aws-lambda-to-vpc-with-terraform - Terraform module with all the cloud resources needed to run Lambda within a VPC
odigos - Distributed tracing without code changes. 🚀 Instantly monitor any application using OpenTelemetry and eBPF
sqs-consumer - Build Amazon Simple Queue Service (SQS) based applications without the boilerplate
exp-lazyproto - Experimental fast implementation of Protobufs in Go
opentelemetry-examples
community - OpenTelemetry community content
aws-otel-js - AWS Distro for OpenTelemetry JavaScript SDK
terraform-aws-jaeger - Terraform module for Jeager
helm-charts - Helm Charts for Jaeger backend