bramble icon indicating copy to clipboard operation
bramble copied to clipboard

Differentiate log level depending on "response.status"

Open anar-khalilov opened this issue 2 years ago • 4 comments

https://github.com/movio/bramble/pull/179

Currently, all requests are being logged as Info (v1.4.3/instrumentation.go:56) and it really results in lots and lots of logs, hence increases costs for our applications.

As per our application's requirements, we don't want to see logs for HTTP200 responses.

What we would like to achieve is to log depending on the response.status value like below.

However, if you come up with a better idea, we are welcome to use it.

func (e *event) finish() {
	e.writeLock.Do(func() {

		var logEntry = log.WithFields(log.Fields{
			"timestamp": e.timestamp.Format(time.RFC3339Nano),
			"duration":  time.Since(e.timestamp).String(),
		}).WithFields(log.Fields(e.fields))

		responseStatusCandidate := e.fields["response.status"]

		if responseStatusCandidate == nil{
			logEntry.Info(e.name)
			return
		}

		responseStatusCode, ok := responseStatusCandidate.(int)

		if !ok{
			logEntry.Info(e.name)
			return
		}

		if (responseStatusCode >= 100 && responseStatusCode <= 199){
			// informational responses
			logEntry.Debug(e.name)
		} else if (responseStatusCode >= 200 && responseStatusCode <= 299){
			// successful responses
			logEntry.Debug(e.name)
		} else if (responseStatusCode >= 300 && responseStatusCode <= 399){
			// redirection messages
			logEntry.Debug(e.name)
		} else if (responseStatusCode >= 400 && responseStatusCode <= 499){
			// client error responses
			logEntry.Error(e.name)
		} else if (responseStatusCode >= 500 && responseStatusCode <= 599){
			// server error responses
			logEntry.Error(e.name)
		} else {
			logEntry.Info(e.name)
		}
	})
}

anar-khalilov avatar Nov 03 '22 08:11 anar-khalilov

We would be super happy to receive feedback about this one because this is really important for us.

anar-khalilov avatar Nov 04 '22 12:11 anar-khalilov

Hi @anar-khalilov, thanks for your PR.

I can understand your need to not log all downstream requests, we'll have to consider a general solution rather than one that just fits your use case though.

Are you ok running a fork for now while we consider this?

Things to consider:

  • Should this be configurable
  • Log levels, error should be for gateway errors, not downstream responses, so perhaps warning makes more sense
  • We could make the instrumentation middleware customisable

pkqk avatar Nov 07 '22 02:11 pkqk

Thanks for comprehensive response. We are currently unable to run a fork due to corporate policies. Because of that we are wondering if this issue has been planned/started etc.

anar-khalilov avatar Nov 09 '22 07:11 anar-khalilov

Hi @anar-khalilov, it's not on our roadmap yet. If you are unable to run a fork, are you able to put a filter in your log collection that drops the unneeded records?

pkqk avatar Dec 04 '22 20:12 pkqk