add Grafana Alloy and Loki for centralized log collection - #270
add Grafana Alloy and Loki for centralized log collection#270IlyaMaluk wants to merge 2 commits into
Conversation
|
Warning Review limit reached
More reviews will be available in 39 minutes and 10 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughAdds Loki and Grafana Alloy to the local Kubernetes infrastructure: a Loki Service/Deployment and an Alloy DaemonSet with RBAC and a ConfigMap defining a pod-log collection pipeline. The Kustomize resources list is updated to include all three new manifests. CNPG is scaled to one instance, and the Makefile readiness check switches from ChangesLogging Stack and Infra Adjustments
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@deploy/k8s/infra/alloy-configmap.yaml`:
- Around line 8-10: The discovery.kubernetes "pods" block in
alloy-configmap.yaml is performing global pod discovery, causing duplicate log
collection across DaemonSet replicas. Add a node_name selector to the
discovery.kubernetes "pods" configuration that filters pods to the local node by
using the NODE_NAME environment variable (which should reference spec.nodeName).
Additionally, in the alloy-daemonset.yaml container spec, add a NODE_NAME
environment variable that retrieves its value from the fieldRef spec.nodeName to
ensure each DaemonSet replica only discovers and ingests logs from pods running
on its own node.
In `@deploy/k8s/infra/alloy-daemonset.yaml`:
- Line 46: Replace the mutable image reference `grafana/alloy:latest` with a
specific pinned version tag combined with the image digest to ensure
reproducibility and prevent unexpected image changes between deployments. Use a
format like `grafana/alloy:<specific-version>`@sha256`:<digest>` where the version
is a tested release tag and the digest provides immutability verification.
- Around line 12-14: The RBAC rule in the alloy-daemonset.yaml is granting
overly broad permissions that exceed what the pipeline actually requires. The
discovery.kubernetes component with role "pod" only needs access to the pods
resource, so you should modify the resources array to contain only "pods"
instead of the current list that includes nodes, nodes/proxy, services, and
endpoints. This reduces the cluster read scope and follows the principle of
least privilege.
- Around line 56-61: The volumeMounts for varlog (/var/log) and
varlibdockercontainers (/var/lib/docker/containers) in the Alloy daemonset are
not utilized by the loki.source.kubernetes pipeline configuration, which obtains
pod logs through the Kubernetes API instead. Remove both the volumeMounts
entries for varlog and varlibdockercontainers from the containers spec, and then
remove their corresponding hostPath volume definitions from the volumes section
at the pod level to eliminate unnecessary node-level filesystem exposure and
reduce security risk.
- Around line 42-58: The Alloy DaemonSet spec lacks security hardening controls
required to restrict the container's privileges. Add a securityContext field at
the pod spec level (under the serviceAccountName field) to configure a seccomp
profile, and add a securityContext field within the alloy container definition
(alongside the image and args fields) to enforce non-root execution with
runAsNonRoot set to true, readOnlyRootFilesystem set to true, and drop all Linux
capabilities using capabilities.drop set to ["ALL"]. This hardens the DaemonSet
while maintaining compatibility with the standard log collection workload
(Kubernetes discovery and pod logs via Loki) that requires no elevated
privileges.
In `@deploy/k8s/infra/loki.yaml`:
- Line 31: The Loki image specification in the loki.yaml file uses the `:latest`
tag which creates non-reproducible deployments and supply chain risks. Replace
the `grafana/loki:latest` image reference with a pinned semantic version tag
(such as a specific release like 2.9.4) followed by the image digest using the
`@sha256:` format. You can find the correct digest for your chosen Loki version
from the Grafana container registry, ensuring both reproducibility and security.
- Around line 29-33: The Loki deployment in the spec section lacks security
restrictions that prevent privilege escalation and unauthorized access. Add a
securityContext at the pod spec level (before the containers array in the
template.spec section) to enforce RuntimeDefault seccomp and set fsGroup
settings. Additionally, add a securityContext within the container specification
(after the name and image fields of the loki container) to run the container as
a non-root user with UID 10001, drop all Linux capabilities, set
allowPrivilegeEscalation to false, and configure readOnlyRootFilesystem to true.
These settings will enforce the principle of least privilege while maintaining
Loki's functionality.
🪄 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: b10be3fd-f97c-4e39-8638-0bcc9b4c470a
📒 Files selected for processing (6)
Makefiledeploy/k8s/infra/alloy-configmap.yamldeploy/k8s/infra/alloy-daemonset.yamldeploy/k8s/infra/cnpg.yamldeploy/k8s/infra/kustomization.yamldeploy/k8s/infra/loki.yaml
1 participant
Summary by CodeRabbit
New Features
Chores