clamav-prometheus-exporter-fips

packaged by Chainguard

Chainguard Container for clamav-prometheus-exporter-fips

The clamav-prometheus-exporter-fips image scrapes a ClamAV daemon over clamd's native protocol and exposes the results as Prometheus metrics on port 9810, built against a FIPS-validated cryptographic module.

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/clamav-prometheus-exporter-fips:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Compatibility Notes

The clamav-prometheus-exporter-fips image is comparable to the upstream rekzi/clamav-prometheus-exporter image published from the upstream project, and is designed to be a drop-in replacement for it. The flags, the metrics it exports, and the 9810 listener are identical to the non-FIPS clamav-prometheus-exporter image. Two differences from upstream are worth noting:

• The binary is installed at /usr/bin/clamav-prometheus-exporter rather than /bin/clamav-prometheus-exporter. /bin is a symlink to /usr/bin, so upstream's path resolves to the same binary and overriding the entrypoint with either absolute path works.
• The container runs as UID 65532 (nonroot) instead of UID 1000. The exporter needs no writable paths, so this does not require any changes.

This image contains only the exporter and its runtime dependencies; it does not include a shell or a package manager.

FIPS Support

The clamav-prometheus-exporter-fips Chainguard Container ships with a validated redistribution of OpenSSL's FIPS provider module. For more on FIPS support in Chainguard Containers, consult the guide on FIPS-enabled Chainguard Containers on Chainguard Academy.

The hardened OpenSSL configuration the image ships keeps that provider primary, but it is not a hard startup requirement. If the OpenSSL FIPS provider fails to load, the Go toolchain this binary is built with falls back to its own embedded FIPS module and keeps running rather than aborting. That fallback is still FIPS-mode crypto, but it is not the OpenSSL module, so a clean startup on its own does not tell you which one is in use. Ask the runtime directly:

docker run --rm -e GODEBUG=cgr_verbose=1 \
  cgr.dev/ORGANIZATION/clamav-prometheus-exporter-fips:latest -h 2>&1 | head -1

cgr_fips: openssl

cgr_verbose=1 makes the runtime name the module it selected before main runs; -h simply gives it something that exits once the line has been printed. Exactly cgr_fips: openssl is the passing result. A fallback names itself instead, and reports why:

cgr_fips: openssl attempted, fallback to geomys: FIPS mode requested (environment variable GODEBUG=fips140=on) but not available: OpenSSL 3.6.4 25 Aug 2026

Prerequisites

The exporter has no state of its own — it scrapes a running ClamAV daemon and re-publishes what it finds. You will need:

• A reachable clamd instance, either over TCP or over a Unix socket shared with the exporter. Chainguard publishes a FIPS clamav image for this at cgr.dev/ORGANIZATION/clamav-fips.
• A Prometheus instance, or any other scraper, configured against the exporter's /metrics endpoint.

Refer to the upstream project for the full list of exported series.

Getting Started

The exporter always serves /metrics on port 9810. It has nothing to report without a clamd to scrape, so put both on the same Docker network and address clamd by container name:

docker network create clamav-demo

docker run -d --name clamd --network clamav-demo \
  cgr.dev/ORGANIZATION/clamav-fips:latest

docker run -d --name clamav-exporter --network clamav-demo -p 9810:9810 \
  cgr.dev/ORGANIZATION/clamav-prometheus-exporter-fips:latest \
  -clamav-address=clamd -clamav-port=3310 -network=tcp

clamd loads its signature database before it accepts connections, which takes up to a minute on a first start. The exporter comes up immediately either way, so poll it rather than guessing:

until curl -s http://localhost:9810/metrics | grep -q '^clamav_up 1$'; do sleep 5; done

Scraping the endpoint then returns the ClamAV series alongside the standard Go collector series:

curl -s http://localhost:9810/metrics | grep '^clamav_'

clamav_build_info{clamav_version="1.5.4",database_version="28110"} 1
clamav_database_age 44602.488502835
clamav_mem_heap_bytes 36379.648
clamav_mem_mmap_bytes 0
clamav_mem_used_bytes 3512.32
clamav_pools_total_bytes 995018.752
clamav_pools_used_bytes 994984.96
clamav_queue_length 0
clamav_threads_idle 0
clamav_threads_live 1
clamav_threads_max 10
clamav_up 1

