Closed mrybas closed 5 years ago
This is what I've found as well. However, are you able to get logs into Graylog after making this change?
I just made the edit after finding the previous error messages, and while it no longer complains on the lack of a key I get the following:
[2019/07/18 11:39:16] [ info] [storage] initializing...
[2019/07/18 11:39:16] [ info] [storage] in-memory
[2019/07/18 11:39:16] [ info] [storage] normal synchronization mode, checksum disabled
[2019/07/18 11:39:16] [ info] [engine] started (pid=1)
[2019/07/18 11:39:16] [ info] [filter_kube] https=1 host=kubernetes.default.svc.cluster.local port=443
[2019/07/18 11:39:16] [ info] [filter_kube] local POD info OK
[2019/07/18 11:39:16] [ info] [filter_kube] testing connectivity with API server...
[2019/07/18 11:39:21] [ info] [filter_kube] API server connectivity OK
[2019/07/18 11:39:21] [ info] [http_server] listen iface=0.0.0.0 tcp_port=2020
[2019/07/18 11:39:22] [error] [plugins/out_gelf/gelf.c:323 errno=104] Connection reset by peer
...
[2019/07/18 11:39:34] [ warn] [engine] Task cannot be retried: task_id=6 thread_id=2 output=gelf.0
Have you made further edits to the files apart from the IP and now this?
I managed to figure it out. Weirdly enough, I can't get it to work using a GELF HTTP input, as is described in the blog post, but a GELF TCP input made it work immediately (after making this edit). Are you using a HTTP or TCP input?
Hi! I use gelf udp
Hi,
I will most likely update the blog post to mention this. Then, one might consider GELF limitations, mostly about message size.
after removing
there is no short_message variable