Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Workload]: metrics-emitter

Abierto
  • ¿Algo no está bien?
#156 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
go, kubernetes, prometheus
Área
infrastructure, observability-sre

Línea de trabajo

Comienza localizando las implementaciones existentes de las cargas de trabajo de cpu, memory y disk, así como la generación de sus Kubernetes Service. Revisa cómo se definen los servicios de cloud-init y systemd, y compara después el comando avalanche propuesto y las etiquetas del Service para el puerto 9101 con las convenciones de las cargas de trabajo. Se considera terminado cuando una VM metrics-emitter expone el endpoint de Prometheus configurado y su Service admite el descubrimiento mediante ServiceMonitor o PodMonitor.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Go
Estrellas
0
Forks
0
Sin PR fusionados en 30 d

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de opdev/virtwork

Todos los issues de opdev/virtwork

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.