opentelemetry-lambda VS VictoriaMetrics

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/...

OpenTelemetry AWS Lambda repository

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.

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?

opentelemetry-lambda

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.

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!

VictoriaMetrics provides a rich set of public playgrounds that allow you to explore the full observability stack - metrics, logs, traces - and even query migration tools without installing or configuring anything locally. These playgrounds are backed by real VictoriaMetrics components and real data, making them ideal for:

VictoriaMetrics: High-performance, cost-efficient TSDB with focus on large-scale deployments and long-term storage.

Wait, I see it's been removed actually [1]. Why, isn't it faster anymore?

[1] https://github.com/VictoriaMetrics/VictoriaMetrics/commit/c2...

Official Website: VictoriaMetrics

Thanks! If you'll hit any issues with the integration, then please file them at https://github.com/VictoriaMetrics/VictoriaMetrics/issues , so we could quickly resolve them.

Time Series: Greptime, Influx, Loki, Mimir, Prometheus, Tempo, Victoria Metrics

Yup, there is a big room for improvements there! BTW, VictoriaLogs docs are open source too [1], so we'll be more than happy receiving pull requests with improvements for the docs!

[1] https://github.com/VictoriaMetrics/VictoriaMetrics/tree/mast...