# Classifying Anomalies in HTTP Requests

Let's say you wish to route HTTP request logs to the appropriate location.

* Normal logs are stored in S3.
* Suspicious logs are classified and sent to the corresponding team for further analysis.
* Anomaly Types:

  1\. SQL Injection Attack

  2\. Unauthorized Access Attempt 

  3\. Server Configuration Error 

  4\. Server Overload due to High Traffic 

  5\. Unknown

<div data-full-width="false"><figure><img src="/files/RRYlDuFrIrNjT57CVBrB" alt=""><figcaption></figcaption></figure></div>

### Data collection and preparation

Set up the corresponding Listener to the logs collected from HTTP servers, capturing details such as request methods, URLs, status codes, timestamps, and user-agent strings.&#x20;

### Data restructuring

Using the **Parser** action, logs are pre-screened and parsed to identify unusual status codes that may indicate potential anomalies.

<figure><img src="/files/P7MrLrAZ5hYbCcVMhLRG" alt=""><figcaption></figcaption></figure>

### Filter your data

Using the **Conditional** action, logs are filtered based on unusual status codes or patterns in request URLs.

<figure><img src="/files/JvgnrXikNheG2MEfkT93" alt=""><figcaption></figcaption></figure>

### Integrate with replicate models

Use the **MLreplicate** action to filter logs meeting the criteria and send them to public Llama3 model via an API from replicate.com. The model processes the text within these logs to classify the type of anomaly.

<figure><img src="/files/B3CYuMoptiSrg8c6axp3" alt=""><figcaption></figcaption></figure>

Logs meeting the filtering criteria are sent to Llama2 via an API from replicate.com. The model processes the text within these logs to classify the type of anomaly.

Llama3 evaluates each log entry against known patterns and characteristics of the four main categories of anomalies. It assigns a category to each log and provides a rationale based on textual evidence found in the log details.<br>

<figure><img src="/files/rtrOYupGvpbALhI3KGan" alt=""><figcaption></figcaption></figure>

### Parser

Use the **Parser** action to provide the model output and restructure the data to make it a coherent message.

<figure><img src="/files/5vpAeaKsSYGcfJD6lcpC" alt=""><figcaption></figcaption></figure>

### Filter the model output

Use the **Conditional** action to filter the model output message.

<figure><img src="/files/TlYrQpIAOWVuRhiu37cR" alt=""><figcaption></figcaption></figure>

### Data sink

Now we want to redirect our data to Slack channels using the **Message builder** action and then the **Slack** data sink.

<figure><img src="/files/LPDQ6fNQdlOGzpNjdsec" alt=""><figcaption></figcaption></figure>

#### Input

```
<134>1 2024-04-16T17:20:25Z 192.168.1.179 webserver - - - GET /api/data HTTP/1.1 500 587 - Mozilla/5.0 (Linux; Android 9; Pixel 3 XL) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.92 Mobile Safari/537.36 - Internal server error - high number of concurrent requests resulted in a failure to process all incoming requests.
```

#### output

<figure><img src="/files/g7CjsPHBtdKkijkfod3w" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.onum.com/usecases/classifying-anomalies-in-http-requests.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.