Apache web server 🔗
The Splunk OpenTelemetry Collector provides this integration as the Apache web server monitor with the SignalFx Smart Agent receiver. The integration monitors Apache web servers using information
To see the monitor source, view the signalfx-agent project on GitHub.
Apache worker threads can be in one of the following states:
|Open||Open (unused) slot - no process|
|Waiting||Idle and waiting for request|
|KeepAlive||Kept alive for possible next request|
|Idle_cleanup||Idle and marked for cleanup|
|Logging||Writing to log file|
|Finishing||Finishing as part of graceful shutdown|
|Starting||Starting up to serve|
Note: Providing an Apache web server monitor entry in your Smart Agent or Collector configuration is required for its use. Use the appropriate form for your agent type.
Follow these steps to deploy the integration:
Splunk OpenTelemetry Collector configuration 🔗
The Splunk Distribution of OpenTelemetry Collector allows embedding a Smart Agent monitor configuration in an associated Smart Agent Receiver instance.
After you deploy the Splunk OpenTelemetry Collector, follow these steps to activate the monitor in the Splunk OpenTelemetry Collector:
Add the following monitor to your agent configuration:
monitors: # All monitor config goes under this key - type: collectd/apache ... # Additional config
Restart the Splunk OpenTelemetry Collector.
See configuration examples for specific use cases that show how the collector can integrate and complement existing environments.
The following configuration options are available for this monitor:
||The hostname of the Apache server|
||The port number of the Apache server|
||This will be sent as the
||The URL, either a final URL or a Go template that will be populated with the host and port values. (default:
Apache configuration 🔗
After you deploy the monitor in the Splunk OpenTelemetry Collector, follow these steps to configure the Apache web server to expose status metrics:
mod_statusmodule in your Apache server. Make sure that the URL you provide for your
mod_statusmodule ends in
?auto. This returns the status page as
text/plain, which the monitor requires.
Add the following configuration to your Apache server:
ExtendedStatus on <Location /mod_status> SetHandler server-status </Location>
Restart the Apache web server.
These metrics are available for this integration.
Metrics that are categorized as container/host (default) are in bold and italics in the list below.
Amount of data served by Apache, in bytes.
The number of connections that are being served by Apache. This is also equal to the number of busy worker threads, where ‘busy’ means any worker thread which has been started successfully and is not slated for idle cleanup.
The number of Apache workers that are idling. If this number is consistently low, then your server may be too busy and you may have to increase the number of threads. If it is consistently high, then the system may be under-utilized.
The number of requests that have been served by Apache. This metric is useful to know total requests and the rate at which Apache is able to serve them.
This metric shows how many worker threads are in the process of closing TCP connections after serving a response. If this number is consistently high, then there might be a network issue or errant client preventing TCP tear-down.
This metric counts the number of worker threads that are performing a DNS lookup. If this number is too high, check if there is a DNS resolution problem at your server. This can affect Apache server performance.
The number of worker threads that are finishing as part of graceful server shutdown.
The number of worker threads that are idle and ready for clean-up.
The number of worker threads that are maintaining keep-alive connections: keeping the connection “alive” after serving a response, in the expectation that another HTTP request will come on the same connection. At the end of the keep-alive interval, the connection is closed.
This metric shows how many worker threads are busy writing to the log file. If this number is consistently high, your logging level may be too high or one or more modules may be too verbose.
This metric shows how many worker slots are open. The slots do not have a worker thread yet, but they can be spun up based on incoming requests.
This metric shows how many workers are in the process of receiving requests (headers or body). If this number is consistently high, clients may be sending large headers or uploading large files.
This metric shows how many workers are sending responses. It is normal for this to be a large number when measuring sites that serve large downloads.
This metric shows how many workers are being started up. If this number is consistently high, then the system may be overloaded.
This metric shows how many worker threads are ready and waiting for requests to come in.
Non-default metrics (version 4.7.0+) 🔗
To emit metrics that are not default, you can add those metrics in the
extraMetrics config option. Metrics that are derived
from specific configuration options that do not appear in the above list of
metrics do not need to be added to
To see a list of metrics that will be emitted you can run
agent-status monitors after configuring this monitor in a running agent instance.
The following dimensions may occur on metrics emitted by this monitor. Some dimensions may be specific to certain metrics.
||Set to whatever you set in the