Using Fluentd with td-agent and remote syslog-ng hosts

2,116 views
Skip to first unread message

kelly...@greenwavereality.com

unread,
Oct 16, 2013, 7:27:33 PM10/16/13
to flu...@googlegroups.com
Forgive me if this is already asked, I couldn't locate it with a search.

I'm trying to get remote Amazon EC2 hosts running syslog-ng to write to Fluentd log collection. So far I can only log local host.

My syslog-ng config lines of interest are: (host ip changed to protect the innocent)

destination loghost2 {
  udp("123.345.678.9" port(24224));
  tcp("123.456.789.9" port(24224));
};

source s_apache {
  file("/var/log/apache2/access.log");
};

log {
  source(s_apache);
  destination(loghost2);
};

My td-agent config (thought I've tried a dozen combinations from the default from your docs to the fluent-elastic recommended and none worked)

<source>
  type syslog
  port 24224
  tag remote_syslog
</source>

<match remote_syslog.**>
  type elasticsearch
  logstash_format true
  flush_interval 10s # for testing
</match>

I've also tried:


#<source>
#  type syslog
#  port 42185
#  tag syslog
#</source>

#<source>
#  type forward
#</source>

#<match remote_syslog.**>
#  type stdout
#</match>

(among many others)

I can see that the hosts are connected with

$ lsof -nPi | grep syslog
syslog-ng 19510       root    6u  IPv4 113836970      0t0  UDP 123.345.567.89:23575->123.456.678.9:24224

Syslog, strace, and using -v on the fluent and td-agent init.d offer more information, but nothing useful or related besides listen on port 24224

The Fluentd WWW interface is empty, and the daemon listener seems to silently ignore me.

I can telnet between hosts, ports, and get a connection that I must terminate with ^] so I can see it is connecting.

Can you tell me where my error is, or more clearly how I should configure the listener on Fluentd?

Or, is my error in my syslog-ng config? Which seems to work otherwise if used with rsyslogd, etc.

Thank you for any help, I'm frustrated at this point.

Regards!

KB

Masahiro Nakagawa

unread,
Oct 17, 2013, 1:35:06 AM10/17/13
to flu...@googlegroups.com
Hi kelly,

Could you paste the content of /var/log/td-agent/td-agent.log ?



--
You received this message because you are subscribed to the Google Groups "Fluentd Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fluentd+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Kelly Black

unread,
Oct 17, 2013, 12:09:13 PM10/17/13
to flu...@googlegroups.com
Hi
Masahiro

Thanks for posting, but I actually found the problem.

UDP packets weren't getting through, and configuring syslog-ng to use TCP didn't fix it because apparently Fluent only listens for UDP?

Anyway I found the problem with

$ nc -l 42185
$ nc -l 24224

Perhaps that should be added to the install instructions as this problem was quite frustrating.

Secondarily I could not find the problem in google groups until I actually searched for "
no patterns matched tag="1""

It would be quite useful if they could add this tid bit to the http://docs.fluentd.org/articles/free-alternative-to-splunk-by-fluentd

Thank you sir for replying regardless. Its good to know people care ;)

KB


--
You received this message because you are subscribed to a topic in the Google Groups "Fluentd Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fluentd/gMPjtYwwLto/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fluentd+u...@googlegroups.com.

Masahiro Nakagawa

unread,
Oct 20, 2013, 1:23:31 PM10/20/13
to flu...@googlegroups.com
UDP packets weren't getting through, and configuring syslog-ng to use TCP didn't fix it because apparently Fluent only listens for UDP?

Yes. in_syslog plugin now supports only UDP.
TCP support is needed?

 

Kelly Black

unread,
Oct 21, 2013, 12:28:15 PM10/21/13
to flu...@googlegroups.com
Masahiro, thanks for responding. Sorry slow getting back to you I wanted to look at it again today.

I don't know how much need there would be for TCP report. My situation came from having both hosts in the cloud, but due to different geographical position and NAT they had to be configured to use the public interface (which will require I configure tls encryption). That's because the DMZ hosts are in different 10.x.x blocks. In such cases TCP is certainly easier to troubleshoot, but I don't know that it would be required.
Reply all
Reply to author
Forward
0 new messages