Differentiate log level depending on "response.status"

[anar-khalilov]

#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]

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

[pkqk]

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

[anar-khalilov]

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.

[pkqk]

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?