Skip to content
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

Logging #34

Open
ghost opened this issue Jul 19, 2018 · 3 comments
Open

Logging #34

ghost opened this issue Jul 19, 2018 · 3 comments
Labels
discussion This topic needs discussion

Comments

@ghost
Copy link

ghost commented Jul 19, 2018

So far, all the logging stuff has been ignored.

The problem is that all the different golang log libraries don't share a common standard interface, so the solution would be to design a standard interface and then make an adapter for each one, similar to the way the SQL package has all the different database drivers, at the cost of not being able to use specific features to each logger package. That itself could be a big task. After a quick Google there seems to be an example which uses adapters approach here:
https://goa.design/implement/logging/

@jirenius
Copy link
Collaborator

Yes. Logging is ignored, and needs to be improved!

Using a logger interface, such as the one you suggested by goa, is a great idea. Not sure we need to do the driver approach, as multiple loggers could easily be implemented using a MultiLogger solution similar to the io.MultiWriter.

The logger could then be passed to the resgate server as part of the Config, as well as to the NATS client when creating that one.

Of course, using custom loggers like this is only when you wrap resgate's server package in your own main package. Resgate's own package main will use standard output.

Apart from this, it needs to be decided what to log, and what levels. NATS server has trace and debug logging. I am thinking about something similar:
https://github.com/nats-io/gnatsd/blob/master/main.go#L37

Any suggestions there?

@ghost
Copy link
Author

ghost commented Jul 26, 2018

well the best way i can contribute here it to highlight issues i have encountered on distributed systems.

  1. Logging.
    Want to have a central place for logs that all devices logs end up in.
  • that also gets around the current issue that i brought up and the remedy of using nomad.
  1. Log filtering
    You want to filter the logs.

All the above is because on distributed system you cant debug them in prod or dev unless you can do the 2 top things.

i would just standup a open tracing stack.
https://github.com/opentracing/opentracing-go
https://godoc.org/github.com/opentracing/opentracing-go

With open tracing, i am searching for the ability to do search retrieval on the central server.
no fount it yet

@ghost
Copy link
Author

ghost commented Jul 26, 2018

the other big one is open consensus.

This combines metrics with tracing ( and logs)

https://opencensus.io/roadmap/
https://godoc.org/go.opencensus.io/trace

https://github.com/go-kit/kit/blob/master/tracing/opencensus/endpoint.go

@jirenius jirenius mentioned this issue Dec 19, 2018
@jirenius jirenius added the discussion This topic needs discussion label Dec 19, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion This topic needs discussion
Projects
None yet
Development

No branches or pull requests

1 participant