The same problem I had

In my personal project, I have the same problem and I adopted this solution.

In CollectorRegistry, the class where you store your metrics, there's no method to get Collector object (Collector is the parent class of any metric like Counter, Gauge, Histogram, etc.).

The restricted_registry method creates a subset (a restricted registry) where you have the Metrics that have that name and labels. But "it's experimental", so be careful. It doesn't solve my (our) problem. Because if a metric has a label, you also have to specify its value, and sometimes you can't know it (for example, if you're counting how many https requests you've made):

def restricted_registry(self, names: Iterable[str]) -> "RestrictedRegistry":
    """Returns object that only collects some metrics.

    Returns an object which upon collect() will return
    only samples with the given names.

    Intended usage is:
        generate_latest(REGISTRY.restricted_registry(['a_timeseries']))

    Experimental."""
    names = set(names)
    return RestrictedRegistry(names, self)

So if you're coding a project, and not its tests, don't use it.

My solutions adopted

First solution (fast implementation)

The first is to store all your metrics inside a custom class (eg PrometheusMetrics) where you have a dictionary with all Metrics object, for example (return objects are custom for my case, if you want to use a parent class, writes Collector):

def register_new_metrics(self, metrics: list[Counter | Gauge | Histogram | Summary | Enum]):
    for metric in metrics:
        for metric_obj in metric.describe():
            # Register the new metric inside the registry
            self.get_registry().register(metric)
            # Add it to the dict
            self._metric[metric_obj.name] = metric

And you can invoke it in this way:

self.register_new_metrics([
            Counter(f'name', "documentation", ['label1','label2']),
            Histogram(f'name2', "documentation", ['label1', 'label2', 'label3'])
])

This way you can have a simple get('metric_name') method that returns a requested metric object. This solution doesn't cause any problems if you only create metrics once at the same time as you create a CollectorRegistry (e.g.).

But if you want to create metrics at runtime, don't use this solution. Because Prometheus uses a threading.Lock (doc) inside the CollectorRegistry class and uses it for a lot of operations.

Second solution (more logical than the first)

The second, in my opinion, is another more logical solution. You can create a subclass of CollectorRegistry and create your own method where you get metrics using the protected field self._names_to_collectors and lock the thread with self._lock. After that you can register your own subclass using "Custom Collectors" way (doc):

from prometheus_client import REGISTRY

REGISTRY.register(CustomRegistry())

class CustomRegistry(CollectorRegistry):
    # ...
    def get_metric(metric: str) -> Collector:
        with self._lock:
            self._names_to_collectors.get(metric)
    # ...

If anyone has a better solution, please write! I am also interested in this topic.

If the metric can have either 0 or 1 values, then the sum_over_time(metric[d]) calculates the number of 1 values on the specified lookbehind window d. For example, sum_over_time(up[1h]) returns the number of up samples with 1 value during the last hour. The number of 0 values then can be calculates as count_over_time(up[1h]) - sum_over_time(up[1h]).

If the metric can have other values than 0 and 1, then Prometheus doesn't provide functions for counting the number of samples with a particular value yet :(

There is another Prometheus-like system, which allows counting the number of raw samples with the given value on the specified lookback window - VictoriaMetrics (I'm the core developer of this system). It provides count_eq_over_time function for this task. For example, the following MetricsQL query returns the number of samples for some_metric time series with the value 42 over the last hour:

count_eq_over_time(some_metric[1h], 42)

I came up with two solutions to this, choose whichever suits you best. For the purpose of simplifying things, let's assume your Prometheus scrape at 15 seconds interval and the error state lasted for 1 minute. Then, the gathered data would look like this:

state_metric 0 @t
state_metric 1 @t+15s
state_metric 1 @t+30s
state_metric 1 @t+45s
state_metric 1 @t+60s
state_metric 0 @t+75s

With changes()

This shows how many state changes were there. It would return 1 for the exemplary data above and it only gives adequate results if the gauge in question can hold exactly two possible values (for example 1 and 0).

changes(state_metric[1d])/2

changes() shows how many times the metric value has changed during the interval, while division by 2 is to compensate the state change back to normal. This is the downside of this method, which makes it only usable for detecting quick changes of state. But you probably have an alert when the error state hangs for some time, so I think this shouldn't be really a problem.

With a subquery

This is more precisely what you asked:

the number of times when metrics were 1

But there is a catch: with the exemplary data above, the query below will return you 4:

sum_over_time(count(state_metric == 1)[1d:])

[1d:] means repeat that instant query (count(state_metric == 1)) for each data point during last 1d. This is precisely the number of times when state_metric was 1 and it can be useful, for example, to calculate the downtime (just multiply by the scrape interval). Unlike the first method, this can work with any number of possible states, since you can define what you need in the condition.

Just use count_over_time function. For example, the following query returns the number of raw samples over the last 2 minutes per each time series with the name instana_metrics:

count_over_time(instana_metrics[2m])

Note that Prometheus calculates the provided query independently per each point on the graph, e.g. each value on the graph shows the number of raw samples per each matching time series over 2 minutes lookbehind window ending at the given point.

If you need just a single value per each matching series over the selected time range in Grafana, then use the following instant query:

count_over_time(instana_metrics[$__range])

See these docs about $__range variable.

See these docs about instant query type in Grafana.