HTTP đź”—
Description đź”—
The Splunk Distribution of OpenTelemetry Collector provides this integration as the http
monitor for the Smart Agent Receiver.
Use this integration to generate metrics based on whether the HTTP response from the configured URL matches expectations. For example, correct body, status code, and so on.
If applicable, TLS information is automatically fetched from the base URL or redirection, depending on whether the useHTTPS
parameter is configured.
Benefits đź”—
After you configure the integration, you can access these features:
View metrics. You can create your own custom dashboards, and most monitors provide built-in dashboards as well. For information about dashboards, see View dashboards in Observability Cloud.
View a data-driven visualization of the physical servers, virtual machines, AWS instances, and other resources in your environment that are visible to Infrastructure Monitoring. For information about navigators, see Splunk Infrastructure Monitoring navigators.
Access the Metric Finder and search for metrics sent by the monitor. For information, see Use the Metric Finder.
Installation đź”—
Follow these steps to deploy this integration:
Deploy the Splunk Distribution of OpenTelemetry Collector to your host or container platform:
Configure the monitor, as described in the Configuration section.
Restart the Splunk Distribution of OpenTelemetry Collector.
Configuration đź”—
To use this Smart Agent monitor with the Collector, include the smartagent
receiver and service pipeline in your configuration file. The Smart Agent receiver is fully supported only on x86_64/amd64 platforms.
Read more in Use Smart Agent monitors with the Collector.
Learn about config options in Collector default configuration.
See the examples below for more details.
receivers:
smartagent/http:
type: http
... # Additional config
To complete the integration, include the monitor in a metrics pipeline. Add the monitor item to the service/pipelines/metrics/receivers
section of your configuration file. For example:
service:
pipelines:
metrics:
receivers: [smartagent/http]
Configuration options đź”—
The following table shows the configuration options for this monitor:
Option |
Required |
Type |
Description |
---|---|---|---|
|
no |
|
The host or IP address to monitor. |
|
no |
|
The port of the HTTP server to monitor. The default value is |
|
no |
|
The HTTP path to use in the test request. |
|
no |
|
The HTTP timeout duration for both read and writes. This should be a duration string that is accepted by the |
|
no |
|
The basic auth username to use on each request, if any. |
|
no |
|
The basic auth password to use on each request, if any. |
|
no |
|
If |
|
no |
|
A map of HTTP header names to values. Comma-separated multiple values for the same message-header are supported. |
|
no |
|
If |
|
no |
|
If |
|
no |
|
The path to the CA certificate that has signed the TLS cert. This option is unnecessary if |
|
no |
|
The path to the client TLS cert to use for TLS required connections. |
|
no |
|
The path to the client TLS key to use for TLS required connections. |
|
no |
|
Optional HTTP request body as string, for example, |
|
no |
|
Do not follow redirect. The default value is |
|
no |
|
HTTP request method to use. The default value is |
|
no |
|
Provides a list of HTTP URLs to monitor. This option is deprecated. Use |
|
no |
|
Optional regex to match on URL(s) response(s). |
|
no |
|
Desired code to match for URL(s) response(s). The default value is |
|
no |
|
Adds the |
Setup đź”—
To create a webcheck from a URL, split the URL into different configuration options. All of these options determine the URL dimension value from its “normalized” URL, which is in the format of {scheme}://{host}:{port}{path}
:
scheme
ishttps
ifuseHTTPS:true
, orhttp
ifuseHTTPS:false
.host
is the host name of the site to check. This option is required.port
is the port to connect to. If not defined,port
is443
ifuseHTTPS:true
or80
ifuseHTTPS:false
. The default value forhttp
is80
. If the default value is used,port
is removed from the configuration because it is implicit and makes the behavior similar to whatcurl
does.path
contains the full query including the resource path and finally theGET
method parameters with?
separator.
Configure the following options to change the behavior of the request done on this URL:
Configure the
method
option to define request types such asGET
orPOST
. See https://golang.org/src/net/http/method.go for the full list of available methods.Configure the
username
andpassword
options for basic authentication.Configure the
httpHeaders
option to define request headers. Use this option to override thehost
header.Configure the
requestBody
option to provide a body to the request. The form of this body depends on theContent-Type
header. For example,{"foo":"bar"}
withContent-Type: application/json
.Configure the
noRedirects:false
option to stop the URL from following redirects. The default value istrue
.
See configuration examples for different request behaviors.
The following configuration options change the resulting values:
The
desiredCode
option determines thehttp.code_matched
value. Configure this option if you expect a different “normal” value. The default value is200
. For example, configuredesiredCode:301
andnoRedirects:false
to check a redirect (and not the end redirected URL) keeping the value to1
(success).The
regex
option does the same with thehttp.regex_matched
metric, where the value is1
only if the provided regex matches the response body.The
addRedirectURL
option does not have impact on metrics, but adds a new dimensionredirect_url
with a “dynamic” value. If theurl
dimension changes with the monitor configuration, theredirect_url
value is impacted by any server change and is always the last URL redirected. This option is deactivated by default because this could cause issues with heartbeat detectors, for example.
The following HTTP headers let the client and the server pass additional information with an HTTP request or response:
Cache-Control: no-cache
to send the request to the origin server for validation before releasing a cached copy.Host
to change the request, that is, to bypass CDN or load balancer requesting directly the back end.Content-Type
to indicate the media type of the resource. For example,json
,xml
, oroctet-stream
.
Examples đź”—
This section provides curl
commands with their corresponding configuration.
If the server reports that the requested page has moved to a different location, run curl -L http://signalfx.com
to make curl redo the request on the new URL. The http.status_code=200
status response code indicates that the request has succeeded because it does follow the redirect to Splunk.
monitors:
- type: http
host: signalfx.com
Run curl -I http://signalfx.com
to include the HTTP response headers in the output instead of the GET request. The HTTP response headers can include information such as server name, cookies, date of the document, and HTTP version. In this example, noRedirects:
is set to true
. The http.status_code=301
status response code means the request does not follow the redirect to Splunk.
monitors:
- type: http
host: signalfx.com
noRedirects: true
method: HEAD
Run curl -L -H 'Host: foobar' -A 'customAgent' https://signalfx.com
to include extra headers in the request when sending HTTP to a server. The -H
option removes an internal header by giving a replacement without content on the right side of the colon. The -A
option specifies the User-Agent
string to send to the HTTP server. The http.cert_valid=0
status response code means that the host does not match the certificate.
monitors:
- type: http
host: signalfx.com
useHTTPS: true
httpHeaders:
Host: foobar
User-Agent: customAgent
Run curl -G -X GET -d 'foo=bar' -d 'leet=1337' http://signalfx.com/fakepage
to make all data specified with -d
, --data
, --data-binary
, or --data-urlencode
to be used in an HTTP GET
request instead of the POST request
that otherwise would be used:
monitors:
- type: http
host: signalfx.com
path: '/fakepage?foo=bar&leet=1337'
method: GET
httpHeaders:
Content-Type: application/x-www-form-urlencoded
Run curl -X POST -d '{"foo":"bar"}' http://signalfx.com
to specify a custom request method to use when communicating with the HTTP server. The specified request method, POST
, is used instead of the default GET
method.
monitors:
- type: http
host: signalfx.com
method: POST
requestBody: '{"foo":"bar"}'
Run curl --resolve signalfx.com:443:127.0.0.1 https://signalfx.com
to provide a custom address for a specific host and port pair:
monitors:
- type: http
host: 127.0.0.1
port: 443
useHTTPS: true
sniServerName: signalfx.com
httpHeaders:
Host: signalfx.com
Metrics đź”—
These are the metrics available for this integration:
Get help đź”—
If you are not able to see your data in Splunk Observability Cloud, try these tips:
Submit a case in the Splunk Support Portal
Available to Splunk Observability Cloud customers
-
Available to Splunk Observability Cloud customers
Ask a question and get answers through community support at Splunk Answers
Available to Splunk Observability Cloud customers and free trial users
Join the Splunk #observability user group Slack channel to communicate with customers, partners, and Splunk employees worldwide
Available to Splunk Observability Cloud customers and free trial users
To learn how to join, see Get Started with Splunk Community - Chat groups
To learn about even more support options, see Splunk Customer Success.