Add a metrics endpoint

[beetlebugorg]

What

A dims-metrics handler serves Prometheus text 0.0.4 at a location that sets it. DimsMetricsEnabled is the switch and defaults to Off.

src/metrics.c holds a shared memory block that every worker adds to with 64-bit atomics, sized once in post config from AP_MPMQ_HARD_LIMIT_DAEMONS. src/metrics_report.c walks it and writes the exposition. dims_handler registers a pool cleanup per request, so every return path records once.

The endpoint reports 27 families:

Group	Families
Request path	dims_requests_total{endpoint,outcome}, dims_responses_total{endpoint,code}, dims_requests_in_flight{endpoint}, dims_request_duration_seconds{endpoint}
Source	dims_source_fetch_duration_seconds, dims_source_bytes, dims_source_bytes_total, dims_source_format_total{format}, dims_origin_responses_total{code}
Processing	dims_imagemagick_duration_seconds, dims_source_frames, dims_output_bytes, dims_output_bytes_total, dims_output_format_total{format}
ImageMagick and memory	dims_imagemagick_resource_bytes{resource}, dims_imagemagick_resource_max_bytes{resource}, dims_imagemagick_resource_limit_bytes{resource}, dims_process_resident_bytes, dims_process_resident_max_bytes, dims_process_virtual_bytes, dims_workers
httpd	dims_httpd_workers{state}, dims_httpd_processes, dims_httpd_processes_limit, dims_httpd_threads_per_process, dims_httpd_connections{state}, dims_httpd_generation
Build	dims_start_time_seconds, dims_build_info

Counters and histograms come from the block. The ImageMagick resources and the process memory are per worker: each child writes its own slot when a request ends, and the endpoint sums the live slots and reports the widest one. The httpd families read the scoreboard at scrape time.

dims_stats_rec goes away, and dims_status_handler sums the requests table for the four numbers it prints.

The container serves images on 8000 and metrics on 8001, with DIMS_METRICS_ENABLED off.

Why

/dims-status/ prints four counters in prose. A Prometheus scrape of that page returns no series. The request record already holds the duration, the source size, the origin status, the frame count, and the output size, so the endpoint reports them without new measurement.

OTLP is push only. Its specification does not define a mode where a server exposes metrics for a collector to fetch. Scraping is the supported path into OpenTelemetry, and the compatibility specification states that the collector adds the resource attributes from the scrape target.

Folding dims_stats_rec into the block fixes two defects. dims_init set success_count to 1 at startup, so the endpoint reported one success before it served a request. The four increments sat in dims_send_image. A failure on a server with no error image returns before that function, so those requests went uncounted.

Port 8001 exists because Require ip reads the ingress controller address rather than the caller address. A second listener moves the decision to the network.

Verify

make -C test test
make -C test test-update
make -C test sanitize

305 cases pass, every golden file reproduces, and 114 sanitizer cases report no finding. test/http/test_metrics.c covers the format, each metric group, and the directive. test/unit/test_metrics.c covers the bucket search and the index maps. test/http/test_status.c asserts the two endpoints agree.

Against the built image:

docker run -d -p 8001:8001 -e DIMS_METRICS_ENABLED=on mod-dims:ci
curl http://127.0.0.1:8001/metrics

I measured 404 with the image defaults and 200 with the variable on. Port 8000 returns 404 for /metrics in both cases.

Breaking

/dims-status/ reports zero successes on a server before its first request, where it reported one. It also counts a failed request that returns no image, which it skipped before.