Pora dorobić logowanie w skrypcie. Nie będę tu przepisywał tutoriali, więc jedynie odeślę do opisu logowania w Hitchhiker’s guide to Python oraz chyba nawet lepszego wpisu na temat dobrych praktyk logowania w Pythonie Docelowo konfiguracja logowania w pliku konfiguracyjnym. Waham się czy jednak syslog, czy może osobny plik, ale to jest detal.
Wczoraj w pociągu rozpisałem wstępnie, co chciałbym logować na poszczególnych poziomach i wyszło mi coś takiego:
WARNING/ERROR:
- błąd otwarcia lub parsowania pliku konfiguracyjnego
- nieistnienie interfejsu zdefiniowanego w pliku konfiguracyjnym
- błąd zwrócony przez skrypty pomocnicze
- brak skryptu pomocniczego, jeśli był zdefiniowany w pliku konfiguracyjnym[1]
- nieosiągalne IP[2]
INFO:
- znalezienie lepszej trasy i zmiana routingu, czyli podstawa
- ostateczna punktacja dla danego interfejsu (docelowo może w DEBUG?)
- znalezienie lepszej trasy, niż istniejąca, z pominięciem kosztu przełączenia[3]
DEBUG:
- chwilowe zmiany routingu per badane IP
- dane wczytane z konfiguracji
- parametry wywołania funkcji
- punktacja dla interfejsu z rozbiciem na składowe
- parametry wywołania skryptów pomocniczych
Domyślny loglevel to oczywiście INFO. Jeśli wszystko pójdzie OK,to zmiany pojawią się w repo dziś wieczorem – niestety czas goni, a dwa wpisy w tygodniu muszą być…
[1] Wybiegam w sekcję ogólną konfiguracji, która dopiero powstanie, o skryptach pomocniczych planuję napisać w kolejnym wpisie.
[2] Jeśli będzie często występowało, to warto je usunąć, żeby nie zaburzało wyników.
[3] W celu poinformowania użytkownika, że być może warto zmienić przy okazji konfigurację sieci.
Nie wiem czy dobre rozumiem założenia projektu. Są dwa interfejsy wyjściowe, do każdego z nich jest przypisany inny publiczny adres IP ?
Jak chcesz badać koszt trasy? tzn, dokąd ? do jakiegoś konkretnego ip ? do GW dla tego łącza ?
to że jakaś trasa będzie lepsza dla jednego operatora nie znaczy że wszystkie takie będą, bo po drodze może być jeszcze kilka hopów? Może mając dwa łącza lepiej podzielić ruch na oba niż przeznaczać jedno na faillover?
@4th4 Tak, dwa lub więcej interfejsów, w wariancie konsumenckim, czyli osobne adresy IP (niekoniecznie publiczne), bez BGP itd.
Jeśli chodzi o pytania, to zerknij na wcześniejsze posty z kategorii, zwł. rozie.blox.pl/2017/03/Wskazniki-jakosci-lacza.html i rozie.blox.pl/2017/03/Zalozenia-i-opis-projektu-abcc.html oraz i na przykładowy konfig github.com/rozie/abcc/blob/master/example.yaml
Generalnie dla każdej sieci (trasy, route) są definiowane osobne IP do których jest robiony pomiar, z określoną wagą. W wariancie minimum (patrz geneza) chodziło o ustawianie default routingu, ale implementuję to w taki sposób, że nic nie stoi na przeszkodzie, by routingi były ustawiane dla konkretnych prefiksów (patrz przykład). Więc tak, jeśli klient będzie miał potrzebę podzielić ruch, to może zdefiniować wiele tras, dla każdej sprawdzać inne IP, z innymi wagami i finalnie ustawić ruch do nich przez różne interfejsy.
Bardzo mi się podoba rozgraniczenie zawczasu co i gdzie będzie logowane. Trochę się już napisałem aplikacji backendowych i wtedy dobre logi to podstawa. Często niestety zdawałem sobie sprawę, gdy właśnie gdzieś jakiegoś istotnego, w danym przypadku brakowało i uczyłem się poprawiając je.
@Kuc Miło mi to słyszeć, choć przyznaję, że takie rozpisanie to raczej efekt uboczny tego, że czasu jest sporo, a spora część tworzenia odbywa się bez udziału komputera. W tym przypadku notowałem sobie w pociągu. 😉