:: Re: [DNG] Mirror 141.84.43.19 - Fre…
Kezdőlap
Delete this message
Reply to this message
Szerző: Evilham
Dátum:  
Címzett: Bernard Rosset
CC: dng
Tárgy: Re: [DNG] Mirror 141.84.43.19 - Frequent unavailability
On dc., jul. 17 2019, Bernard Rosset via Dng wrote:

> Thx Evilham for your answer. Glad it was not sinkholed ;o)


Not at all :-).

>> But maybe it'll be interesting to add simple monitoring at a
>> connection
>> level same way you ran your tests.
>> I'll try to setup a thing in the next couple days.
>
> I was actually thinking about ways of involving the community,
> whose
> kind members already are actively participating in mirrors &
> such, in a
> distributed monitoring array.
> While heavy checks might be run on more central,
> tighly-controlled
> components, availability checks could be run from anyone's
> scheduled
> tasks manager, and might be aggregated as "pods" in (a)
> monitoring
> instance(s) responsible to store & display results?
>
> I was thinking simple checks run as scheduled tasks, collection
> through
> rsyslog. For the displaying part YMMV, depending on which you
> merely
> wanna display or allow viewers to query on the dataset... hence
> either a
> static display or more evolved stuff like Grafana.
>
> Has anyone built such a thing recently with maybe more proper
> architectures, yet agent-less, than this one?
> The usual monitoring setups I encountered so far tended to be
> locked to
> the previously chosen tech... for better or worse. Decoupling is
> good.
>
> This would pave the way for check coming from many
> networks/IX/equipments/hosters, etc. balancing/nullifying
> observation
> biases.



Interesting idea, but that opens a weird can of worms, e.g.
quality and reliability of the data, biases, even privacy and a
bunch of things that won't come to me right now.

So, it *is* interesting, but it may be a bit of an overkill for
this particular instance of this class of issues?


Regarding public grafana dashboards, they have an issue, and it's
that by having a public dashboard you effectively disclose the
whole data source since grafana only acts as a proxy that passes
queries to the data source.
It's pretty trivial as well, just use the network tab and find the
API calls, open in a new tab and modify the query away :-).
https://community.grafana.com/t/how-to-make-one-live-dashboard-public/12819/2

It may not be a problem if you consider the data source to be
public anyway.


FWIW, when I said "I'll see if I can set up sth", I had in mind a
thing we started as a PoC on a public status page, but it hasn't
been brought up to being actually working publicly, e.g. for
Devuan.
https://github.com/evilham/prometheus-adlermanager


>> If we get more reports we totally will, so far everything is
>> "looking
>> good" and all tests pass, but maybe there is indeed something
>> inherently
>> spotty on the connection and that's what you are seeing; we'll
>> see if
>> with more data or more reports or when the maintainer takes a
>> look
>> something changes.
>
> IIUC, this lack of detection seems to be coming from the lack of
> monitoring... hence my ping/call to the community :o)
> Anyone jumping on board is warmly welcome!



Oh, there is monitoring, it's just, you know, you can always
monitor more and better :-p.

In any case, just be respectful towards the mirror admins and
don't do crazy things like checking that everything is equal bit
to bit every 30 minutes :-).
--
Evilham