Documentation Grafana Cloud Monitor infrastructure Kubernetes Monitoring Configure Kubernetes Monitoring Configure with Helm chart Helm chart Collector reference

Grafana Alloy collector reference

Use this reference if you want to configure Grafana Alloy instances without using the Kubernetes Monitoring configuration GUI or if you want to modify Alloy instances you have deployed.

Collectors are Grafana Alloy instances deployed by the Alloy Operator as Kubernetes workloads. This information covers collector options specific to the Kubernetes Monitoring Helm chart.

When you enable a collector, Alloy Operator creates a Kubernetes workload as either a DaemonSet, StatefulSet, or Deployment, with its own set of Pods running Alloy containers. Each collector uses a workload type appropriate for the type of telemetry it collects.

General configuration

Each collector is defined in its own section in the values file of the Kubernetes Monitoring Helm chart. To enable and configure a collector, follow this general format:

yaml Copy

alloy-<collector name>:
  enabled: true # Enable deploying this collector

  alloy: # Settings related to the Alloy instance
    ...
  controller: # Settings related to the Alloy controller
    ...

Because collectors are deployed using the Alloy Operator, you can use any of the standard Alloy helm chart values. These values will be used when creating the Alloy instance.

Alloy Receiver

• Pod name: <helm_release>-alloy-receiver-*
• Default controller type: DaemonSet
• Service name: <helm_release_name>-alloy-receiver

This collector creates an Alloy instance deployed as a DaemonSet to receive application metrics when the Application Observability feature is enabled.

For each receiver enabled, configure this collector to expose the corresponding ports on the Kubernetes service that is fronting the Pods. For example, to enable a receiver to collect Zipkin traces, add:

yaml Copy

applicationObservability:
  enabled: true
  receivers:
    otlp:
      grpc:
        enabled: true
        port: 4317
      http:
        enabled: true
        port: 4318
---
alloy-receiver:
  enabled: true
  alloy:
    extraPorts:
      - name: otlp-grpc
        port: 4317
        targetPort: 4317
        protocol: TCP
      - name: otlp-http
        port: 4318
        targetPort: 4318
        protocol: TCP

Client endpoint configuration

You can configure endpoints inside or outside the Cluster.

Inside the Cluster

Applications inside the Kubernetes Cluster use the kubedns name to reference a particular receiver endpoint. For example:

yaml Copy

endpoint: http://grafana-k8s-monitoring-alloy[.mynamespace.cluster.local]:4318

Outside the Cluster

To expose the receiver to applications outside the Cluster (for example, Frontend Observability), you can use different approaches depending on your setup. Load balancers are created by whatever controllers are installed on your Cluster. For the full list of options, refer to the Alloy chart values.

For example, to create a Network Load Balancer on Amazon Elastic Kubernetes Service (Amazon EKS) when using the AWS Load Balancer Controller, use this example:

yaml Copy

alloy-receiver:
  alloy:
    service:
      type: LoadBalancer

To create an Application Load Balancer, use this example:

yaml Copy

alloy-receiver:
  alloy:
    ingress:
      enabled: true
      path: /
      faroPort: 12347

You can also create additional services and ingress objects as needed if the Alloy Helm chart options don’t fit your needs. Consult your Kubernetes vendor documentation for details.

Istio/Service Mesh

Depending on your mesh configuration, you might need to do either of these:

• Explicitly include the Grafana monitoring namespace as a member.
• Declare the receiver as a backend of your application for traffic within the Cluster.

For traffic from outside the Cluster, it’s likely you need to set up an ingress gateway into your mesh. In any case, consult your mesh vendor for details.

Troubleshooting

Here are some troubleshooting tips related to configuring collectors.

Startup issues

Make sure your receiver Pods are up and running. Use this command to show you a list of Pods and associated states:

kubectl get pods -n <helm_release_namespace>

While you may have meta monitoring turned on (which exposes the Alloy Pod logs in Loki), this is not helpful when the alloy-logs receiver itself is faulty.

To troubleshoot receiver startup problems, inspect the Pod logs using the method you would for any Kubernetes workload. To watch the alloy-logs receiver Pods, use:

kubectl logs -f --tail 100 ds/grafana-k8s-monitoring-alloy-logs

Alloy debugger

You can apply standard Alloy troubleshooting strategies to each collector Pod specifically for Kubernetes.

1. To access the Alloy UI on a collector Pod, forward the UI port to your local machine:

   bash Copy

   kubectl port-forward grafana-k8s-monitoring-alloy-receiver 12345:12345

2. Open your browser to http://localhost:12345

Scaling

Follow these instructions for appropriate scaling.

DaemonSets and Singleton instances

For collectors deployed as DaemonSets and Singleton instances, one Pod is deployed per Node. You cannot deploy more replicas with this type of controller. To scale the individual Pods, increase the resource requests and limits. Refer to Estimate Grafana Alloy resource usage to learn how to tune those parameters.

For example:

yaml Copy

alloy-metrics:
  alloy:
    resources:
      requests: {}
      limits: {}

StatefulSets

For StatefulSet collectors, set the number of replicas in the alloy config section of the collector:

yaml Copy

alloy-metrics:
  controller:
    replicas: 3

Autoscaling

Alloy doesn’t provide autoscaling out of the box. However, depending on the type of deployment for the collector, you can use these Kubernetes autoscalers:

• HorizontalPodAutoscaler (HPA)
• VerticalPodAutoscaler (VPA)

Set the target for the HPA or VPA to the collector deployment name.

Values reference

The following is a reference for for collector values.

Alloy Logs

Alloy Metrics

Alloy Profiles

Alloy Receiver

Alloy Singleton

Additional configuration sources

Each collector also has the ability to specify additional configuration sources. These are specified within the Alloy instance’s own section in the values file: