DEV Community: didiViking

VictoriaMetrics playgrounds any dev should try in 2026

didiViking — Tue, 30 Dec 2025 09:39:58 +0000

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:

Learning VictoriaMetrics query languages
Trying dashboards and queries interactively
Validating migration paths
Demonstrating features in talks or workshops
Experimenting with AI-driven observability via MCP

In this post, we’ll walk through each available playground, explain what it does and link to the relevant GitHub repositories behind it.

VictoriaMetrics Playground (VMUI)

🔗 https://play.victoriametrics.com/

This is the primary playground for VictoriaMetrics metrics, powered by VMUI and backed by a VictoriaMetrics cluster installation. It is available for testing the query engine, relabeling debugger, other tools and pages provided by VMUI.

This playground is the best starting point for understanding how VictoriaMetrics stores and queries metrics at scale.

GitHub repository:
https://github.com/VictoriaMetrics/VictoriaMetrics

Grafana VictoriaMetrics Playground

🔗 https://play-grafana.victoriametrics.com/

This playground provides a hosted Grafana instance preconfigured with:

VictoriaMetrics as a metrics data source
VictoriaLogs as a logs data source

Here you can:

Explore real dashboards built on top of VictoriaMetrics
See how MetricsQL and LogsQL are used in Grafana panels
Learn dashboard design and visualization best practices

It’s particularly useful if you already use Grafana and want to see how VictoriaMetrics integrates into existing workflows.

Relevant repositories:

VictoriaMetrics Grafana datasource: https://github.com/VictoriaMetrics/victoriametrics-datasource

VictoriaLogs Grafana datasource: https://github.com/VictoriaMetrics/victorialogs-datasource

VictoriaLogs Playground (LogsQL)

🔗 https://play-vmlogs.victoriametrics.com/

This playground focuses on VictoriaLogs and it is available for testing the query engine on demo logs set.
The playground demonstrates how VictoriaLogs handles high-volume log data with predictable performance and low operational overhead.

GitHub repository:
https://github.com/VictoriaMetrics/VictoriaLogs

LogQL → LogsQL Playground (Migration Assistant)

🔗 https://play-logql.victoriametrics.com/

For teams migrating from Grafana Loki, this playground provides a LogQL to LogsQL, the VictoriaLogs query language, translation tool, which automatically converts Loki queries to VictoriaLogs queries.

This significantly reduces friction when adopting VictoriaLogs in environments already using Loki.

GitHub repository:
https://github.com/VictoriaMetrics-Community/logql-to-logsql

Documentation:
https://docs.victoriametrics.com/victorialogs/logql-to-logsql/

VictoriaTraces Playground

🔗 https://play-vtraces.victoriametrics.com/

This playground showcases VictoriaTraces, the VictoriaMetrics backend for distributed tracing and it is available for testing the query engine on demo traces set.

GitHub repository:
https://github.com/VictoriaMetrics/VictoriaTraces

VMAnomaly Playground (Anomaly Detection)

🔗 https://play-vmanomaly.victoriametrics.com/metrics/vmui/

The VMAnomaly playground demonstrates automatic anomaly detection on time-series data using VictoriaMetrics. It allows you to:

Explore metrics enriched with an anomaly_score
Visualize anomalies directly in VMUI
Understand how anomaly detection integrates with MetricsQL
Learn how anomaly scores can be used for alerting (for example with vmalert)

VMAnomaly continuously analyzes metric behavior and produces anomaly scores that behave like any other time series in VictoriaMetrics.

Distribution & setup:

VMAnomaly container: https://hub.docker.com/r/victoriametrics/vmanomaly

Helm charts (including anomaly setups): https://github.com/VictoriaMetrics/helm-charts

VictoriaLogs SQL to LogsQL playground

🔗 https://play-sql.victoriametrics.com/

This playground enables you to query data from VictoriaLogs instance or just translate SQL to LogsQL without querying.

GitHub repository:
https://github.com/VictoriaMetrics/sql-to-logsql

Bonus point: VictoriaMetrics MCP server

If you are a fan of using MCP servers then you should definitely try the official VictoriaMetrics MCP Server, which enables AI-driven interaction with observability data. This MCP server allows you to use almost all read-only APIs of VictoriaMetrics, basically all the functions available in VMUI:

