Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

[Workload]: log-generator

Aberta
  • Algo errado?
#155 0 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Funcionalidade
Clareza
Precisa de esclarecimento
Status de atividade
Pouca atividade
Stack de tecnologia
bash, go
Domínio
infrastructure, observability

Direção de pesquisa

Revise primeiro as cargas de trabalho existentes de CPU, memória e disco para descobrir como as cargas de trabalho de VM e os payloads de cloud-init são representados. A proposta indica /usr/local/bin/virtwork-log-generator.sh e virtwork-log-generator.service como os principais pontos de entrada, com journald e saída opcional para arquivo. O trabalho estará concluído quando uma carga de trabalho de uma única VM puder gerar de forma confiável os formatos acordados e usar a taxa e os destinos de saída configuráveis.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

log-generator

Workload Description

Structured log emission workload that generates logs at configurable rates and formats. Produces sustained log volume in common formats — syslog (RFC 5424), JSON (structured), Apache combined, and nginx access log — written to journald and/or log files.

This workload fills the gap for log management and SIEM partners. The current virtwork workloads produce system-level metrics (CPU, memory, disk I/O) but generate minimal log output. Partners building log aggregation, analysis, and security information products (Splunk, Elastic, Datadog Logs, Sumo Logic, CrowdStrike Falcon LogScale) need sustained log volume with realistic structure and variety to validate their agents correctly collect, parse, and forward logs from VMs on OpenShift.

Tooling and Packages
  • Tool: flog (fake log generator — supports Apache combined, RFC5424, JSON, Common Log Format) or a lightweight shell script using logger (for syslog) and structured echo loops (for JSON/file-based)
  • RPM packages: none required if using a shell-based generator; flog is a single Go binary
  • systemd service command: flog -f json -d 100ms -l (generate JSON logs at 10 lines/sec, infinite loop)
  • Configurable parameters: format (syslog, json, apache, nginx), rate (lines/sec), output target (stdout→journald, file path), log line size, number of unique source IPs/paths (controls cardinality)
VM Count Model

Single VM (like cpu, memory, disk)

Required Resources
  • Persistent storage (DataVolume)
  • Kubernetes Service (for inter-VM communication)
  • Kubernetes Secret (for credentials or config)
  • Additional CPU/memory beyond defaults
  • GPU or special device passthrough
Cloud-Init Details
write_files:
  - path: /usr/local/bin/virtwork-log-generator.sh
    permissions: '0755'
    content: |
      #!/bin/bash
      # Configurable log generation
      FORMAT="${LOG_FORMAT:-json}"
      RATE="${LOG_RATE:-10}"  # lines per second
      DELAY=$(echo "scale=3; 1/$RATE" | bc)
      while true; do
        case "$FORMAT" in
          json)
            echo "{\"timestamp\":\"$(date -Iseconds)\",\"level\":\"$(shuf -n1 -e INFO WARN ERROR DEBUG)\",\"service\":\"virtwork-app\",\"message\":\"$(shuf -n1 -e 'Request processed' 'Connection established' 'Cache miss' 'Query completed' 'Auth validated')\",\"duration_ms\":$((RANDOM % 500)),\"status\":$(shuf -n1 -e 200 201 301 400 404 500)}"
            ;;
          syslog)
            logger -p "$(shuf -n1 -e local0.info local0.warn local0.err)" "virtwork-app: $(shuf -n1 -e 'request_handled' 'connection_timeout' 'cache_refreshed' 'query_slow') duration=$((RANDOM % 500))ms"
            ;;
          apache)
            echo "$(printf "%d.%d.%d.%d" $((RANDOM%256)) $((RANDOM%256)) $((RANDOM%256)) $((RANDOM%256))) - - [$(date '+%d/%b/%Y:%H:%M:%S %z')] \"GET /$(shuf -n1 -e api/v1/users api/v1/orders health metrics static/app.js) HTTP/1.1\" $(shuf -n1 -e 200 200 200 301 404 500) $((RANDOM % 50000))"
            ;;
        esac
        sleep "$DELAY"
      done
  - path: /etc/systemd/system/virtwork-log-generator.service
    content: |
      [Unit]
      Description=Virtwork log generation workload
      After=network-online.target
      [Service]
      Type=simple
      Environment=LOG_FORMAT=json
      Environment=LOG_RATE=10
      ExecStart=/usr/local/bin/virtwork-log-generator.sh
      Restart=always
      RestartSec=5
      StandardOutput=journal
      SyslogIdentifier=virtwork-log-generator
      [Install]
      WantedBy=multi-user.target
runcmd:
  - systemctl enable --now virtwork-log-generator.service
Use Case
  • Log management partners (Splunk, Elastic, Datadog Logs): Need sustained log volume from VMs to validate their agents correctly discover, collect, parse, and forward logs. Different formats test different parsing pipelines.
  • SIEM partners (CrowdStrike, Splunk ES, IBM QRadar): Need structured security-relevant log events (auth failures, connection anomalies) to validate detection rules and correlation engines against VM-sourced logs on OpenShift.
  • Observability partners: Need correlated logs alongside the metrics generated by other virtwork workloads (CPU, memory, disk) to validate unified observability dashboards.
  • Compliance/audit partners: Need to validate that log collection from VMs meets retention and completeness requirements — log-generator with known output rate provides a ground truth for verifying no logs are dropped.
Additional Context
  • The shell-based approach is preferred for initial implementation: zero external dependencies, easy to extend formats, and the script itself is the cloud-init payload. flog can be offered as an alternative for higher throughput.
  • Configurable parameters to expose via CLI/YAML: log-format (json, syslog, apache, nginx), log-rate (lines/sec), log-output (journal, file, both), log-line-size (bytes), log-cardinality (number of unique source IPs/paths/services — controls how many unique log streams the partner product must handle).
  • Output to journald (via StandardOutput=journal) ensures logs are available through the standard Linux logging pipeline that most partner agents hook into. File output can target /var/log/virtwork/ for agents that tail files.
  • At 100 lines/sec with ~200 byte JSON lines, this generates ~1.7 MB/min or ~2.4 GB/day per VM — realistic for a moderately active application server.
Linguagem predominante
Go
Estrelas
0
Forks
0
Nenhum PR com merge em 30d

Preparar o ambiente

  • Inclui um Dockerfile ou arquivo Docker Compose
  • Sem modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de opdev/virtwork

Todas as issues de opdev/virtwork

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.