---
title: Apache HTTP server (HTTPD) metrics
slug: telemetry-pipeline/apache-http-server-httpd-metrics
docTags: 
createdAt: 2025-04-21T00:48:57.057Z
---

## Apache HTTP Server (HTTPD) Metrics Source

The Apache HTTP Server metrics source collects **runtime and performance metrics** from an Apache HTTPD instance by scraping the **mod\_status** endpoint. It enables visibility into request handling, worker utilization, and server health without requiring additional instrumentation.

This source is suitable for both **daemon** and **sidecar** deployment models and is commonly used in on-premise, VM-based, and containerized Apache deployments.

## Prerequisites

### Apache mod\_status

The Apache **mod\_status** module must be enabled and accessible.

Operational requirements:

- mod\_status loaded in Apache configuration 
- server-status endpoint enabled 
- Access allowed from the metrics collector 
- Output format must support the ?auto parameter 

Without mod\_status, no metrics can be collected.

## Collection Model

- Pull-based metric collection 
- Periodic scraping of HTTP endpoints 
- Stateless operation with no local persistence 
- One scrape cycle produces one batch of metrics 

Each configured endpoint is scraped independently.

## Endpoint Configuration

### endpoints (required, \[string])

Defines the list of Apache **mod\_status** endpoints to scrape metrics from.

Key points:

- Each entry must point to a valid server-status endpoint 
- Multiple endpoints can be configured to monitor multiple Apache instances 
- Endpoints must return metrics in a machine-readable format 

**Operational note:**
 Ensure network access and authentication rules allow the collector to reach the endpoint.

## Metric Namespacing

### namespace (optional, string)

Specifies the namespace under which Apache metrics are emitted.

When enabled:

- All metrics are prefixed with the configured namespace 
- Metric naming collisions are avoided 
- Downstream routing and filtering becomes easier 

If empty, namespacing is disabled.

## Proxy Configuration

### proxy (optional, object)

Controls how HTTP requests to Apache endpoints are routed through a proxy.

This is useful in environments where:

- Direct access to Apache servers is restricted 
- Traffic must traverse controlled egress points 
- Centralized network policies are enforced 

proxy.enabled (optional, bool)

Enables or disables proxy support globally for this source.

proxy.http (optional, string)

Proxy endpoint used for HTTP traffic.

Must be a valid URI.

proxy.https (optional, string)

Proxy endpoint used for HTTPS traffic.

Must be a valid URI.

proxy.no\_proxy (optional, \[string])

Defines hosts or networks that should bypass the proxy.

Supported patterns include:

- Exact domain names 
- Wildcard domains 
- IP addresses 
- CIDR ranges 
- Global wildcard 

## Scrape Interval

### scrape\_interval\_secs (optional, uint)

Controls how frequently Apache metrics are collected.

Considerations:

- Short intervals increase metric resolution 
- Longer intervals reduce load on the Apache server 
- Interval applies to all configured endpoints uniformly 

## Metrics Scope

The source exposes metrics related to:

- Request throughput 
- Worker and thread utilization 
- Connection states 
- Server uptime and load 
- Scoreboard status 

Metrics are derived directly from the Apache server-status output.

## Reliability and Delivery Semantics

- Metrics are delivered with **at-least-once semantics** 
- Duplicate samples may occur during retries 
- No acknowledgement tracking at the source level 
- Downstream systems should handle potential duplication gracefully 

## Security Considerations

- The server-status endpoint should not be publicly exposed 
- Access should be restricted by IP or authentication 
- Proxy settings can be used to enforce controlled access paths 
- HTTPS endpoints are recommended in production environments 

## Common Use Cases

- Apache performance monitoring 
- Capacity and load analysis 
- SLA and availability tracking 
- Integration with Prometheus-compatible backends 
- Sidecar-based observability in containerized Apache setups