Curious how other folks are dealing with the volume of logs that Kamailio generates. We are currently sending them to syslog and alerting on WARN and above but the amount of alert noise is unbearable. For example (there are many variations): ERROR: <core> [core/tcp_read.c:297]: tcp_read_data(): error reading: Connection reset by peer INVITE:WARNING: sanity [sanity.c:776]: check_parse_uris(): failed to parse
From header
INVITE:ERROR: <core> [core/parser/parse_from.c:75]: parse_from_header(): b ad From header
The fact that these are WARN/ERROR level and from core makes me wonder how we can possibly make alerts relevant. Any input would be appreciated.
Thanks,
Daniel G
Hello,
maybe you can make some filtering based on the path of the files printing the error messages, so if you want to "ignore" parsing errors, then skip alerts what have "core/parser/" in the path.
Otherwise, it is not that easy to add so many options to be able to control every errors/warnings/... when to print them.
There could be also solutions to block traffic from devices sending broken SIP packages continuously/for long interval of time.
Cheers, Daniel
On 14.02.19 03:58, Daniel Greenwald wrote:
Curious how other folks are dealing with the volume of logs that Kamailio generates. We are currently sending them to syslog and alerting on WARN and above but the amount of alert noise is unbearable. For example (there are many variations): ERROR: <core> [core/tcp_read.c:297]: tcp_read_data(): error reading: Connection reset by peer INVITE:WARNING: sanity [sanity.c:776]: check_parse_uris(): failed to parse From header INVITE:ERROR: <core> [core/parser/parse_from.c:75]: parse_from_header(): b ad From header
The fact that these are WARN/ERROR level and from core makes me wonder how we can possibly make alerts relevant. Any input would be appreciated.
Thanks,
Daniel G
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
I would also say - implement your own routing logic / info shaking data you wish to make sense of, then change debug level to lower value, change debug level higher when actually reproducing and investigating a bug/issue.
On Thu, Feb 14, 2019 at 6:57 AM Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
maybe you can make some filtering based on the path of the files printing the error messages, so if you want to "ignore" parsing errors, then skip alerts what have "core/parser/" in the path.
Otherwise, it is not that easy to add so many options to be able to control every errors/warnings/... when to print them.
There could be also solutions to block traffic from devices sending broken SIP packages continuously/for long interval of time.
Cheers, Daniel On 14.02.19 03:58, Daniel Greenwald wrote:
Curious how other folks are dealing with the volume of logs that Kamailio generates. We are currently sending them to syslog and alerting on WARN and above but the amount of alert noise is unbearable. For example (there are many variations): ERROR: <core> [core/tcp_read.c:297]: tcp_read_data(): error reading: Connection reset by peer INVITE:WARNING: sanity [sanity.c:776]: check_parse_uris(): failed to parse From header INVITE:ERROR: <core> [core/parser/parse_from.c:75]: parse_from_header(): b ad From header
The fact that these are WARN/ERROR level and from core makes me wonder how we can possibly make alerts relevant. Any input would be appreciated.
Thanks,
Daniel G
Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Gotcha. I have some xlog info stuff in thing is we weren't catching unforeseen things like 'dispatcher had no nodes'. I'm now using a syslog regex to alert for 'dispatcher' and maybe I'll do one for 'core' minus anything with the word 'parse'. Baby steps..
On Thu, Feb 14, 2019, 5:23 PM Brandon Armstead brandon@cryy.com wrote:
I would also say - implement your own routing logic / info shaking data you wish to make sense of, then change debug level to lower value, change debug level higher when actually reproducing and investigating a bug/issue.
On Thu, Feb 14, 2019 at 6:57 AM Daniel-Constantin Mierla < miconda@gmail.com> wrote:
Hello,
maybe you can make some filtering based on the path of the files printing the error messages, so if you want to "ignore" parsing errors, then skip alerts what have "core/parser/" in the path.
Otherwise, it is not that easy to add so many options to be able to control every errors/warnings/... when to print them.
There could be also solutions to block traffic from devices sending broken SIP packages continuously/for long interval of time.
Cheers, Daniel On 14.02.19 03:58, Daniel Greenwald wrote:
Curious how other folks are dealing with the volume of logs that Kamailio generates. We are currently sending them to syslog and alerting on WARN and above but the amount of alert noise is unbearable. For example (there are many variations): ERROR: <core> [core/tcp_read.c:297]: tcp_read_data(): error reading: Connection reset by peer INVITE:WARNING: sanity [sanity.c:776]: check_parse_uris(): failed to parse From header INVITE:ERROR: <core> [core/parser/parse_from.c:75]: parse_from_header(): b ad From header
The fact that these are WARN/ERROR level and from core makes me wonder how we can possibly make alerts relevant. Any input would be appreciated.
Thanks,
Daniel G
Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-- Sent from Gmail Mobile
-
Brandon Armstead -
Daniel Greenwald -
Daniel-Constantin Mierla