Tear the example down with docker rm -f clamav-exporter clamd && docker network rm clamav-demo.

While clamd is unreachable the exporter keeps serving /metrics rather than failing the scrape, so an outage shows up as a metric rather than as a dead endpoint. Only clamav_up 0 is left, though: every other series above is derived from clamd's own STATS and VERSION replies, so they disappear until it comes back.

The most common deployment is a sidecar next to clamd, where the two containers reach each other over the pod's loopback interface:

cat > exporter.yaml <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: clamav
spec:
  replicas: 1
  selector:
    matchLabels:
      app: clamav
  template:
    metadata:
      labels:
        app: clamav
    spec:
      containers:
        - name: clamd
          image: cgr.dev/ORGANIZATION/clamav-fips:latest
          ports:
            - containerPort: 3310
        - name: exporter
          image: cgr.dev/ORGANIZATION/clamav-prometheus-exporter-fips:latest
          args:
            - "-clamav-address=127.0.0.1"
            - "-clamav-port=3310"
            - "-network=tcp"
          ports:
            - containerPort: 9810
          readinessProbe:
            httpGet:
              path: /metrics
              port: 9810
EOF
kubectl apply -f exporter.yaml

Configuration

The exporter is configured entirely through command-line flags; there is no configuration file and no environment-variable interface:

When clamd and the exporter share a volume, prefer the Unix socket: it keeps the ClamAV control protocol off the network entirely, which matters because clamd has no authentication of its own. Note that -clamav-address then carries the socket path, and -clamav-port is unused:

docker run --rm -p 9810:9810 -v clamav-run:/run/clamav \
  cgr.dev/ORGANIZATION/clamav-prometheus-exporter-fips:latest \
  -clamav-address=/run/clamav/clamd.sock -network=unix

Raising the log level to debug does not echo the clamd exchange. What it adds is how the exporter parsed each reply: the regex match list for the STATS and VERSION responses, plus the value it took from each field. Run it against the clamd from Getting Started above:

docker run --rm --network clamav-demo \
  cgr.dev/ORGANIZATION/clamav-prometheus-exporter-fips:latest \
  -clamav-address=clamd -log-level=debug

{"level":"debug","msg":"Matches Threads[[THREADS: live 1 1] [idle 0 0] [max 10 10] [idle-timeout 30 30]]","time":"..."}
{"level":"debug","msg":"threadsLive: 1","time":"..."}

That makes debug useful for one thing specifically: telling a clamd whose reply the exporter could not parse (an empty match list, and the corresponding series missing from /metrics) from one it parsed cleanly. It is not the way to diagnose a connection problem — an unreachable clamd is logged at error level, so it is already visible at the default info level.

One upstream quirk to be aware of while reading that output: the memHeap, memMmap and memUsed debug lines are each labelled one MEMSTATS field off from the number they print, so memHeap shows the mmap figure, and so on. The exported clamav_mem_*_bytes series are correct; only these three debug labels are misleading.

Documentation and Resources

• Upstream project documentation
• ClamAV documentation
• FIPS-enabled Chainguard Containers

What are Chainguard Containers?

Chainguard's free tier of Starter container images are built with Wolfi, our minimal Linux undistro.

All other Chainguard Containers are built with Chainguard OS, Chainguard's minimal Linux operating system designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a development, or -dev, variant.

In all other cases, including Chainguard Containers tagged as :latest or with a specific version number, the container images include only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager.

Although the -dev container image variants have similar security features as their more minimal versions, they include additional software that is typically not necessary in production environments. We recommend using multi-stage builds to copy artifacts from the -dev variant into a more minimal production image.

Need additional packages?

To improve security, Chainguard Containers include only essential dependencies. Need more packages? Chainguard customers can use Custom Assembly to add packages, either through the Console, chainctl, or API.

To use Custom Assembly in the Chainguard Console: navigate to the image you'd like to customize in your Organization's list of images, and click on the Customize image button at the top of the page.

Learn More

Refer to our Chainguard Containers documentation on Chainguard Academy. Chainguard also offers VMs and Libraries — contact us for access.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.