[Asterisk-code-review] res_pjsip: Add endpoint configuration -- log_subscription_error (asterisk[master])

[Mark Murawski]

Mark Murawski has posted comments on this change. ( https://gerrit.asterisk.org/c/asterisk/+/14405 )

Change subject: res_pjsip:  Add endpoint configuration -- log_subscription_error
......................................................................


Patch Set 2:

(1 comment)

https://gerrit.asterisk.org/c/asterisk/+/14405/2/res/res_pjsip_exten_state.c 
File res/res_pjsip_exten_state.c:

https://gerrit.asterisk.org/c/asterisk/+/14405/2/res/res_pjsip_exten_state.c@419 
PS2, Line 419: 			ast_log(LOG_NOTICE, "Endpoint '%s' state subscription failed: "
             : 				"Extension '%s' does not exist in context '%s' or has no associated hint\n",
             : 				ast_sorcery_object_get_id(endpoint), resource, context);
> Instead of adding a whole new option just for this one log statement I think I'd be more inclined fo […]
I think it's better to actually start to invent a new log paradigm altogether that's more flag oriented.  But for now, since that doesn't exist, individual per-item logging would be incredibly helpful to match a wide variety of use cases without having to force a workflow.

My use case:
I pretty much run everything at core verbose 4 without question.  We have some pretty complex systems and need the ability to go to logging at any point and see what happened, so we can resolve the issue without having to ask people to 'reproduce the problem live'.  Something like subscription failures from a historical point of view, I could care less about.  Failing subscribes is more of a "what is it doing right now?" sort of thing, for us.  Turning off this one log, while keeping the rest of the logging, probably saves me about 2,000-5,000 lines of logging per second, per system.

Dropping down to verbose 0, I would consider it a no-go to just avoid logging one particular, but very common type of issue.  A type of issue that I think most I would agree to be not a major issue.  And I would think it would be safe to assume that other users would want to have verb 1,2,3,4,etc and also the ability to trim down certain types of extra logging.


General use case:
People should be able to control what they want across the entire ecosystem at a fairly atomic level, if it is reasonable to do so.  And that's a huge part of Asterisk history as a whole... one persons feature is another one's annoyance, so it begets that there's options to turn off and on.

And with the complexity of the logging system as it is right now, adding 'one more if' is not much of a performance hit by any means.  If someone wants full logging, but avoid what is noise to them, they should be able to do that without having to turn off logging completely.



-- 
To view, visit https://gerrit.asterisk.org/c/asterisk/+/14405
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: master
Gerrit-Change-Id: I5dff21c3c8ac3a3e3aefbd89053581fb90bc7018
Gerrit-Change-Number: 14405
Gerrit-PatchSet: 2
Gerrit-Owner: Mark Murawski <markm at intellasoft.net>
Gerrit-Reviewer: Friendly Automation
Gerrit-CC: Kevin Harwell <kharwell at digium.com>
Gerrit-Comment-Date: Tue, 12 May 2020 01:00:29 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Kevin Harwell <kharwell at digium.com>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20200511/d7b51e4e/attachment.html>