Add blog paving-the-way-for-a-new-logging-backend-the-victorialogsbackend-feature-gate#883
Conversation
…kend-feature-gate
📝 WalkthroughWalkthroughA blog post is added documenting the ChangesBlog Post: VictoriaLogsBackend Feature Gate Documentation
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Suggested labels
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Review rate limit: 0/1 reviews remaining, refill in 60 minutes.Comment |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
✅ Deploy Preview for soon-to-be-gardenercloud ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
The Gardener project currently lacks enough active contributors to adequately respond to all PRs.
You can:
/lifecycle stale |
|
The Gardener project currently lacks enough active contributors to adequately respond to all PRs.
You can:
/lifecycle rotten |
|
/lgtm |
|
@rrhubenov: adding LGTM is restricted to approvers and reviewers in OWNERS files. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
website/blog/2026/03/03-04-paving-the-way-for-a-new-logging-backend-the-victorialogsbackend-feature-gate.md (1)
27-32: ⚡ Quick winAdd a concrete
kubectl port-forwardexample (or placeholders) for the VMUI.At Line 31, the post tells readers to port-forward the
logging-vlservice but doesn’t include a command or port mapping, which makes it harder for users to follow precisely. Suggest adding an example command using placeholders for the VMUI port if it’s not uniform across setups (e.g.,<VMUI_PORT>), or link to where the port is defined.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@website/blog/2026/03/03-04-paving-the-way-for-a-new-logging-backend-the-victorialogsbackend-feature-gate.md` around lines 27 - 32, Add a concrete kubectl port-forward example for accessing the VMUI by showing the command to forward the logging-vl service to a local port (use placeholders like <VMUI_PORT> and <LOCAL_PORT> if the VMUI port varies) and include brief guidance about the namespace and how to find the service port (e.g., reference the logging-vl service and VMUI). Update the paragraph mentioning "port-forward the `logging-vl` service" to include that example command and a note directing readers to where the VMUI port is defined if it isn’t standard.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@website/blog/2026/03/03-04-paving-the-way-for-a-new-logging-backend-the-victorialogsbackend-feature-gate.md`:
- Around line 15-36: The headings in the blog post use h3 (###) where the
document structure expects h2 (MD001); update the top-level section headings
like "A New Feature Gate for a Gradual Transition", "How It Works: Dual-Writing
Logs", "Exploring the New VictoriaLogs UI", and "What's Next?" from ### to ##
and then increment subsequent subsection headings consistently (e.g., make any
nested headings one level deeper than these) so the hierarchy is correct across
the article.
---
Nitpick comments:
In
`@website/blog/2026/03/03-04-paving-the-way-for-a-new-logging-backend-the-victorialogsbackend-feature-gate.md`:
- Around line 27-32: Add a concrete kubectl port-forward example for accessing
the VMUI by showing the command to forward the logging-vl service to a local
port (use placeholders like <VMUI_PORT> and <LOCAL_PORT> if the VMUI port
varies) and include brief guidance about the namespace and how to find the
service port (e.g., reference the logging-vl service and VMUI). Update the
paragraph mentioning "port-forward the `logging-vl` service" to include that
example command and a note directing readers to where the VMUI port is defined
if it isn’t standard.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 3792b965-7a17-4433-869e-57a18acfda5e
📒 Files selected for processing (1)
website/blog/2026/03/03-04-paving-the-way-for-a-new-logging-backend-the-victorialogsbackend-feature-gate.md
| ### A New Feature Gate for a Gradual Transition | ||
|
|
||
| The `VictoriaLogsBackend` feature gate, available for both `gardenlet` and `gardener-operator`, allows you to start experimenting with the new logging backend. When enabled, Gardener deploys a `VictoriaLogs` instance in every `Garden`, `Seed`, and `Shoot` cluster. | ||
|
|
||
| Crucially, this initial phase is designed for safety and stability. The existing Vali instance remains active and continues to receive logs. This parallel deployment ensures that the logging pipeline is not interrupted during the transition period. | ||
|
|
||
| ### How It Works: Dual-Writing Logs | ||
|
|
||
| With the `VictoriaLogsBackend` feature gate enabled, the OpenTelemetry Collector is reconfigured to send logs to both the existing Vali instance and the new VictoriaLogs instance. This dual-writing mechanism is key to the migration strategy, guaranteeing that no logs are lost and allowing for direct comparison and verification between the two systems. | ||
|
|
||
| The architectural change is straightforward: logs collected by Fluent Bit and processed by the OpenTelemetry Collector are now routed to two destinations instead of one. | ||
|
|
||
| ### Exploring the New VictoriaLogs UI | ||
|
|
||
| While Gardener's current dashboarding tool, Plutono, does not have a native integration for VictoriaLogs, you can still explore your logs through the powerful, feature-rich UI provided by VictoriaMetrics itself, known as the VMUI. | ||
|
|
||
| To access it, you can port-forward the `logging-vl` service in the respective cluster namespace. The UI offers valuable statistics and a different way to query and visualize your log data. For those running a local Gardener setup, this feature gate is enabled by default, making it easy to start experimenting right away. | ||
|
|
||
| ### What's Next? | ||
|
|
||
| This update represents the first major step in the migration to VictoriaLogs. Future releases will build upon this foundation, culminating in a final step that will introduce another feature gate to cleanly remove Vali, completing the transition. Stay tuned for more updates as we continue to enhance Gardener's observability capabilities. | ||
|
|
There was a problem hiding this comment.
Fix markdownlint heading levels (MD001).
markdownlint reports that at Line 15 it expected an h2 heading but found an h3 (###). To keep the structure consistent, consider changing the first-level headings to ## (and then using one increment level consistently within sections).
Suggested change
-### A New Feature Gate for a Gradual Transition
+## A New Feature Gate for a Gradual Transition
@@
-### How It Works: Dual-Writing Logs
+## How It Works: Dual-Writing Logs
@@
-### Exploring the New VictoriaLogs UI
+## Exploring the New VictoriaLogs UI
@@
-### What's Next?
+## What's Next?📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ### A New Feature Gate for a Gradual Transition | |
| The `VictoriaLogsBackend` feature gate, available for both `gardenlet` and `gardener-operator`, allows you to start experimenting with the new logging backend. When enabled, Gardener deploys a `VictoriaLogs` instance in every `Garden`, `Seed`, and `Shoot` cluster. | |
| Crucially, this initial phase is designed for safety and stability. The existing Vali instance remains active and continues to receive logs. This parallel deployment ensures that the logging pipeline is not interrupted during the transition period. | |
| ### How It Works: Dual-Writing Logs | |
| With the `VictoriaLogsBackend` feature gate enabled, the OpenTelemetry Collector is reconfigured to send logs to both the existing Vali instance and the new VictoriaLogs instance. This dual-writing mechanism is key to the migration strategy, guaranteeing that no logs are lost and allowing for direct comparison and verification between the two systems. | |
| The architectural change is straightforward: logs collected by Fluent Bit and processed by the OpenTelemetry Collector are now routed to two destinations instead of one. | |
| ### Exploring the New VictoriaLogs UI | |
| While Gardener's current dashboarding tool, Plutono, does not have a native integration for VictoriaLogs, you can still explore your logs through the powerful, feature-rich UI provided by VictoriaMetrics itself, known as the VMUI. | |
| To access it, you can port-forward the `logging-vl` service in the respective cluster namespace. The UI offers valuable statistics and a different way to query and visualize your log data. For those running a local Gardener setup, this feature gate is enabled by default, making it easy to start experimenting right away. | |
| ### What's Next? | |
| This update represents the first major step in the migration to VictoriaLogs. Future releases will build upon this foundation, culminating in a final step that will introduce another feature gate to cleanly remove Vali, completing the transition. Stay tuned for more updates as we continue to enhance Gardener's observability capabilities. | |
| ## A New Feature Gate for a Gradual Transition | |
| The `VictoriaLogsBackend` feature gate, available for both `gardenlet` and `gardener-operator`, allows you to start experimenting with the new logging backend. When enabled, Gardener deploys a `VictoriaLogs` instance in every `Garden`, `Seed`, and `Shoot` cluster. | |
| Crucially, this initial phase is designed for safety and stability. The existing Vali instance remains active and continues to receive logs. This parallel deployment ensures that the logging pipeline is not interrupted during the transition period. | |
| ## How It Works: Dual-Writing Logs | |
| With the `VictoriaLogsBackend` feature gate enabled, the OpenTelemetry Collector is reconfigured to send logs to both the existing Vali instance and the new VictoriaLogs instance. This dual-writing mechanism is key to the migration strategy, guaranteeing that no logs are lost and allowing for direct comparison and verification between the two systems. | |
| The architectural change is straightforward: logs collected by Fluent Bit and processed by the OpenTelemetry Collector are now routed to two destinations instead of one. | |
| ## Exploring the New VictoriaLogs UI | |
| While Gardener's current dashboarding tool, Plutono, does not have a native integration for VictoriaLogs, you can still explore your logs through the powerful, feature-rich UI provided by VictoriaMetrics itself, known as the VMUI. | |
| To access it, you can port-forward the `logging-vl` service in the respective cluster namespace. The UI offers valuable statistics and a different way to query and visualize your log data. For those running a local Gardener setup, this feature gate is enabled by default, making it easy to start experimenting right away. | |
| ## What's Next? | |
| This update represents the first major step in the migration to VictoriaLogs. Future releases will build upon this foundation, culminating in a final step that will introduce another feature gate to cleanly remove Vali, completing the transition. Stay tuned for more updates as we continue to enhance Gardener's observability capabilities. |
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 15-15: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@website/blog/2026/03/03-04-paving-the-way-for-a-new-logging-backend-the-victorialogsbackend-feature-gate.md`
around lines 15 - 36, The headings in the blog post use h3 (###) where the
document structure expects h2 (MD001); update the top-level section headings
like "A New Feature Gate for a Gradual Transition", "How It Works: Dual-Writing
Logs", "Exploring the New VictoriaLogs UI", and "What's Next?" from ### to ##
and then increment subsequent subsection headings consistently (e.g., make any
nested headings one level deeper than these) so the hierarchy is correct across
the article.

Purpose
@rrhubenov This is an automatically generated draft pull request proposing a new blog post based on your Gardener review meeting presentation you gave on 2026-03-04 titled:
The purpose of the blog post is to actively inform the community about new Gardener features or changes, as discussed during review meetings.
Notes to Reviewers
This draft was automatically generated by LLMs using the review meeting recording and referenced materials.
Please evaluate whether this topic is suitable for a blog post. If so, review and edit the content as needed.
If you decide the topic isn't appropriate for a blog post, feel free to close this PR and delete the branch.
Instructions for Reviewers
❌ If the draft isn't viable
✏️ If the draft is viable but requires editing
git clone https://github.com/gardener/documentation cd documentationgit fetch origin && git checkout blog/2026-03-04-paving-the-way-for-a-new-logging-backend-the-victorialogsbackend-feature-gatewebsite/blog/2026/03/03-04-paving-the-way-for-a-new-logging-backend-the-victorialogsbackend-feature-gate.md.✅ If the draft is ready for review
/lgtmto approve (required step)The documentation team will review your PR, as required by branch protection.
They will merge it once you (and any additional reviewers) have approved it.
@rrhubenov Thank you for helping us share valuable updates from the Gardener project with the community!
Summary by CodeRabbit