Querying metrics and exploring data (even drawing graphs if your client supports it)
Listing and exporting available metrics, labels, labels values and entire series
Analyzing and testing your alerting and recording rules and alerts
Showing parameters of your VictoriaMetrics instance
Exploring cardinality of your data and metrics usage statistics
Analyzing, tracing, prettifying and explaining your queries
Debugging your relabeling rules, downsampling and retention policy configurations
Integration with VictoriaMetrics Cloud

This makes it possible for MCP-compatible tools (such as Cursor, Claude Desktop, or VS Code integrations) to query and reason about observability data conversationally.

GitHub repository:
https://github.com/VictoriaMetrics-Community/mcp-victoriametrics

Video how to use VictoriaMetrics MCP server: https://www.youtube.com/watch?v=1k7xgbRi1k0

Run Your Own Local Playgrounds

In addition to these hosted playgrounds, VictoriaMetrics provides Docker and Helm-based resources you can run locally and start playing with the ecosystem:
https://hub.docker.com/u/victoriametrics
https://github.com/VictoriaMetrics/helm-charts
https://docs.victoriametrics.com/victoriametrics/quick-start/

Let me know which one was your favorite playground or if you have any feedback for improvement, ping me a comment here or you can find me on LinkedIn or GitHub.

The Unofficial Guide to Contributing to OpenTelemetry — where to look and who to talk to!

didiViking — Wed, 17 Dec 2025 09:51:50 +0000

OpenTelemetry provides the tools and standards to collect metrics, logs, and traces from applications and services. Getting started with contributions can feel overwhelming, so here is something people rarely tell you.

What People Don't Tell You

Jumping into OpenTelemetry is not just about learning the code, it is about understanding the community and the workflows behind it. Most guides focus on good first issues or setting up your local environment, but here is what you will not hear as often.
Before checking out just OpenTelemetry look at the broader ecosystem. What other tools and observability projects are out there? Are they outdated or not? Can you start contributing there as well? How do they relate to OpenTelemetry? A little bit of research and history check never hurt anyone.

Most devs don't know about this website, CLOTributor, that helps you check out good first issues from a number of Cloud Native projects. I love it!

Tips for beginners!

Start small. Contributing does not mean implementing core protocols on day one. Documentation improvements, examples, test fixes, and localization are all meaningful contributions. The codebase moves fast. APIs evolve, modules get refactored, and Collector pipelines change. Do not get discouraged if something you learned last week behaves differently today.

Community context matters. A pull request is not just code, it is discussions, design decisions and feedback from maintainers. Reading issues and pull request threads is as educational as coding itself. Your experience is your superpower. Coming from Software Engineering or developer experience gives you a fresh perspective most contributors lack. You know what patterns are practical, what documentation is confusing and which examples actually help developers adopt OpenTelemetry.

Who to Talk To

When contributing to OpenTelemetry, engage with everyone in the community, but pay particular attention to maintainers, SIG members, senior contributors and approvers. These are the people who review pull requests, set priorities and guide the direction of projects. Observing their discussions, asking thoughtful questions and seeking feedback will accelerate your learning and help your contributions align with real community needs.

Where you find them?

Useful CNCF Slack OpenTelemetry channels for new contributors:
#otel-sig-end-user, #otel-devex, #opentelemetry-new-contributors, #otel-contributor-experience, #otel-docs-localization

1. Understand the Pieces

OpenTelemetry is more than a single library, it is a set of tools and standards. SDKs exist in multiple languages including Python, Java, and Go. The Collector gathers and forwards telemetry data, and instrumentation libraries connect your frameworks and protocols. Core protocols such as OTLP, gRPC, and HTTP define how telemetry moves across systems.

If you want to go for something new and shiny in 2025, I recommend you two newer projects that are worth keeping an eye on.
OTel Injector helps automatically instrument cloud-native applications, making it easier to collect telemetry without manually modifying code.

OTel Weaver simplifies configuring and managing telemetry pipelines, reducing friction for teams setting up observability stacks.
You don't know what new and hot? Not a problem, I recommend you check out: https://opentelemetry.io/blog/2025/

