grafana / alloy-modules

The open-source platform for monitoring and observability

Grafana allows you to query, visualize, alert on and understand your metrics no matter where they are stored. Create, explore, and share dashboards with your team and foster a data-driven culture:

• Visualizations: Fast and flexible client side graphs with a multitude of options. Panel plugins offer many different ways to visualize metrics and logs.
• Dynamic Dashboards: Create dynamic & reusable dashboards with template variables that appear as dropdowns at the top of the dashboard.
• Explore Metrics: Explore your data through ad-hoc queries and dynamic drilldown. Split view and compare different time ranges, queries and data sources side by side.
• Explore Logs: Experience the magic of switching from metrics to logs with preserved label filters. Quickly search through all your logs or streaming them live.
• Alerting: Visually define alert rules for your most important metrics. Grafana will continuously evaluate and send notifications to systems like Slack, PagerDuty, VictorOps, OpsGenie.
• Mixed Data Sources: Mix different data sources in the same graph! You can specify a data source on a per-query basis. This works for even custom datasources.

Get started

• Get Grafana
• Installation guides

Unsure if Grafana is for you? Watch Grafana in action on play.grafana.org!

Documentation

The Grafana documentation is available at grafana.com/docs.

Contributing

If you're interested in contributing to the Grafana project:

• Start by reading the Contributing guide.
• Learn how to set up your local environment, in our Developer guide.
• Explore our beginner-friendly issues.
• Look through our style guide and Storybook.

Get involved

• Follow @grafana on Twitter.
• Read and subscribe to the Grafana blog.
• If you have a specific question, check out our discussion forums.
• For general discussions, join us on the official Slack team.

This project is tested with BrowserStack

License

Grafana is distributed under AGPL-3.0-only. For Apache-2.0 exceptions, see LICENSING.md.

alloy-modules's Issues

Module for windows-exporter

[alloy-modules-to-configmaps-helm-chart] is STALE

@Imshelledin21,

alloy-modules-to-configmaps-helm-chart has had no activity for 61 days.

This branch will be automatically deleted in 29 days.

[node-exporter-vm-metrics] is STALE

@Imshelledin21,

node-exporter-vm-metrics has had no activity for 62 days.

This branch will be automatically deleted in 28 days.

[blackbox-exporter-module] is STALE

@Imshelledin21,

blackbox-exporter-module has had no activity for 61 days.

This branch will be automatically deleted in 29 days.

Implement Auto Tagging

To ensure users can consume modules outside of the main branch, tags need to be used. I don't think we will do releases due to the nature of the repo, but we should tag every merge to the main branch.

Consider implementing the GitHub action: https://github.com/marketplace/actions/github-tag-bump

kube-state-metrics module metrics.alloy fixes

Found a couple of config issues when trying to utilize the kube-state-metrics module

• discovery.relabel "ksm" component referenced the wrong component in it's targets argument
• prometheus.scrape "kube_state_metrics" component didn't reference argument.targets.value, instead referenced a direct component that didn't exist

Create Helm Chart from Modules

It would be great to create a helm chart from all of the modules that would automatically create config maps, this way it can be included as a sub chart. Then modules can be imported via configmap / import.string

remote.kubernetes.configmap "agent_mysql_module" {
  namespace = "monitoring"
  name = "agent-mysql-module"
}

import.string "mysql" {
  content = remote.kubernetes.configmap.agent_mysql_module.data["databases-sql-mysql-metrics.river"]
}

[windows-logs] is STALE

@Imshelledin21,

windows-logs has had no activity for 62 days.

This branch will be automatically deleted in 28 days.

[mattdurham-patch-1] is STALE

@web-flow,

mattdurham-patch-1 has had no activity for 62 days.

This branch will be automatically deleted in 28 days.

[dependabot-npm_and_yarn-editorconfig-checker-5.1.8] is STALE

@web-flow,

dependabot-npm_and_yarn-editorconfig-checker-5.1.8 has had no activity for 61 days.

This branch will be automatically deleted in 29 days.

[imports] is STALE

@bentonam,

imports has had no activity for 61 days.

This branch will be automatically deleted in 29 days.

Discovery drops on a non-existent label

This same rule is found across various modules as the first discovery.relabel rule. It does a keep based on labels that the pod has a port name defined or one named metrics, is running and ready. But it also checks that the container is not an init container. The problem I have is that I don't have the label for init containers on any of my scrapes. So I'm getting a lot of stuff dropped that shouldn't be. This came to light because I can't get the kube_dns scrape in the core module to work and removing this fourth label from the keep caused it to start working.

I'm happy to submit a PR, but I'm wondering if the right move is to remove this last keep requirement for __meta_kubernetes_pod_container_init ... we could add a drop rule after this rule for if __meta_kubernetes_pod_container_init=true to solve what I think this is trying to do. Can anyone confirm my solution is correct and I'll get it PRd to all the places this exists?

  // kube_dns relabelings (pre-scrape)
  discovery.relabel "kube_dns" {
    targets = discovery.kubernetes.kube_dns.targets

    // keep only the specified metrics port name, and pods that are Running and ready
    rule {
      source_labels = [
        "__meta_kubernetes_pod_container_port_name",
        "__meta_kubernetes_pod_phase",
        "__meta_kubernetes_pod_ready",
        "__meta_kubernetes_pod_container_init",
      ]
      separator = "@"
      regex = coalesce(argument.port_name.value, "metrics") + "@Running@true@false"
      action = "keep"
    }

  // kube_dns relabelings (pre-scrape)
  discovery.relabel "kube_dns" {
    targets = discovery.kubernetes.kube_dns.targets

    // keep only the specified metrics port name, and pods that are Running and ready
    rule {
      source_labels = [
        "__meta_kubernetes_pod_container_port_name",
        "__meta_kubernetes_pod_phase",
        "__meta_kubernetes_pod_ready",
      ]
      separator = "@"
      regex = coalesce(argument.port_name.value, "metrics") + "@Running@true"
      action = "keep"
    }

    // drop any init containers
    rule {
      source_labels = ["__meta_kubernetes_pod_container_init"]
      regex = "true"
      action = "drop"
    }

[windows-exporter-module] is STALE

@web-flow,

windows-exporter-module has had no activity for 61 days.

This branch will be automatically deleted in 29 days.

[unstable] is STALE

@web-flow,

unstable has had no activity for 63 days.

This branch will be automatically deleted in 27 days.