Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

[Workload]: metrics-emitter

Offen
  • Stimmt etwas nicht?
#156 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
45/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
go, kubernetes, prometheus
Bereich
infrastructure, observability-sre

Rechercherichtung

Beginnen Sie damit, die vorhandenen Implementierungen der cpu-, memory- und disk-Workloads sowie deren Kubernetes Service-Generierung zu finden. Prüfen Sie, wie cloud-init- und systemd-Services definiert sind, und vergleichen Sie anschließend den vorgeschlagenen avalanche-Befehl und die Service-Labels für Port 9101 mit den Konventionen der Workloads. Als erfüllt gilt die Aufgabe, wenn eine metrics-emitter-VM den konfigurierten Prometheus-Endpunkt bereitstellt und ihr Service die Erkennung durch ServiceMonitor oder PodMonitor unterstützt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

good first issue priority/backlog size/L triage/accepted workload-request workload/tier-1
Workload Name

metrics-emitter

Workload Description

A workload that runs a Prometheus-compatible metrics endpoint inside a VM, exposing configurable gauges, counters, and histograms with tunable label cardinality and scrape-ready /metrics path. Produces sustained, realistic metric signals that monitoring partners can scrape via OpenShift's native ServiceMonitor/PodMonitor pipeline.

This is the missing link between virtwork's in-VM workloads and the Prometheus-based monitoring ecosystem on OpenShift. The current workloads (cpu, memory, disk, database) generate real system pressure, but monitoring partners need scrapeable application metrics — not just node-level signals. A metrics-emitter VM acts as a synthetic application that exposes the same kind of metric surface a real business application would: request duration histograms, active connection gauges, error counters, queue depth gauges — all with configurable cardinality to stress the partner's ingestion pipeline.

Tooling and Packages
  • Tool: avalanche (Prometheus metric load generator by Prometheus team) or a lightweight custom exporter
  • avalanche flags: --metric-count=500 --label-count=10 --series-count=5 --port=9101 --value-interval=30
  • RPM packages: none — avalanche is a single Go binary
  • systemd service command: /usr/local/bin/avalanche --metric-count=500 --label-count=10 --series-count=5 --port=9101
  • Exposes port 9101 (Prometheus metrics) via Kubernetes Service
  • Configurable parameters: metric count, label count (cardinality), series count per metric, value change interval, port
VM Count Model

Single VM (like cpu, memory, disk)

Required Resources
  • Kubernetes Service (for inter-VM communication)
  • Persistent storage (DataVolume)
  • Kubernetes Secret (for credentials or config)
  • Additional CPU/memory beyond defaults
  • GPU or special device passthrough
Cloud-Init Details
write_files:
  - path: /etc/systemd/system/virtwork-metrics-emitter.service
    content: |
      [Unit]
      Description=Virtwork Prometheus metrics emitter
      After=network-online.target
      Wants=network-online.target
      [Service]
      Type=simple
      ExecStart=/usr/local/bin/avalanche \
        --metric-count=500 \
        --label-count=10 \
        --series-count=5 \
        --port=9101 \
        --value-interval=30
      Restart=always
      RestartSec=5
      [Install]
      WantedBy=multi-user.target
runcmd:
  - curl -Lo /usr/local/bin/avalanche https://github.com/prometheus-community/avalanche/releases/download/v0.6.0/avalanche_0.6.0_linux_amd64.tar.gz
  - tar -xzf /usr/local/bin/avalanche -C /usr/local/bin/
  - chmod +x /usr/local/bin/avalanche
  - systemctl enable --now virtwork-metrics-emitter.service

The Kubernetes Service should expose port 9101 with appropriate labels for ServiceMonitor discovery:

apiVersion: v1
kind: Service
metadata:
  name: virtwork-metrics-emitter-0
  labels:
    app.kubernetes.io/managed-by: virtwork
    virtwork/component: metrics-emitter
    virtwork/metrics: "true"
spec:
  ports:
    - name: metrics
      port: 9101
      targetPort: 9101
  selector:
    # matches VM pod labels
Use Case
  • Monitoring platform partners (Datadog, Dynatrace, Sysdig, Grafana Labs): Need scrapeable Prometheus endpoints from VMs to validate that their agents correctly discover, scrape, and ingest application-level metrics from KubeVirt VMs — not just node/kubelet metrics. High cardinality (many labels × many series) stresses ingestion pipelines and validates the partner's ability to handle metric volume at scale.
  • Prometheus/Thanos/Mimir ecosystem partners: Need realistic scrape targets to validate long-term storage, compaction, and query performance against VM-sourced metrics. Configurable metric count and cardinality lets partners tune the load to match their customers' real-world profiles.
  • OpenShift platform validation: Validates that the full Prometheus pipeline — ServiceMonitor discovery → scrape → remote write → partner product — works correctly when the scrape target is a KubeVirt VM rather than a pod. This exercises a code path that's distinct from container-based scraping and is less commonly tested.
  • Capacity planning partners: Need predictable, tunable metric volume to validate alerting thresholds and dashboard rendering under load.
Additional Context
  • avalanche is maintained by the Prometheus community and designed specifically for this purpose: generating configurable Prometheus metric load. It's the standard tool for testing Prometheus-compatible backends.
  • The Kubernetes Service is critical — it enables OpenShift's ServiceMonitor to discover and scrape the VM's metrics endpoint through the standard Prometheus operator pipeline. This is what makes this workload uniquely valuable on OpenShift vs. a bare VM.
  • Configurable parameters to expose via CLI/YAML: metric-count (number of distinct metrics), label-count (labels per metric — controls cardinality), series-count (series per metric), value-interval (seconds between value changes), port.
  • Consider also generating a sample ServiceMonitor CR in dry-run output to show partners how to wire up scraping. This isn't a virtwork-managed resource but a documentation/example artifact.
  • At 500 metrics × 5 series × 10 labels, a single VM produces ~2,500 time series — comparable to a moderately instrumented microservice. Scaling to 5,000+ metrics or 50+ labels tests high-cardinality ingestion.
Vorherrschende Sprache
Go
Sterne
0
Forks
0
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

  • Enthält ein Dockerfile oder eine Docker-Compose-Datei
  • Keine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus opdev/virtwork

Alle Issues in opdev/virtwork

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.