> For the complete documentation index, see [llms.txt](https://fredhopper.gitbook.io/product-discovery/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://fredhopper.gitbook.io/product-discovery/building-the-front-end-experience-with-fhr/best-practice/traffic-monitoring-best-practice.md).

# Traffic Monitoring Best Practice

Follow these best practices guidelines for monitoring traffic to diagnose and prevent issues.

### Why you should monitor Traffic

It's always best practice to have logging and monitoring on your systems, and this extends to the traffic between your site and Fredhopper.

This gives you an understanding of your traffic, the ability to detect and handle anomalies, and if there is an issue, data to diagnose the problem.

The following is some best practice of what to monitor, and what to look for.

### What to Monitor

| Metric / Data Point                           | Why it Matters                                        |
| --------------------------------------------- | ----------------------------------------------------- |
| **Query Volume (per endpoint)**               | Helps track overall usage and detect surges           |
| **Round-Trip Time (RTT)**                     | Identifies latency issues or back-end slowness        |
| **Status Codes** (2xx/4xx/5xx)                | Reveals malformed queries, outages, or timeouts       |
| **Unique IP/User-Agent count**                | Identifies spikes in new or bot-like clients          |
| **Query Parameters (e.g.** `fh_location`**)** | Detects abusive patterns (e.g., brute-force faceting) |
| **Rate per user/session/token**               | Helps enforce throttling and usage fairness           |
| **Cache hit/miss ratio**                      | Indicates inefficiencies in caching strategy          |

### How to Implement It <a href="#how-to-implement-it" id="how-to-implement-it"></a>

#### Structured Logging

In your middleware or proxy service:

* Log all FHR-bound requests with:
  * Timestamp
  * User/session ID (if available)
  * Client IP and User-Agent
  * FHR endpoint and query parameters
  * FHR response status and time
* Prefer **JSON-formatted logs** for easy parsing in log aggregators

Example:

{% code overflow="wrap" %}

```
{ "timestamp": "2025-07-22T13:00:12Z", "userId": "user-123", "ip": "192.0.2.45", "userAgent": "Mozilla/5.0", "fh_endpoint": "/fredhopper/query", "fh_location": "//catalog01/en_GB/brand=adidas", "status": 200,"rtt_ms": 128 }
```

{% endcode %}

#### Performance Metrics

Use an APM tool (e.g. Grafana) to track:

* Average/median/max round-trip times
* Request rate per minute/hour
* Cache efficiency
* Error rate

Set alerts for:

* RTT > 500ms (indicates FHR or network issues)
* 4xx/5xx status rate spikes
* Unusual request rates from specific IPs or tokens

#### Correlation by Page Type

Monitor FHR usage broken down by page context:

* Category (PLP)
* Product detail (PDP)
* Search results
* Suggest/autocomplete

Look for out-of-pattern traffic, such as:

* Excessive hits to Suggest API
* PDPs requesting unusual or irrelevant `fh_location` paths
* Non-search pages generating `fh_search` queries

### Irregular Traffic Patterns

Watch out for the following irregular traffic patterns:

| Pattern                                              | Possible Cause                                 |
| ---------------------------------------------------- | ---------------------------------------------- |
| Sudden spike in RTT                                  | Back-end issues, query complexity, or bot load |
| High 400s/500s rate                                  | Malformed queries, missing fallback logic      |
| Repeated suggest queries with random strings         | Automated bots brute-forcing autocomplete      |
| Uncached repeat queries with minor parameter changes | Bot or misconfigured client with no caching    |
| High volume from single IP or unknown UA             | Malicious bot or unmonitored integration       |