Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alloy does not recognize "queue_config" block #2159

Open
hmahdiany opened this issue Nov 26, 2024 · 3 comments
Open

Alloy does not recognize "queue_config" block #2159

hmahdiany opened this issue Nov 26, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@hmahdiany
Copy link

hmahdiany commented Nov 26, 2024

What's wrong?

I'm using Grafana Alloy version "1.4.3" running as a deamon-set on a Kubernetes cluster version 1.26.16. Here is my remote write configuration:

prometheus.remote_write "remote_write" {
        external_labels = {
        cluster = env("CLUSTER"),
        source_exporter = "alloy",
        }
        queue_config {
          max_samples_per_send = 8000
          batch_send_deadline  = "60s"
        }
        endpoint {
          url = env("REMOTE_WRITE_URL")
            basic_auth {
              username = env("REMOTE_WRITE_USERNAME")
              password = env("REMOTE_WRITE_PASSWORD")
            }
        }
      }

I get this error message:

Error: /etc/alloy/config.alloy:7:3: unrecognized block name "queue_config"

 6 |     }
 7 |     queue_config {
   |  ___^^^^^^^^^^^^^^
 8 | |     max_samples_per_send = 8000
 9 | |     batch_send_deadline  = "60s"
10 | |   }
   | |_^^^
11 |     endpoint {
interrupt received
Error: could not perform the initial load successfully

As documentation suggests "queue_config" should work from version "1.3.0" but it doesn't.

Steps to reproduce

Deploy Grafana Alloy via it's Helm chart with following configuration for remote write:

alloy:
  configMap:
    # -- Create a new ConfigMap for the config file.
    create: true
    # -- Content to assign to the new ConfigMap.  This is passed into `tpl` allowing for templating from values.
    content: |
      prometheus.remote_write "remote_write" {
        external_labels = {
        cluster = env("CLUSTER"),
        source_exporter = "alloy",
        }
        queue_config {
          max_samples_per_send = 8000
          batch_send_deadline  = "60s"
        }
        endpoint {
          url = env("REMOTE_WRITE_URL")
            basic_auth {
              username = env("REMOTE_WRITE_USERNAME")
              password = env("REMOTE_WRITE_PASSWORD")
            }
        }
      }

It creates a configmap on your cluster called "alloy" and when you get Alloy log it shows that "queue_config" is not a valid block.

System information

Kubernetes 1.26.16

Software version

Grafana Alloy v1.4.3

Configuration

prometheus.remote_write "remote_write" {
        external_labels = {
        cluster = env("CLUSTER"),
        source_exporter = "alloy",
        }
        queue_config {
          max_samples_per_send = 8000
          batch_send_deadline  = "60s"
        }
        endpoint {
          url = env("REMOTE_WRITE_URL")
            basic_auth {
              username = env("REMOTE_WRITE_USERNAME")
              password = env("REMOTE_WRITE_PASSWORD")
            }
        }
      }

Logs

`Error: /etc/alloy/config.alloy:7:3: unrecognized block name "queue_config"

 6 |     }
 7 |     queue_config {
   |  ___^^^^^^^^^^^^^^
 8 | |     max_samples_per_send = 8000
 9 | |     batch_send_deadline  = "60s"
10 | |   }
   | |_^^^
11 |     endpoint {
interrupt received
Error: could not perform the initial load successfully`
@hmahdiany hmahdiany added the bug Something isn't working label Nov 26, 2024
@dehaansa
Copy link
Contributor

The queue_config block belongs inside the endpoint block, that should resolve your issue.

@hmahdiany
Copy link
Author

Thank you @dehaansa. It definitely solved my problem. I think this document should be updated.

@wildum
Copy link
Contributor

wildum commented Nov 27, 2024

hi, the blocks table has a hierarchy column with "endpoint > queue_config".
"The > symbol indicates deeper levels of nesting. For example, endpoint > basic_auth refers to a basic_auth block defined inside an endpoint block."
This seems easy to miss in big docs though. Maybe nested block descriptions should mention their parent block? @clayton-cornell any thoughts on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants