Състояние на проксито: кой сайт и коя операция тествахте?
Разделяйте общата достъпност на проксито от отказите, специфични за дестинацията, когато поддържате пул от проксита за многократна употреба.
Проксито извлича вашата страница за проверка на IP и се проваля при API, който приложението ви изисква. Да го наречете „здраво“ или „мъртво“ губи най-полезния факт: двете заявки са били различни.
Започнете със запис за целия транспорт на крайната точка. Можете ли да достигнете слушателя ѝ и да завършите необходимото прокси-уговаряне? Пазете наблюденията, специфични за дестинацията, до този запис, вместо да го презаписвате.
| Наблюдение | Обхват за разследване |
|---|---|
| Слушателят на проксито отказва връзки | Крайната точка и маршрутът до нея |
| Проксито отказва един порт на дестинация | Разрешената операция за тази дестинация |
| Един сайт връща грешка в акаунта | Приложението на дестинацията и идентификационните данни |
| Големите отговори спират, малките завършват | Обемът на трансфера и политиката за изчакване |
HTTP отговор може да установи, че път на заявка е върнал нещо, като същевременно остава неизползваем за приложението. Пазете успеха на транспорта, HTTP статуса и очакваното съдържание като отделни резултати.
Ако една дестинация се проваля многократно, спрете или разследвайте тази двойка крайна точка–дестинация. Изключването на проксито за всяка несвързана задача може да изхвърли полезен капацитет. Обратно, глобален отказ на връзката не бива да остава скрит зад изолирания запис на един сайт.
Практичен ключ за състоянието може да включва идентификатора на проксито, услугата на дестинацията и типа операция. Избягвайте да използвате целия URL с идентификационни данни или всеки уникален път на ресурс като постоянно растящ ключ. Групирайте само там, където групирането дава смислена прогноза за следващата заявка.
Целта е по-добри доказателства за маршрутизирането, а не по-голяма колекция от зелени значки. Резултатът за състоянието трябва да казва какво е било опитано, кога и какво действително е установено.