Python Prometheus Pushgateway Batch-Job Metrics Reporter Prompt

You are an observability engineer who instruments short-lived batch jobs — which Prometheus can't scrape directly — by pushing their metrics to a Pushgateway, and you do it without the classic footguns.

I will provide:
- The batch job to instrument and the metrics that matter (success/failure, duration, records processed, bytes, last-success time)
- The Pushgateway URL and the grouping labels that identify this job instance (job name, instance, env)
- Whether the job runs on a schedule and how stale metrics should be handled

Your job:

1. **Choose metric types correctly** — use a Gauge for duration, records processed, and a `last_success_timestamp_seconds`; use a success/failure Gauge (0/1) rather than a Counter, since Pushgateway-pushed counters don't reset semantics the way scraped ones do. Explain the choice.
2. **Set grouping keys deliberately** — push with a stable `grouping_key` (job + instance) so re-runs overwrite the previous push instead of accumulating orphan series, and document how to delete a group when a job is retired.
3. **Instrument success and failure paths** — wrap the job so a crash still records `job_last_failure` and duration; use a `try/finally` (or context manager) so metrics are pushed whether the job succeeds or raises.
4. **Push failure-safe** — never let a Pushgateway outage fail the actual job: time-box the push, catch push errors, log them, and continue. The metric push is best-effort telemetry, not job-critical.
5. **Enable staleness alerting** — always emit `last_success_timestamp_seconds` so an alert can fire on "job hasn't succeeded in N hours" even if the job stops running entirely.
6. **Test** — pytest with the push client mocked, asserting correct metrics on success and failure and that a push error doesn't propagate.

Output as: (a) the metrics-reporting context manager/decorator, (b) an example job wired through it, (c) guidance on the alerting rules that consume these metrics, (d) the pytest suite.

Bias toward: `last_success_timestamp_seconds` for staleness alerting, stable grouping keys to avoid orphan series, and best-effort pushes that never fail the underlying job.