Contributing to these projects allows you to influence how developers adopt OpenTelemetry in real-world environments, which is particularly valuable for SREs and platform engineers who care about scalable and maintainable monitoring. We need your developer feedback!

Direct Interviews/Feedback Sessions: The End User SIG actively seeks users for interviews to improve the project. You can reach out to them on the #otel-sig-end-user Slack channel to schedule a session.

2. Official Documentation: A Good Starting Point

The official documentation is solid but can be overwhelming if you do not know where to start. The OpenTelemetry site has quickstart guides per language, Collector setup instructions and SDK and instrumentation references. The GitHub repositories for the Collector and the Python SDK, for example, contain READMEs, contributing guides and issues labeled good first issue, which provide context and entry points for new contributors.

3. Useful Unofficial Resources: the unconventional way

Blogs, tutorials, YouTube talks, and conference sessions (e.g. KubeCon past sessions on CNCF YouTube channel) demonstrate real setups, including projects like OTel Injector. Community discussions on CNCF Slack channels often provide practical tips missing from the documentation. Contributions do not have to be code-related.
Localization of documentation, writing guides, creating sample applications, and providing feedback on instrumentation user experience are all highly valuable.

4. Setting Up a Local Sandbox

Hands-on exploration is the fastest way to learn. Start by forking and cloning the repository.

git clone https://github.com/your-username/opentelemetry-python.git cd opentelemetry-python

Set up the development environment with pip install editable for Python or go build for Go. Run tests to verify your setup.

pytest

Experiment by adding a log, tweaking instrumentation or sending data to a local Grafana instance or your preferred observability frontend platform.

5. Learn by Reading and Modifying Code

Start with small tasks such as documentation or test fixes. Study recent pull requests to learn patterns and best practices. Explore test cases as they often illustrate intended behavior clearly. Open draft pull requests for minor improvements, even for localization or example tweaks.
Be curious. Ask questions. Keep yourself motivated and challenged.

6. Expanding Your Knowledge

CNCF learning resources and courses are helpful. The Linux Foundation OpenTelemetry Certification provides a structured way to validate your understanding and gain deeper insight into the ecosystem. Hands-on projects, such as building a Collector with a sample application and Grafana pipeline, consolidate learning. Curated GitHub tutorials or Medium guides help fill gaps.

7. Making Contributions Sustainable

Sustaining contributions is about picking a focus and staying engaged. Choose a module, library, or project to focus on. Projects like OTel Injector and Weaver are particularly exciting because they address automation and pipeline management, which are pain points for many teams.

Attend SIG meetings to understand ongoing development and decisions. Share what you learn through blogs, demos, or internal talks, and review others' pull requests or mentor newcomers. Contributions that improve usability, documentation, localization, or developer experience have a long-lasting impact even if they are not code-heavy. Community is key.

Why you should listen to me?

In 2024, I was just like you. Novice, no prior Open Source or Cloud Native contribution. Then I got curious about OpenTelemetry. I joined the community and started adding my first contributions to the OpenTelemetry (OTCA) exam certification. Over the next 7–8 months, I have contributed and revised many exam questions, read official and unofficial documentation, paid attention to what my peers suggested. I showed up and I got myself motivated. With its general public release in January 2025, I became OTCA Exam developer.

Then I POC-ed OpenTelemetry at my company. It failed to reach production. But I did collaborated with developers, we instrumented code together, we made our tests, we saw the OTel potential. We provided our developer feedback to the community.

In January 2025, I contributed with my first commit and PR to the OpenTelemetry repository. Then soon followed other PRs and localization contributions. In August 2025, I created a new localization SIG for Romanian. I asked new contributors to join and mentored them.

In November 2025, at KubeCon Atlanta, the community supported us just like we supported the community all this time. Along with some of my peers, I received the OpenTelemetry 2025 Contributor Award.
In 2025, I spoke at 9 different conferences about my journey with OpenTelemetry and how important motivation is for the long run contributors in cloud native.

You can do it too. The OpenTelemetry community is extremely supportive and communicative. Be curious, ask questions, show up, diversify your contributions, stay motivated. The results won't fail to appear!

Where to find me: https://github.com/didiViking
Ask me questions: https://www.linkedin.com/in/diana-todea-b2a79968/

Article originally published on Medium, read here.