sendgridlabs / loggly-docker

Docker container for loggly (via syslog)
MIT License
44 stars 39 forks source link

error message from docker container itself: Error in the push function. #21

Closed JLarky closed 8 years ago

JLarky commented 8 years ago

I'm getting errors that are internal for syslog. Here's the error:

severity: Error
timestamp: 2016-03-07T17:57:59.638236+00:00
facility: messages generated internally by syslogd
priority: 43
host: 17010d56a5f9
unparsed:
message: unexpected GnuTLS error -53 in nsd_gtls.c:1618: Error in the push function. [v8.9.0 try http://www.rsyslog.com/e/2078 ]

image 2016-03-07 10-22-54

I use docker like that (docker-compose format):

loggly-docker:
  restart: always
  image: sendgridlabs/loggly-docker
  ports:
   - 514/udp
  environment:
   - TAG=MyTag
   - TOKEN=xxxx

it also sends some other non application specific messages like:

action 'action 1' resumed (module 'builtin:omfwd') [v8.9.0 try http://www.rsyslog.com/e/2359 ]
-- MARK --

but I'm ok with those since at least they don't say "error" in them :)

jonathan-short commented 8 years ago

Can you compare the two images "sendgridlabs/loggly-docker:1.3" and "sendgridlabs/loggly-docker:1.4" to see if the behavior is the same in both?

JLarky commented 8 years ago

it seems that 1.3 is no longer available on docker hub image

jonathan-short commented 8 years ago

Ah - that's unexpected I haven't done anything to make then unavailable.

I pushed up a rebuilt 1.3 with the tag '1.3-rebuild'. If you could compare that to 1.4 that'd be an interesting data point. There was an upgrade of the alpine base image and a minor change to the rsyslog config between the two.

JLarky commented 8 years ago

I was going to ask you how do you do that :))

I started two containers, one with latest and one with 1.3-rebuild, I will let you know

JLarky commented 8 years ago

image I had two containers running, and as you can see it behaves this way in both of them image

jonathan-short commented 8 years ago

Thanks for doing the comparison - I wanted to be sure it wasn't broken by the recent changes and it looks like it wasn't.

It looks like the containers may both exhibit the problem at about the same time.

Unfortunately I don't have any insight into rsyslog's log message or internals. My best guess is that this is a network error of some kind? Perhaps you could pursue an answer upstream with rsyslog?

JLarky commented 8 years ago

Actually I see this issue in rsyslog github https://github.com/rsyslog/rsyslog/issues/846 so I guess you would just have to update image to use whatever version that was fixed in

frederikaalund commented 8 years ago

@JLarky I just want to let you know that I recently re-opened rsyslog/rsyslog#846 since it actually wasn't fixed in the 8.17.0 release.

JLarky commented 8 years ago

@jonathan-short later in rsyslog discussion they talk about http://www.rsyslog.com/doc/relp.html maybe that's what you should use for loggly instead of tcp?

jonathan-short commented 8 years ago

@JLarky thanks for finding and connecting to the upstream rsyslog issue. I don't see that loggly supports RELP server side, so that probably isn't a viable option. (Note - I don't work for loggly). If/when loggly does support RELP, I can consider a pull request to use it.

From the upstream issue, it sounds like network interruption is to blame, the only resolution being an improved syslog message. We can pick that up when alpine pulls in the new version.

I'll close this issue for now as it sounds like everything is working as expected.

alex88 commented 7 years ago

Seems there is issue is still there with latest version, I still having continuous errors like

rsyslogd: unexpected GnuTLS error -53 in nsd_gtls.c:1618: Error in the push function.  [v8.9.0 try http://www.rsyslog.com/e/2078 ]
GnuTLS error: Error in the push function.

using latest version (image downloaded couple months ago)