OpenMetrics: expose per-engine successful and failed request counters

Is your feature request related to a problem?

The current OpenMetrics endpoint exports searxng_engines_request_count_total for sent requests, while SearXNG already keeps successful and error counters internally for every engine. These two counters are not exposed at /metrics, so Prometheus users cannot calculate an exact per-engine success rate for a time window.

searxng_engines_reliability_total is not a replacement: it is a computed, rounded percentage and can decrease. searxng_engines_result_count_total is also not a cumulative result count in the current implementation.

Describe the solution you'd like

Expose the existing internal counters in searx/metrics/__init__.py:openmetrics() as two OpenMetrics counters, using the existing engine_name label:

searxng_engines_successful_request_count_total{engine_name="..."}
searxng_engines_error_request_count_total{engine_name="..."}

Suggested help text:

The total amount of successful requests made to this engine
The total amount of failed requests made to this engine

This should not change the meaning of the existing sent-request, reliability, latency, or result-count metrics.

For the current search flow, an empty but valid engine response is successful. The error counter is incremented in EngineProcessor.handle_exception() and is independent of error-context recording, including secondary error contexts. Focused tests should document the intended relationship between sent, successful, and error requests, including any asynchronous exceptions.

With these counters, the window success rate can be calculated as:

100 *
sum by (engine_name) (
  increase(searxng_engines_successful_request_count_total[$__range])
)
/
clamp_min(
  sum by (engine_name) (
    increase(searxng_engines_request_count_total[$__range])
  ),
  1
)

The counters describe requests sent by SearXNG to upstream engines, not incoming /search requests. One incoming search can invoke multiple engines.

Describe alternatives you've considered

Using searxng_engines_reliability_total is not suitable because it is an approximate percentage rather than a monotonic counter. Using searxng_engines_result_count_total is not suitable because it currently represents a P50 result-count value rather than a cumulative count. Changing the shared OpenTelemetry Collector is also unnecessary because it already scrapes the complete /metrics response.

AI assistance disclosure

This issue is a close English translation of a human-authored Chinese requirements document. Codex was used only to translate and format that document; it did not introduce a separate feature proposal.

Code of Conduct

• I read the AI Policy and hereby confirm that this issue conforms with the policy.