On 06/20/2017 01:23 PM, Alban Hertroys wrote:
On 20 Jun 2017, at 18:46, Adrian Klaver <adrian.klaver@xxxxxxxxxxx> wrote:
Yes this could be become complicated if for no other reason then it is being driven from the customer end and there will need to be a process to verify and incorporate their changes.
There you're saying something rather important: "If it is being driven from the customer end".
Yeah, it is the interaction between technical issues and people issues.
One is easier to solve then the other:)
2) Figure out what a day is. In other words are different timezones involved and if so what do you 'anchor' a day to?
For an example of how that might fail: At our company, they work in shifts (I don't) of 3*8 hours, that run from 23:00 to 23:00. Depending on who looks at the data, either that's a day or a normal day (00:00-00:00) is. It's a matter of perspective.
I see that as part of how to 'anchor' a day. Right now Steve is looking
at one customer as I understand it. I would expect that might change so
I can envision a system that would need to account for different
definitions of a day. Still you have to start somewhere.
IMHO, the only safe approach is to have the customer end decide whether it's a regular outage or an irregular one. There is just no way to reliably guess that from the data. If a customer decides to turn off the system when he's going home, you can't guess when he's going to do that and you will be raising false positives when you depend on a schedule of when he might be going home.
From a software implementation point of view that means that your customer-side application needs to be able to signal planned shutdowns and startups. If you detect any outages without such a signal, then you can flag it as a problem.
I agree. I personally see false alerts as a form of 'Crying wolf' and I
think that down the road they lead to complacency. Hence my earlier
suggestion to have a method to indicate manual intervention on the
customer end.
There are still opportunities for getting those wrong of course, such as lack of connectivity between you and your customer, but those should be easy to explain once detected.
And I'm sure there are plenty of other corner-cases you need to take into account. I bet it has a lot of problems in common with replication actually (how do we reliably get information from system A to system B), so it probably pays to look at what particular problems occur there and how they're solved.
I would say a good deal of the above is going to be driven by legal
considerations. Who is responsible for what and what guarantees are in
effect.
Alban Hertroys
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
