How to set up an HTTP-Tracer¶
In order to operate properly, the Kadiska Tester from which HTTP-Tracer tests are performed must be able to send HTTP(S) requests (port is configurable) to the HTTP-Tracer targets.
In case the target contains a domain name, the Tester must also have a valid DNS server present in its TCP/IP stack configuration.
Step 1: HTTP-Tracer creation¶
First, login to the Kadiska platform and click on the “Configuration” icon:
Click on the HTTP-Tracers menu:
In this HTTP-Tracers menu, you can see all existing HTTP-Tracers. Click on "Create" to create a new one:
Section 1: General¶
In the first section (General), you can configure:
|Name||Name of the target (optional). If not configured, the target URL will be used instead|
|Description||Description of the HTTP-Tracer (optional)|
|Method||HTTP method used to test the target. The supported methods are GET, POST, PUT, HEAD, DELETE, PATCH, OPTIONS, CONNECT and TRACE|
|Target URL||URL of the tested target. The URL can contain a domain name, an IPv4 or an IPv6 address. You can add a port in case the web service does not run on traditional ports like 443 (e.g. : https://www.kadiska.com:4545)|
Section 2: Request¶
In the second section (Request), you can configure:
|Probe Interval||Interval (in minutes) between consecutive tests (1, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, 60)|
|HTTP Redirect||By default, Kadiska follows HTTP redirections. When disabled, the HTTP-Tracer analysis stops at the first server. In case of redirections, the response code is then like 301,302,...|
|Headers||Optional headers can be added. For example, this can be useful when JWT bearers are used for authentication, when you explicitly expect specific response format, or to activate some CORS headers.|
|Resolution||IPv4 or IPv6 protocol used for the initial DNS resolution process (if the target contains a domain name). By default, this is set to automatic.|
Section 3: Response¶
In the third section (Response), you can configure:
|Expected Status||By default, Kadiska expects a status code between 200 and 299. You can specify any status code (range) according to your specific requirements|
Section 4: Advanced¶
In the last section (Advanced), you can configure:
|TLS security||By default, the HTTP-Tracer validates the server certificate. In case you want to test servers with embedded self-signed certificate, you may want to disable this option|
|User agent||By default, the user agent for each HTTP-Tracer test is like "Kadiska/version". Depending on potential constraints at the server level, you may change this. We provide prefilled user agents for Chrome Windows, Firefox Windows, Edge Windows and Safari MacOS|
|Max. redirect||Maximum number of redirections before aborting the test. This would generate an error. Please refer to the Availability section for more information|
|Timeout||Maximum number of seconds waiting for a server response before aborting the test and generating an error. Please refer to the Availability section for more information|
|Connect Timeout||Maximum number of seconds waiting for a server connection setup before aborting the test and generating an error. Please refer to the Availability section for more information|
An HTTP-Tracer can only contain one target.
Once the configuration is done, you can copy it as a cURL command (click on "Copy as cURL" button at the top of the configuration) in order to validate it through a command line on your PC.
Click on the "Create" button to finalize the HTTP-Tracer creation process. The HTTP-Tracer is now created but is not yet associated with any Tester.
Step 2: HTTP-Tracer activation¶
In order to associate the HTTP-Tracer with one or multiple Testers, click on "Assign Testers" (1). Select the Station(s) and/or the Fleet(s) you want to activate the HTTP-Tracer on (2). Finally, click on "Apply" to confirm your configuration.
That's it, your HTTP-Tracer is now active on the selected Tester(s).