resgateio / resgate

A Realtime API Gateway used with NATS to build REST, real time, and RPC APIs, where all your clients are synchronized seamlessly.
https://resgate.io
MIT License
689 stars 67 forks source link

Logging #34

Open ghost opened 6 years ago

ghost commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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.
  2. 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 commented 6 years ago

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