High Speed Logging service requires restart

Hi Simon,

 

 

I think HSL processing is within TMM, so you'd need to restart TMM or all services. What's the issue you're trying to address?

 

 

Aaron

Is this still the only way to restart HSL? Has this been changed in V11? It would be a pity to bring everything down (or perform a fail-over) to restart one service....

what's the issue you are having?

 

 

this is a bug about HSL i've found. not sure if it's what you are experiencing.

 

 

Bug 343642 - HSL: B/W tracking apparently fails to recover from transient loss of all pool members.

 

Bug 343642 is fixed in 10.2.2 and 11.0.0.

I restarted our Syslog server, and HSL hasn't logged since. I'm about to go restart TMM.

are you using tcp?

 

what is software unit is running? is it 10.2.2?

UDP on 10.2.0

i run nc -l -u -p 514 as syslog server.

i was able to receive hsl log after ctrl+c and run nc again.

[root@Edelweiss:Active] config  b version|grep -iA 1 version
BIG-IP Version 10.2.0 1707.0
Final Edition

[root@Edelweiss:Active] config  b virtual bar list
virtual bar {
   snat automap
   pool foo
   destination 172.28.17.77:http
   ip protocol tcp
   rules myrule
   profiles {
      http {}
      tcp {}
   }
}
[root@Edelweiss:Active] config  b rule myrule list
rule myrule {
   when CLIENT_ACCEPTED {
   set hsl [HSL::open -proto UDP -pool syslogp]
}
when HTTP_REQUEST {
    Log HTTP request as local7.info; see RFC 3164 Section 4.1.1 - "PRI Part" for more info
   HSL::send $hsl "<190>[clock format [clock seconds] -gmt 8] [IP::local_addr] [HTTP::uri]"
}
}
[root@Edelweiss:Active] config  b pool syslogp list
pool syslogp {
   members 192.168.206.96:shell {}
}

You might want to update to something later than 10.2.0. I had similar problems with HSL last year... Later is better...

 

 

HSL with tcp has it's own set of challenges BTW... I had to do a 'bigstart restart tmm' quite a few times when stress testing. That's the only way to get it to work again IIRC...

 

 

H