-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add SysLogger for new implementation. #17171
Add SysLogger for new implementation. #17171
Conversation
@nazariig could you help review? |
Fix path issue.
@@ -48,6 +66,20 @@ def __init__(self, log_identifier): | |||
if not signal.getsignal(signal.SIGTERM): | |||
signal.signal(signal.SIGTERM, self.signal_handler) | |||
|
|||
def log(self, priority, msg, also_print_to_console=False): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xincunli-sonic IMHO, this is a hack and in general a bad architecture. The method you override, was not designed to be overridable. Also, the logger class is used in many other places, not just only a various python demons implementation. This means, that the issue appears to be in many places. Ideally, there should be two different implementations, which share the same interface (e.g., LoggerBase[defines logger interface API], SystemLogger[uses native syslog], SyslogLogger[uses syslog handler], FileLogger[uses file handler]). But that will lead up to a major code changes. I would suggest to abandon having a separate SyslogLogger implementation and just fix the original one, preserving all the defined set of APIs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is intending to be reduce the scope of new change. Here is the consideration
- Most of daemon process will inherit from Daemon_Base with old logger implementation. If we use the new SysLogger, then it could be used for all daemons.
- What we want to do would be only apply new SysLogger to some new Daemon process, like ycabled etc.
- The override function, you can think it like factory pattern, which depends on use_syslogger flag as optional parameter, if it is true then it will use new SysLogger, otherwise it keeps the old logger and behavior will not change.
/azp run |
Commenter does not have sufficient privileges for PR 17171 in repo sonic-net/sonic-buildimage |
/azp run Azure.sonic-buildimage |
Azure Pipelines successfully started running 1 pipeline(s). |
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
/azpw run |
/AzurePipelines run |
Azure Pipelines successfully started running 1 pipeline(s). |
@xincunli-sonic could you please help to prioritize this PR feedback and checkers? |
Hi @xincunli-sonic , I suppose the checker failure is related to the code change. The unit test tried to connect to a unix socket of a logger server, but the unix socket does not exist.
|
Hi @prgeor , could you please kindly review this? |
@liat-grozovik can you merge? |
i removed the backport ask for old branches as 202205 and 202305. if this is must lets discuss. |
This PR introduces the SysLogger to address an issue where the original Logger.py could override the SYSLOG_IDENTIFIER if a new Logger instance is created.
Why I did it?
This change was made because the SysLog was displaying
NOTICE pmon#CCmisApi:
instead ofNOTICE pmon#ycable:
. This discrepancy led to confusion during debugging and incorrect component identification in log analysis.How I did it
I implemented an instance-level syslog using the
logging.handlers
module to prevent the SYSLOG_IDENTIFIER from being overridden.How did you verify/test it?
Which release branch to backport (provide reason below if selected)
Signed-off-by: Xincun Li xincun.li@microsoft.com