Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Workload]: metrics-emitter

Aperta
  • Qualcosa non va?
#156 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
go, kubernetes, prometheus
Ambito
infrastructure, observability-sre

Direzione di ricerca

Inizia individuando le implementazioni esistenti dei workload cpu, memory e disk e la generazione dei relativi Kubernetes Service. Esamina come sono definiti i servizi cloud-init e systemd, quindi confronta il comando avalanche proposto e le label del Service per la porta 9101 con le convenzioni dei workload. Il lavoro è completato quando una VM metrics-emitter espone l’endpoint Prometheus configurato e il suo Service supporta il rilevamento tramite ServiceMonitor o PodMonitor.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
Go
Stelle
0
Fork
0
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di opdev/virtwork

Tutte le issue di opdev/virtwork

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.