Re: Monitoring disk space from within the server - Mailing list pgsql-hackers

On Fri, Nov 08, 2019 at 04:06:21PM +0100, Christoph Berg wrote:
>Re: Tomas Vondra 2019-11-08 <20191108145025.d7pfcip6plufxiah@development>
>> While I agree monitoring disk space is important, I think pretty much
>> every deployment already does that using some other monitoring tool
>> (which also monitors million other things).
>
>There are plenty of deployments where that isn't true, either because
>they aren't doing any monitoring, or (probably more commonly) because
>the OS monitoring is done by the OS department and the DB department
>doesn't have good access to the figures, and possibly not even any
>shell access.
>

It might sound a bit annoying, but I suspect deployments where the DBAs
does not have access to such basic system metrics have bigger issues and
giving them one particular piece of information is just a bandaid.

>Offering the numbers on the database level would make monitoring
>easier for these users, and also provide the numbers on the level
>where they might be useful. ("Do I have enough disk space to load this
>5GB dump now?")
>
>> Also, I wonder how universal / reliable this actually is, considering
>> the range of filesystems and related stuff (thin provisioning, quotas,
>> ...) people use in production. I do recall a number of cases when "df"
>> was showing a plenty of free space, but one of the internal resources
>> for that particular filesystem was exhausted. I doubt it's desirable to
>> add all this knowledge into PostgreSQL.
>
>That might be partly true, e.g. btrfs traditionally didn't support
>"df" but only "btrfs df". But this got fixed in the meantime, and just
>because there are weird filesystems doesn't mean we shouldn't try to
>support the normal case where statfs() just works.
>

Maybe, but if you suggest to show the information in \dn+ then we should
at least know how common / likely those issues are. Because if they are
anything but extremely uncommon, we'll get plenty of bogus bug reports
complaining about inaccurate information.

>> It's not clear to me what issue this is actually meant to solve - it
>> provides data, which is nice, but it still needs to be fed to some
>> motinoring and alerting system. And every monitoring system has a good
>> plugin to collect this type of data, so why not to use that?
>
>What's wrong with providing nice data? It doesn't hurt to have it.
>And the cost of the implementation is low.
>

My point was that there are other (better, already existing) ways to get
the data, and getting them through database means extra complexity (I do
agree it's not a lot of code at this point, though).

Of course, if your assumption is that using those other ways to get the
data is impossible, then sure - adding this makes sense.

>> Surely, we can't rely on this for any internal logic - so why not to
>> provide this as an extension?
>
>By the same argument you could also argue that \l+ should be an
>extension because database size is optional to know.
>

That's not really my argument, though. I'm not suggesting everything
"optional" should be in an extension, but that there's nothing forcing
us to make this directly part of the core.

And packaging stuff into extension has advantages too (independent dev
cycle, and so on).

>I think this should be directly in core because it's useful to a wide
>range of users.
>

I'm not convinced that's actually true. It might be, but I don't have
any data to support it (or vice versa).


cheers

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services