On Tue, Apr 22, 2014 at 06:34:48AM +0200, Lennart Poettering wrote:
> 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.
This terminology is (excitingly?) reversed from push vs. pull in
configuration management, where either clients pull from a server or have
commands pushed to them. Maybe we could use different terms for logging
instead, like "send" and "fetch"?
Or maybe it's just me that's easily confused.
> 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.
There are advantages and disadvantages to both. Disadvantages of pull
(fetch) include:
- If a client system is broken into, logs may be removed before they're
fetched. (Of course, this is also a risk with a "batched" send/push
scheme.)
- Client system needs to hold logs until asked -- maybe a long time.
Traditionally some devices don't hold logs at all and _just_ send them
remotely.
- Usually pull/fetch designs require more configuration, with the server
needing a list of clients to check and the clients configured to allow
connections from just that server in.
But it's definitely better for scaling, and you don't have to worry about
100% log server uptime, and the log server itself can be kept more secure.
And on the neutral side, the network design may make it hard to reach
clients; they might be behind NAT/PNAT from the log server's point of view.
That's not necessarily an inherent pro or con, but may make push/send fit
better into a certain environment.
--
Matthew Miller -- Fedora Project -- <mattdm@xxxxxxxxxxxxxxxxx>
"Tepid change for the somewhat better!"
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
