Re: F21 Self Contained Change: Remote Journal Logging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2014-04-22 at 06:34 +0200, Lennart Poettering wrote:
> On Wed, 16.04.14 12:46, Bill Nottingham (notting@xxxxxxxx) wrote:
> 
> > Zbigniew Jędrzejewski-Szmek (zbyszek@xxxxxxxxx) said: 
> > > On Mon, Apr 14, 2014 at 04:20:16PM -0400, Bill Nottingham wrote:
> > > > Jaroslav Reznik (jreznik@xxxxxxxxxx) said: 
> > > > > = Proposed Self Contained Change: Remote Journal Logging = 
> > > > > https://fedoraproject.org/wiki/Changes/Remote_Journal_Logging
> > > > > 
> > > > > Change owner(s): Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx>
> > > > > 
> > > > > Systemd journal can be configured to forward events to a remote server. 
> > > > > Entries are forwarded including full metadata, and are stored in normal 
> > > > > journal files, identically to locally generated logs. 
> > > > 
> > > > What's the future of gatewayd if this becomes more widely used?
> > >
> > > gatewayd works in pull mode. Here I'm proposing a push model, where the
> > > "client" (i.e. machine generating the logs) pushes logs to the server
> > > at the time of its own chosing. gatewayd is probably better for some use
> > > cases, this for others.
> > 
> > I understand the pull vs push distinction ... I'm just not clear why pull
> > would ever be a model you'd want to use. (vs something like a local cockpit
> > agent.)
> 
> Pull is the only model that scales, since the centralized log infrastructure can
> schedule when it pulls from where and thus do this according to
> available resources. THe push model is prone to logging bursts
> overwhelming log servers if you scale your network up.
> 
> I am pretty sure that a pull model should be the default for everything
> we do, and push only be done where realtimish behaviour is desired to do
> live debugging or suchlike.
> 
> I am pretty sure the push model concept is one of the major weaknesses
> of the BSD syslog protocol.

Except that the server may not need direct access to the clients (in
NATted LANs for examples), so sometimes push is all you can count on,
make sure you can think how to properly rate limit, give feedback to
clients if necessary. A good protocol would allow to send a first small
packet that establish a connection and a reply that can "push back" on
the client w/o requiring huge bandwidth to be spent.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux