Safe, aggregate-only production reports (Bugsnag / Scout / Heroku) for maintainers

Abierto
  • ¿Algo no está bien?
#7,264 2 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@1steve78 ya está trabajando en esto.

Desde el 1/11/2026.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rails, ruby
Área
devops, observability, security

Línea de trabajo

Start by checking the existing production monitoring scripts and documentation under bin/ and doc/, then review the Bugsnag, Scout APM, and Heroku read-only API options named in the issue. Define an allow-list for each report and use recorded responses containing fake PII to verify sensitive fields never appear. Done means the aggregate reports, absence-of-PII specs, and maintainer setup docs are in place.

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

Descripción

✨ New Feature Difficulty: Intermediate

Problem

Today, production signal reaches contributors only as Discord bot posts (#bot-bugsnag, #bot-scout, #prod-app-performance). Each Bugsnag post links to an event most contributors can't open. The same error repeats for days without anyone seeing the count or trend (e.g. the CSRF errors in #7243). Raw Heroku logs and Bugsnag events can include youth data (see #7263), so we can't just hand out access or paste them into issues or AI tools.

Proposal: aggregate-only, read-only scripts maintainers can run and share

Add bin/prod-report (or three small scripts) that use read-only credentials and print only aggregates that are safe to paste into a GitHub issue:

  • Bugsnag (Data Access API, read-only collaborator token in BUGSNAG_DATA_TOKEN): open error groups from the last N days, with error class, message, controller#action, event count, users affected (count only), and first/last seen. No event metadata, request params, user emails, or URLs.
  • Scout APM (API key with read-only access): top endpoints by time consumed, p95, and allocations, plus memory-bloat endpoints (helps #7218).
  • Heroku (heroku logs / log drain): counts of platform error codes (H12, R14, H10…) and 5xx counts by dyno and hour. Router path= values are reduced to the route pattern (/casa_cases/:id).

Each script should:

  • Fail closed: if a field isn't on its allow-list, it isn't printed
  • Have a spec feeding a recorded API response with fake PII and asserting it's absent from the output
  • Be documented in doc/ with how to get the read-only token (maintainers only)

Stretch

  • Weekly scheduled run posting the summary to a pinned GitHub issue or Discord, replacing per-event Bugsnag pings with trends
  • Then disable Discord embeds for Bugsnag (#5390)
Lenguaje dominante
Ruby
Estrellas
382
Forks
547
Merge medio
2 d 22 h
PR fusionados (30 d)
46

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

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 rubyforgood/casa

Todos los issues de rubyforgood/casa

Issues similares

Más issues de Ruby

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.