delta will fail when your counter will be reset (when it will start counting from 0 again), while increase/rate will detect that and adjust result accordingly. So with:

t0: 5
t1: 11
t2: 28
t3: 4
t4: 40

with delta you'll probably get 40 - 5 = 35, while increase will probably calculate something similar to (28-5)+40 = 63

If you know the interval between samples (e.g. one minute in the example above), then the following subquery can be used:

delta(http_requests[1m])[5m:1m]

This instant query should return the last 5 deltas on 1-minute interval. Unfortunately, it is likely Prometheus will return empty results, since it needs at least two samples on the lookbehind window in square brackets for delta calculations, e.g. it doesn't take into account the difference between the last point before the lookbehind window and the first point in the lookbehind window. So the query must be rewritten to:

delta(http_requests[2m])[5m:1m]

Unfortumatele this query may give unexpected results because of the same issue - Prometheus skips the delta between the last sample before the lookbehind window and the first sample in the lookbehind window [2m].

P.S. An alternative solution is to try the first query in VictoriaMetrics. It takes into account the delta mentioned above, so it must return the expected results. See more details at MetricsQL docs. Take a look also at rollup_delta function - it calculates deltas between consecutive samples on the given lookbehind window and then returns max, min and avg values from the calculated deltas.

I found offset is the correct keyword.

Query like this:

sum(vss_device_number) - sum(vss_device_number offset 1d)

Will return difference between now and yesterday.

Docs.

You need to create rule for pre-filtering of metric_name

prometheus.yml

...
rule_files:
  - my_rules.yml
...

my_rules.yml

groups:
- name: my_filters
  rules:
  - record: metric_name_filtered
    expr: metric_name != 0
 

This will drop fake zero-values.

PromQL will be: delta(metric_name_filtered[1d])

If you need to fill-up dropped metrics, you could create one more rule:

  - record: metric_name_filtered_and_restored
    expr: last_over_time(metric_name_filtered[1h])

See also the best practices for naming metrics created by recording rules