When customers visit your website, a link that results in a "HTTP 404 - File not found" error message can be frustrating and might cause customers to leave your site without finding what they were searching for.
This walkthrough takes you through the steps of sending HTTP records to your recordstore, then drilling down on HTTP transaction metrics to discover the source of 404 errors and identify any missing resources on your web server.
- Familiarize yourself with the concepts in this walkthrough by reading the Records topic.
- You must have access to an ExtraHop system that is connected to a recordstore.
- Your user account must have full write privileges to create a trigger.
- Your ExtraHop system must have network data with web server traffic and HTTP records that are being written to the recordstore. If you do not have access to web server data, you can perform this walkthrough in the ExtraHop demo.
Before you can query for records, you must write a trigger to generate a record every time an HTTP response occurs on specified devices or networks.
|Note:||If you are performing this walkthrough in the ExtraHop demo, the trigger has already been created, and you can proceed to the Start a new query section.|
- Log in to the ExtraHop system through https://<extrahop-hostname-or-IP-address>.
- Click the System Settings icon and then click Triggers.
- On the Triggers page, click New.
- Type a name for the trigger in the Name field. For this walkthrough, type HTTP response.
- Select the Enable debug log checkbox to help you validate that the script is running correctly.
- Click in the Events field and select HTTP_RESPONSE.
- Click the Editor tab.
In the Trigger Script editor, type the following code:
HTTP.commitRecord() debug ("committing HTTP record")
HTTP.commitRecord() is the method of generating the HTTP records, and "committing HTTP record" is the text string that is written in the debug log when the trigger successfully commits the record.
- Click Save and Close.
Next, you will assign the trigger to a web server on your network that you want to collect HTTP records for.
- At the top of the page, click Assets.
- In the left pane, click Devices.
- From the filter drop-down menu, click Any Field, and then select Type.
Click in the filter field and select Activity: HTTP
Server from the drop-down menu, as shown in the following
- Select the checkbox next to one of your HTTP servers in the list.
In the top right corner of the page, click Assign
Trigger, as shown in the following figure.
- In the Assign Triggers dialog box, select the checkbox next to the trigger you created and then click OK.
- Verify that the trigger is assigned to the web server by returning to the Triggers page in System Settings, clicking your trigger, and then clicking the Assignments tab. The web server should be listed in the Assignments section.
Next, verify that your trigger is generating HTTP records by clicking the
Debug Log tab. If the trigger is working correctly,
you should see a committing HTTP record entry similar to the
Now, you will create a new query to view all of the HTTP data received in the last 24 hours.
- Click on the Global Time Selector, select Last day and then click Save.
The query results for all records appear in the content pane.
Next, filter the results of your query to only display the metrics related to HTTP records.
Refine the results further to get a clearer picture of which server is supposed to store the requested resource, the client that is requesting the resource, and finally the path to where the resource should be located.
- Click 404 in the Status Code section in the left pane.
From the Group By drop-down list in the left pane, select
URI. You now have a list of URIs that are returning
404 errors. In the figure below, the
appears to be problematic, recording over 4,500 errors.
Click the URI with the highest count of 404 errors and then click the equals
sign (=) to add the URI as a filter.
Find the client or clients that are making the
request for that URI. From the Group By drop-down list,
select Client IPv4 Address. From this result, you can see
that only one client is requesting this URI that is returning a 404 status