Using Prometheus exporters to monitor custom application metrics

Application logs explain what happened, while custom metrics show how often it happens and whether the service is approaching a limit. Prometheus exporters provide a practical bridge between an application, a database, or a piece of hardware and a time-series monitoring platform. They are especially useful when an off-the-shelf integration does not understand the business events that matter to your team.

For Australian operators, this approach fits environments ranging from a small workload in an AWS Sydney region to a hybrid platform spread across Melbourne offices, home NBN connections, and a local server room. A carefully designed exporter can expose useful signals without adding sensitive data, excessive network traffic, or an operational burden that grows with every deployment.

Choose the right exporter pattern

An exporter is usually a small HTTP service that presents metrics in Prometheus’s text format. Prometheus periodically scrapes an endpoint such as /metrics, parses the output, and stores each measurement with its labels and timestamp. The exporter may query a database, inspect a queue, call an application API, or read operating-system statistics.

There are three common designs. A dedicated exporter runs beside the application and translates internal state into metrics. Direct instrumentation adds a Prometheus client library to the application itself. A push gateway or intermediary can handle short-lived jobs, although it should not replace regular scraping for long-running services. Select the simplest pattern that preserves reliable ownership of the data.

For a PHP application deployed in containers, a separate sidecar or small service can be easier to operate than modifying every web worker. The deployment techniques in PHP applications with Docker are relevant here because the exporter, application, and monitoring configuration can be versioned together and tested through the same Compose workflow.

Design metrics around operational decisions

A useful metric answers a specific operational question. Counters suit events that increase over time, such as completed orders, failed jobs, authentication errors, and database queries. Gauges represent values that rise and fall, including queue depth, active sessions, disk utilisation, or the number of workers currently available. Histograms help measure request duration and payload sizes across meaningful buckets.

Names should be stable, descriptive, and consistent. A counter might be called orders_processed_total, while a histogram could be http_request_duration_seconds. Avoid embedding changing values in metric names. Put controlled dimensions in labels, such as method, route, status, or queue, but do not use customer IDs, email addresses, request IDs, or arbitrary URLs as labels.

High-cardinality labels can make a modest environment unexpectedly expensive. A route label containing every product path may create thousands of time series, increasing memory use in Prometheus and complicating dashboards. Australian businesses handling personal information should also treat labels as a potential privacy boundary under the Privacy Act and Australian Privacy Principles. Metrics should reveal system behaviour without becoming a secondary customer database.

Instrument application and infrastructure boundaries

Custom business metrics are most valuable when combined with technical signals. Track request rate, error rate, latency, queue age, worker availability, database connection failures, and dependency response time. A job-processing service might expose the number of jobs received, completed, retried, and permanently failed, along with the oldest item waiting in the queue.

Keep the exporter’s collection work predictable. A scrape should not trigger a full table scan, invoke a slow third-party API, or block while waiting for an unavailable dependency. Cache expensive measurements for a short interval, set timeouts, and expose an exporter health metric separately from the application’s business metrics. A successful scrape only proves that the endpoint responded; it does not prove that the application is healthy.

Test metric behaviour during deployments and failures. Confirm that counters remain monotonic across ordinary restarts, that missing data is distinguishable from a genuine zero, and that labels do not change unexpectedly. If a queue disappears because a connection failed, returning zero could hide the incident; returning an error or omitting the measurement is often safer.

Run collection securely and efficiently

Prometheus should reach exporters over a restricted network path. Bind an endpoint to a private interface, apply firewall rules, and avoid exposing /metrics through a public load balancer unless there is a strong reason. Metrics can disclose software versions, internal hostnames, customer activity, and infrastructure topology.

Protect the monitoring layer as carefully as the services it observes. Key-based administration and automated banning are covered in hardening SSH access, and the same disciplined approach applies to exporter hosts: minimise exposed ports, remove password logins where practical, patch regularly, and give collection accounts only the permissions they need.

Choose scrape intervals according to the signal’s value. A five-second interval is sensible for a rapidly filling queue, but wasteful for a weekly storage report. In Australia, a Sydney-based Prometheus server scraping an application hosted in Perth or Singapore also has to account for latency and link reliability. Regional federation or local collection can reduce cross-region traffic and make outages easier to interpret.

Build alerts that support action

Alert rules should describe a condition that someone can investigate and resolve. High request latency, a growing queue, an exporter that has stopped responding, or a sustained rise in failed transactions are stronger alerts than every individual warning log. Use a for duration to prevent brief spikes from generating unnecessary pages.

Alert thresholds need context. A payment service may tolerate a short increase in latency during a scheduled batch, while a public booking platform may require rapid intervention. Alert on symptoms and trends, then attach useful labels such as service, environment, region, and severity. Include a runbook link or an explanation of the first diagnostic commands.

Dashboards should show traffic, saturation, errors, and latency together. Record rules can precompute expensive PromQL expressions for frequently viewed panels. When teams operate across AEST and AEDT, timestamps and maintenance windows should be explicit so a planned change in Brisbane is not mistaken for an unexplained overnight incident in Melbourne.

Storage deserves equal attention. Set a retention period based on investigation needs, estimate series growth before adding labels, and monitor Prometheus’s own disk usage. For workloads subject to contractual or regulatory retention requirements, document where metric data is stored and whether it leaves Australia. The same consideration applies when sending long-term data to a managed monitoring service.

Apply a practical monitoring baseline

Start with a small set of signals and expand only when they support a decision. A focused exporter is easier to review, secure, and keep compatible than a broad endpoint that exposes every internal variable. Review the metric catalogue during code changes and remove measurements that no longer drive a dashboard, alert, or capacity decision.

A home-lab or hardware project can benefit from the same approach. Storage temperatures, scan queue lengths, disk errors, and backup age are more useful than an unfiltered stream of sensor readings. When monitoring image-scanning equipment, understanding the difference between ICE and GEM helps separate a software feature from an actual hardware or workflow metric worth tracking.

Use this baseline when implementing a new exporter:

• Define the operational question before naming the metric.
• Prefer counters, gauges, and histograms according to their meaning.
• Keep labels bounded, stable, and free of personal information.
• Add timeouts, caching, authentication, and network restrictions.
• Test scrape failures, restarts, deployment changes, and dependency outages.
• Pair every important alert with an owner, threshold, and runbook.

Prometheus exporters work best as part of an operating practice rather than as isolated code. Store dashboards and alert rules in version control, review them with application changes, and test them in a staging environment. For teams supporting customers across Australian time zones, clear ownership and reliable escalation matter as much as the metric format itself.

Choose one service with a measurable queue, latency problem, or business workflow and expose a small, well-named metric set. Scrape it privately, create one actionable dashboard, and validate the alerts during a controlled test. That first feedback loop will provide the evidence needed to extend custom application monitoring across the rest of the platform.