docker exec -ti 18f6134ac0f9 bash # Graylog Server Instance
apt-get update && apt-get install -y netcat
echo -n '{"version": "1.1", "host": "example.org", "short_message": "A
short message that helps you identify what is going on", "full_message":
"Backtrace here\n\nmore stuff", "timestamp": 1385053862.3072, "level": 1,
"_user_id": 9001, "_some_info": "foo", "_some_env_var": "bar"}' | nc -u -q1
localhost 12201
Ok, now, with this call I get at least visible throughput in graylog.
Things which still generate no throughput:
On the load balancer instance:
docker exec -ti f396598155a6 bash # Rancher Network Agent (= Haproxy Load
Balancer istance)
apt-get update && apt-get install -y netcat
echo -n '...' | nc -u -q1 192.168.0.9 12201 # Local Machine IP, goes
through docker-for-windows port exposure mechanisms
echo -n '...' | nc -u -q1 172.17.0.2 12201 # Docker Host IP, bypassing host
machine, only using internal docker network
echo -n '...' | nc -u -q1 192.168.0.9 12201 # Local Machine IP, goes
through docker-for-windows port exposure mechanisms
echo -n '...' | nc -u -q1 10.42.248.237 12201 # IP of Loadbalancer in
Rancher's Internal Network (Overlay)
Hooray, got the culprit!
This works:
echo -n '...' | nc -u -q1 10.42.218.111 12201 # IP of Graylog Server within
Rancher's Internal Network
On Wednesday, August 3, 2016 at 10:58:30 AM UTC-5, David Arnold wrote:
>
> Hi Marius,
>
> thanks a lot. I should have more knowledgable on this. I changed it, yet
> still there is silence. Actually, what happened is, that I started with the
> correct setting and as things showed not to be working I tried random
> changes to put some entropy in the case.
>
> Isn't there a way how I can verify, that graylog would receive an UDP
> message from localhost (within the container) to systematically isolate the
> failure?
>
> Best, David
>
> On Wednesday, August 3, 2016 at 2:17:52 AM UTC-5, Marius Sturm wrote:
>>
>> Hi,
>> your 'gelf-address' looks odd. To get the Docker logging driver working
>> start a UDP GELF input on the server side and use a address like udp://
>> 192.168.0.9:12201 on the container. Something like /gelf only exist in
>> a HTTP context what is not used in this case.
>>
>> Cheers,
>> Marius
>>
>>
>> On 3 August 2016 at 08:46, David Arnold <d...@devco.co> wrote:
>>
>>> Hi
>>> I have the following docker-compose file, on top of docker-for-windows
>>> 0.12 and rancher:
>>> elasticsearch:
>>> command: elasticsearch -Des.cluster.name='graylog'
>>> image: elasticsearch:2
>>> volumes: ['graylog-elst:/usr/share/elasticsearch/data']
>>> graylog:
>>> environment: {GRAYLOG_PASSWORD_SECRET: '${graylog_secret}',
>>> GRAYLOG_REST_TRANSPORT_URI: 'http://${graylog_fqdn}:12900',
>>> GRAYLOG_ROOT_PASSWORD_SHA2: '${graylog_password}'}
>>> image: graylog2/server:2.1.0-beta.2-1
>>> labels: {io.rancher.container.hostname_override: container_name}
>>> links: ['mongodb:mongo', 'elasticsearch:elasticsearch']
>>> restart: always
>>> expose: ['12201/udp']
>>> volumes: ['graylog-data:/usr/share/graylog/data']
>>> lb:
>>> image: rancher/load-balancer-service
>>> labels: {io.rancher.scheduler.global: 'true'}
>>> links: ['graylog:graylog']
>>> ports: ['9000:9000', '12900:12900', '12201:12201/udp', '12202:12202']
>>> restart: always
>>> mongodb:
>>> image: mongo:3
>>> labels: {io.rancher.container.hostname_override: container_name}
>>> volumes: ['graylog-mngo:/data/db']
>>>
>>>
>>> lb is rancher's haproxy 1.5 loadbalancer. From mi machine I can happily
>>> do:
>>>
>>> curl -XPOST http://192.168.0.9:12202/gelf -p0 -d
>>> '{"short_message":"Hello there 2", "host":"example.org",
>>> "facility":"test", "_foo":"bar"}'
>>>
>>> and hooray, everything as expected.
>>>
>>> Now I start another container with
>>>
>>> gelf-address=udp://192.168.0.9:12201/gelf
>>>
>>> Yet, there is an unbearable silence all over the place.
>>>
>>> I really don't know quite well how to debug and see if graylog is
>>> accepting as expected.
>>> So here is the question:
>>>
>>> What can I do to enter the graylog docker and test the UDP Input?
>>>
>>> I can't enter moby linux VM (docker-for-windows has blocked the access),
>>> but I can do those kind of stuff on localhost or from within a peer
>>> container as well.
>>>
>>> Thank's for any help. I hit the point where I don't advance by myself
>>> anymore.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Graylog Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to graylog2+u...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/graylog2/406cf55e-eee3-4ab3-821d-bdc3ecb3df50%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/graylog2/406cf55e-eee3-4ab3-821d-bdc3ecb3df50%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Developer
>>
>> Tel.: +49 (0)40 609 452 077
>> Fax.: +49 (0)40 609 452 078
>>
>> TORCH GmbH - A Graylog Company
>> Poolstraße 21
>> 20335 Hamburg
>> Germany
>>
>> https://www.graylog.com <https://www.torch.sh/>
>>
>> Commercial Reg. (Registergericht): Amtsgericht Hamburg, HRB 125175
>> Geschäftsführer: Lennart Koopmann (CEO)
>>
>
--
You received this message because you are subscribed to the Google Groups
"Graylog Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to graylog2+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/graylog2/c027c83d-3918-46cc-a34a-42aee9c80f7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
