{"action":"created","issue":{"url":"https://api.github.com/repos/keeprocking/pygelf/issues/8","repository_url":"https://api.github.com/repos/keeprocking/pygelf","labels_url":"https://api.github.com/repos/keeprocking/pygelf/issues/8/labels{/name}","comments_url":"https://api.github.com/repos/keeprocking/pygelf/issues/8/comments","events_url":"https://api.github.com/repos/keeprocking/pygelf/issues/8/events","html_url":"https://github.com/keeprocking/pygelf/issues/8","id":177623775,"number":8,"title":"every GELF record triggers getfqdn?","user":{"login":"jhaar","id":1179078,"avatar_url":"https://avatars.githubusercontent.com/u/1179078?v=3","gravatar_id":"","url":"https://api.github.com/users/jhaar","html_url":"https://github.com/jhaar","followers_url":"https://api.github.com/users/jhaar/followers","following_url":"https://api.github.com/users/jhaar/following{/other_user}","gists_url":"https://api.github.com/users/jhaar/gists{/gist_id}","starred_url":"https://api.github.com/users/jhaar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jhaar/subscriptions","organizations_url":"https://api.github.com/users/jhaar/orgs","repos_url":"https://api.github.com/users/jhaar/repos","events_url":"https://api.github.com/users/jhaar/events{/privacy}","received_events_url":"https://api.github.com/users/jhaar/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2016-09-18T02:13:58Z","updated_at":"2016-10-09T21:00:00Z","closed_at":null,"body":"Hi there\r\n\r\nI was debugging an unrelated issue and detected tonnes of DNS lookups for the hostname I was running pygelf on (permanent process, converting squid logs into GELF in realtime). It looks to me like pygelf is doing a DNS lookup for $HOSTNAME for every GELF record it generates? That's a nasty overhead if you're generating 100+/sec streams of GELF data\r\n\r\nI don't know for sure, but could it be the \"'source': socket.getfqdn()\" in gelf.py that's doing that?\r\n\r\nShouldn't that be replaced by defining that as a variable at startup, and then just reusing that variable afterwards? I know the hostname could be put into /etc/hosts, but actually strace showed the DNS lookups occurring before /etc/hosts was opened - so I don't even think that would help - and even that's an overhead that could be skipped if it only did it once?\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/keeprocking/pygelf/issues/comments/252512325","html_url":"https://github.com/keeprocking/pygelf/issues/8#issuecomment-252512325","issue_url":"https://api.github.com/repos/keeprocking/pygelf/issues/8","id":252512325,"user":{"login":"jhaar","id":1179078,"avatar_url":"https://avatars.githubusercontent.com/u/1179078?v=3","gravatar_id":"","url":"https://api.github.com/users/jhaar","html_url":"https://github.com/jhaar","followers_url":"https://api.github.com/users/jhaar/followers","following_url":"https://api.github.com/users/jhaar/following{/other_user}","gists_url":"https://api.github.com/users/jhaar/gists{/gist_id}","starred_url":"https://api.github.com/users/jhaar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jhaar/subscriptions","organizations_url":"https://api.github.com/users/jhaar/orgs","repos_url":"https://api.github.com/users/jhaar/repos","events_url":"https://api.github.com/users/jhaar/events{/privacy}","received_events_url":"https://api.github.com/users/jhaar/received_events","type":"User","site_admin":false},"created_at":"2016-10-09T20:59:59Z","updated_at":"2016-10-09T20:59:59Z","body":"Well that's weird - I'm a big user of graylog and all our incoming syslog data has 'source' set to the syslog client name. I see no evidence of that becoming \"host\"? ie incoming syslog data out of syslog agents looks like\r\n\r\ntimestamp syslogclient other\r\n\r\nFrom what you are saying, wouldn't you expect that the latest version of graylog (v2.1.1) be setting \"host=syslogclient\" - I'm not seeing that. I'm not seeing any reference to a \"host\" field at all. (ie if graylog themselves aren't doing it for syslog, that's not much motivation to do it for GELF/pygelf)\r\n\r\nBTW, I did a \"pip install pygelf\" and now I'm getting full_message:null - which wasn't happening on the older version of pygelf I had. I've always used short_message. How do I get rid of that, or couldn't you do something like require that either short_message or full_message be set, and remove the unused one? Just in case you don't know, graylog shows my short_message fields as \"message\", so now I have the situation that even though I'm setting \"short_message\", graylog is showing a \"message\" field and a \"null\" full_message field. \r\n\r\n"}}
{"actor":{"display_login":"jhaar"}}