-
Notifications
You must be signed in to change notification settings - Fork 345
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
Implement custom logger #134
Comments
We can assign identifiers and name when creating a job. For ease of tracking. What do your think about it? |
Hi @akdilsiz! Interesting idea... How do you think the implementation would work? Could you give some examples of the usage? |
Hi @Streppel, When the new job is added, if the custom logger is defined, I give an example; The callback function CustomLogger.Info ("Added new job") can be called. Or it can be called CustomLogger.Info ("Job done") when the job is finished or stopped. Of course, we need to define a custom logger interface. type CronLogger interface {
Info(msg string)
Error(err error, msg string)
} Considering that we created a special interface in this way. We can ask the developer to create a custom logger structure for our interface. type CustomLogger struct {
CronLogger
}
func (l CustomLogger) Info(msg string) {
fmt.Println(msg)
}
func (l CustomLogger) Error(err error, msg string) {
fmt.Println(err, msg)
} or type CustomLogger struct {
CronLogger
Log *zap.Logger
}
func (l CustomLogger) Info(msg string) {
l.Log.Sugar().Info(msg)
}
func (l CustomLogger) Error(err error, msg string) {
l.Log.Sugar().Error(err, msg)
} If jobs or the timer is run later, if the logger is defined, we call the required functions. func (s *Scheduler) RunPending() {
runnableJobs, n := s.getRunnableJobs()
if n != 0 {
for i := 0; i < n; i++ {
runnableJobs[i].run()
}
if s.Logger != nil {
s.Logger.Info("RunPending runs all the jobs that are scheduled to run.")
}
}
} This can give us a plus feature. If a solution such as Logstash is used, the job logs will automatically reach the logstash solution. Or can do whatever the developer wants to do. The extra features that the developer will provide if we add identifiers, delete the job without closing the main program, job update events can be done easily through the logic of his own. The main goal is to make the developer's job even easier. |
@akdilsiz thank you for writing your suggestion! It's a very good idea indeed. I will not implement it right away because we are in the middle of a big merge and some things in the code base might change soon, but as soon as things settle down I will take a look into it. If you want to, you could also develop it and we could review and merge it later. Anyways, this will be scheduled for the 1.0 milestone. |
@Streppel okay, I will start developing this feature. Happy codings :) |
I think we should make it compatible with the custom logger modules created in the applications. In this way, job status can be monitored in autonomous state. I can write directly, if that's okay.
The text was updated successfully, but these errors were encountered: