iRule for HSL or logging etc

If this is for HTTP, I recommend using a Request Logging Profile:

• Using the Request Logging Profile

If that is not suitable, however:

when LB_SELECTED {
    set hsl [HSL::open -publisher your_publisher]
    
    HSL::send $hsl "[clock format [clock seconds]] [IP::client_addr] [LB::server name] [clientside {IP::local_addr}]:[clientside {TCP::local_port}]"
}

If you wish to do this for HTTP, it's prudent to do this instead (if you want to log on each HTTP Request message):

when CLIENT_ACCEPTED {
    set hsl [HSL::open -publisher your_publisher]
}

when HTTP_REQUEST {
    HSL::send $hsl "[clock format [clock seconds]] [IP::client_addr] [LB::server name] [clientside {IP::local_addr}]:[clientside {TCP::local_port}]"
}

If this is for HTTP, I recommend using a Request Logging Profile:

• Using the Request Logging Profile

If that is not suitable, however:

when LB_SELECTED {
    set hsl [HSL::open -publisher your_publisher]
    
    HSL::send $hsl "[clock format [clock seconds]] [IP::client_addr] [LB::server name] [clientside {IP::local_addr}]:[clientside {TCP::local_port}]"
}

If you wish to do this for HTTP, it's prudent to do this instead (if you want to log on each HTTP Request message):

when CLIENT_ACCEPTED {
    set hsl [HSL::open -publisher your_publisher]
}

when HTTP_REQUEST {
    HSL::send $hsl "[clock format [clock seconds]] [IP::client_addr] [LB::server name] [clientside {IP::local_addr}]:[clientside {TCP::local_port}]"
}

The http profile itself should not interrupt traffic, though its application will cause the VS to drop any traffic that is improperly formatted HTTP (or which is not HTTP at all). It should also not cause any traffic drops at the moment it is applied.

In any case, I admit that you follow-on question is somewhat unclear to me. When you write "... how about for the application that I want to monitor", do you mean that you want to log something from a BIG-IP monitor used to health check a pool member/node? Or do am I misreading your request?

The http profile itself should not interrupt traffic, though its application will cause the VS to drop any traffic that is improperly formatted HTTP (or which is not HTTP at all). It should also not cause any traffic drops at the moment it is applied.

In any case, I admit that you follow-on question is somewhat unclear to me. When you write "... how about for the application that I want to monitor", do you mean that you want to log something from a BIG-IP monitor used to health check a pool member/node? Or do am I misreading your request?

If you add the http profile to a Virtual Server that is receiving non-HTTP traffic, that traffic flow will fail (because the HTTP parser will reject the traffic). On the other hand, if you believe the traffic is in fact HTTP, then one of three things is happening:

1. the traffic is malformed HTTP (in which case the HTTP parser rejects the message);
2. the HTTP traffic violates http profile configured protections (for example, there is a maximum header size limit that is configurable on the profile. If a message is received with headers exceeding the limit, the message is dropped);
3. you are encountering a bug (in which case, you should open a support case).

At any rate, as I mention above, you can log any arbitrary traffic by using the CLIENT_ACCEPTED, LB_SELECTED or SERVER_CONNECTED events, all of which happen on any full-proxy connection. For example:

when LB_SELECTED {
    set hsl [HSL::open -publisher your_publisher]

    HSL::send $hsl "[clock format [clock seconds]] [IP::client_addr] [LB::server name] [clientside {IP::local_addr}]:[clientside {TCP::local_port}]"
}

This assume the traffic is TCP. If it is UDP, the change each instance of

TCP::

UDP::

If you add the http profile to a Virtual Server that is receiving non-HTTP traffic, that traffic flow will fail (because the HTTP parser will reject the traffic). On the other hand, if you believe the traffic is in fact HTTP, then one of three things is happening:

1. the traffic is malformed HTTP (in which case the HTTP parser rejects the message);
2. the HTTP traffic violates http profile configured protections (for example, there is a maximum header size limit that is configurable on the profile. If a message is received with headers exceeding the limit, the message is dropped);
3. you are encountering a bug (in which case, you should open a support case).

At any rate, as I mention above, you can log any arbitrary traffic by using the CLIENT_ACCEPTED, LB_SELECTED or SERVER_CONNECTED events, all of which happen on any full-proxy connection. For example:

when LB_SELECTED {
    set hsl [HSL::open -publisher your_publisher]

    HSL::send $hsl "[clock format [clock seconds]] [IP::client_addr] [LB::server name] [clientside {IP::local_addr}]:[clientside {TCP::local_port}]"
}

This assume the traffic is TCP. If it is UDP, the change each instance of

TCP::

UDP::

The application of the http profile is not necessary for iRules to work. It is necessary to utilize HTTP events (e.g., HTTP_REQUEST) and HTTP primitives (e.g.,

HTTP::header

IP::client_addr

The application of the http profile is not necessary for iRules to work. It is necessary to utilize HTTP events (e.g., HTTP_REQUEST) and HTTP primitives (e.g.,

HTTP::header

IP::client_addr