Monitorovani site

[Dan Lukes]

On 07/03/14 10:58, Miroslav Lachman:
>> Dan pise, "(ne)uspesny ping nerovna se nutne (ne)schopnosti navazat TCP
>> spojeni na stejnou cilovou IP. A to jak ve smyslu falesne pozitivniho tak
>> falesne negativniho testu."
>
> V dnesni dobe se pouziva ruzna prioritizace packetu podle protokolu,
> nebo i podle sluzby (portu), takze je klidne mozne, ze jedna sluzba
> neprochazi a druha bezi jako vino. Stejne tak muze mit system nastaveno,
> ze odpovi maximalne na urcity pocet ICMP packetu za sekundu (u FreeBSD
> defaultne 200) a pritom ostatni TCP/IP provoz bezi nerusene dal.
> Nektera zarizeni maji ICMP (ping) zakazano uplne.

Pak zde muze byt problem s rozdilnou velikosti paketu, napriklad. Do hry 
muze vstoupit i pripadna fragmentace. Nebo s nejakym stavovym filtr se 
buhvi proc nekde zamota do cesty. Nebo zmena v poradi dorucovanych 
paketu, ktera se bude projevovat spis za nekterych okolnosti nez jinych.

A pak zde zustava oblast uplny magie, kdy se ti mozna ani nepodari 
zjistit, proc test funguje zatimco to hlavni co te zajima nefunguje 
(nebo obracene). Jen to tak proste bude. To je uz zminovany pripad, kdy 
neprochazi TCP, ale traceroute ano, a co vic, ten traceroute zpusobi, ze 
to TCP zacne fungovat taky.

> Zkratka pokud chces spolehlive monitorovat dostupnost nejake sluzby,
> musis monitorovat prave tu sluzbu a ne zkouset jinym protokolem neco
> jineho.

Prave tak. Ten test by mel byt co mozna nejpodobnejsi tomu, co testujes.

Kdysi jsme tu meli moc pekny pripad, kdy NFS klientovi nebyly z NFS 
serveru dostupne konkretni soubory. Zatimco jine soubory byly dostupne 
bez problemu. A nakonec to byla chyba firmware lokalniho switche.

Dokonale identicky test nejspis nepostavis, ale cim mene podobny bude 
tomu co te ve skutecnosti zajima, tim vetsi sance, ze odpoved, kterou 
dostanes bude na to, na co jsi se ptal, nikoliv na to, co ses cvhtel 
dozvedet.

Dan