Forum Discussion

rschwarz79's avatar
rschwarz79
Icon for Nimbostratus rankNimbostratus
Jul 11, 2024

LTM log suppressing messages

Hello F5 users,

 

I've a question/issue on F5 logging HTTP requests to LTM log. Maybe someone can explain it ;-)

 

In the past, I created a simple iRule for logging based on https://my.f5.com/manage/s/article/K42210592.

(for troubleshooting)

 

For my understanding then I should see any GET/POST request in my LTM log. BUT if I compare the count of GET requests on client browser side (developer tools) and the LTM logs ----> it doesn't match. The LTM logs much less requests.

 

I know there is a limitation of 1024 bytes per request. But each client side request should be a new request for F5 (at least that's what I think). Could that be another log limitation?

 

Thanks for you help.

 

 

 

LTM
ltm irule

1 Reply

Sort By
  • CA_Valli's avatar
    CA_Valli
    Icon for MVP rankMVP
    Jul 23, 2024

    Hi! This is an interesting question that's a little tricky to answer properly .. 

    iRules are event-driven language, and this means that your code will be executed once every time that the trigger condition (called the iRule event, ie. HTTP_REQUEST) is triggered. 

    The way that these events fire is usually largely dependent on the traffic/network flow across the BIG-IP: the F5 proxy architecture is made up of a series of filters, designed to perform specific functions; and each of these filters has an associated set of iRules events that fire at that point in the session’s life cycle as well, when the connection is being interrogated or affected by the particular filter in question. As the connection is passed up the chain more and more specific filters fire, along with events to match.

     

    Regarding your statement,

    But each client side request should be a new request for F5 (at least that's what I think). 

    This isn't always the case. For instance, some content could be cached, or the HTML code that loads the page might reference some external CSS <link>-elements, or external JS <script>-elements.

    In my opinion, wireshark is a better tool to perform this type of analysis, since every packet captured on the BIG-IP will represent a session that has been handed over from the client side of the proxy to the server side (and vice versa), meaning it should have passed its way down the filter chain on each side.