Простой ICMP мониторинг на Python c сохранением данных в БД для Grafana.

Появилась задача помониторить внешние ресурсы на доступность простым ICMP опросом. Но данное решение как вы понимаете подойдет и для решения мониторинга узлов внутренней сети, короче говоря всего, что вы можете попинговать :) 

У меня уже была поднята Grafana и influxdb - эта база данных идеально подходит для сбора и хранения подобных данных. Основным назначением является хранение больших объемов данных с метками времени.

И нам осталось только написать скрипт который будет опрашивать данные, и записывать их в БД. А настройки графаны для вывода графиков буду интуитивно понятны.

Для поддержания скрипта в постоянно рабочем состоянии я использую демон  supervisorctl, но если уверены в стабильности вашей системы можно просто в screen запускать, тут уж на ваш вкус.

Сам скрипт таков:

from ping3 import ping, verbose_ping

from influxdb import InfluxDBClient

import datetime                                                                                                                                                                                                                                 

host='localhost'

port=8086 

user='ping'                                                                                                            

password='ping'

dbname='pingdb'

client = InfluxDBClient(host, port, user, password, dbname)

  servers = ['yandex.ru', 'vk.com', 'yota.ru', 'instagram.com', 'ok.ru']

def pingserver(server):

    try:

        return ping(server)*1000

    except:

        return 0.0

while True:

    now = datetime.datetime.now()

    for server in servers:

        pingdata = [{

            "measurement": "obit",

            "tags": {

                "host": server,

            },

            "time": now.strftime("%Y-%m-%d %H:%M:%S"),

            "fields": {

            "ping": pingserver(server)

            }

        }]

        print(pingdata)

        client.write_points(pingdata)

Traceroute лжет! Типичная неверная интерпретация результата.

Иногда пользователи с проблемами доступности определенных узлов, с гордостью предоставляют мне результаты трассировки маршрута (traceroute) и указывают на определенный узел, обвиняя его в высокой задержке соединения. В одном случае из тысячи это действительно так. Однако в остальных 999... Пожалуйста, позвольте мне объяснить.

Вывод traceroute
Перед вами типичный вывод traceroute, который может быть отправлен пользователем (IP и имена хостов изменены, чтобы не подвергать опасности непричастных):

$ traceroute www-europe
traceroute to www-europe (18.9.4.17), 64 hops max, 52 byte packets
 1  gateway (57.239.196.133)          11.447 ms   18.371ms    25.057 ms
 2  us-atl-edge (137.16.151.202)      13.338 ms   20.070 ms   19.119 ms
 3  us-ga-core (57.239.129.37)       103.789 ms  105.998 ms  103.696 ms
 4  us-nyc-core (57.239.128.189)     107.601 ms  103.116 ms  103.934 ms
 5  us-east-core (57.239.13.42)      103.099 ms  104.215 ms  109.042 ms
 6  us-east-bb1 (57.239.111.58)      107.824 ms  104.463 ms  103.482 ms
 7  uk-south-bb1 (57.240.117.81)     106.439 ms  111.156 ms  104.761 ms
 8  uk-south-core (57.240.117.61)    103.408 ms  104.430 ms  103.277 ms
 9  uk-london-core (57.240.132.178)  131.883 ms  104.071 ms  104.161 ms
10  uk-london-edge (99.88.4.133)     104.642 ms  105.685 ms  106.011 ms
11  www-europe (18.9.4.17)           103.465 ms  103.630 ms  104.228 ms

Смотрите! Пользователь негодует, причина явно между узлами us-alt-edge и us-ga-core (узлы #2 и #3), потому что задержка между ними возрастает с 20 мс до 105 мс!

Нет, это не так.

Разве не странно, между двумя узлами находящимися в региональной близости задержка увеличивается на 90 мс, а между узлами 6 и 7 разделенными океаном(зачастую исходя из названия узлов можно судить о их региональной принадлежности) задержка практически не увеличивается? На самом деле, разве не странно, что задержка после третьего узла примерно одинаковая?

Я знаю, многие читатели уже поняли почему так получается, но для тех, кто не понял(и в этом нет ничего позорного): такие результаты трассировки говорят о том, что на пути маршрута встречается MPLS сеть, а MPLS Provider edge (PE) является маршрутизатор на втором узле.

Почему так?
Помните, что одно из преимуществ MPLS сети в том, что ядро MPLS сети (PE или P узел) ничего не должно знать о конечных точках маршрута. Есть всего две вещи о которых должны знать P узлы MPLS сети:
1. Где все остальные узлы MPLS сети (обычно для этого используют OSPF или IS-IS протоколы маршрутизации)
2. Куда пересылать входящие фреймы MPLS на основании указанных меток.
Обычно это довольного "глупое" активное оборудование, но это позволяет им гораздо быстрее передавать трафик, нежели роутерам с IP маршрутизацией. Так в чем же проблема?

В своей работе traceroute полагается на отправленные пакеты с включенным TTL; когда TTL истекает, обычно устройство на котором он истек отправляет ICMP-сообщение источнику, предупреждая, что TTL истек в пути, именно так traceroute узнает о каждом узле в пути маршрута. Посмотрев на иллюстрацию MPLS сети предоставленную выше, что происходит когда TTL истекает на Р-маршрутизаторе? Р-маршрутизаторы ничего не знают о пограничных сетях(за пределами MPLS сети), поэтому никак не сможет направить ICMP-сообщение обратно к источнику, о котором не знает. Метки MPLS несут в себе информацию только об одном направлении(к месту назначения), поэтому P-маршрутизатор делает единственное, что может: добавляет к исходящей метке, которую собирается использовать и создает новый MPLS фрейм содержащий ICMP TTL Exiped и этот фрейм полностью(без именений в TTL) передается на PE-маршрутизатор (в указанном примере это PE-B).
PE-B получает фрейм, просматривает ICMP-сообщение внутри него и просматривает адрес получателя, т.е. моего компьютера(адрес машины на которой запущен traceroute). Как полагается PE-маршрутизатору, он знает, как добраться до моего компьютера(т.е. какой ярлык использовать для отправки пакета в сеть MPLS), упаковывает ICMP-пакет внутри MPLS и отправляет его обратно.
Другими словами, любые сообщения ICMP TTL Expired, сгенерированные в сети MPLS, фактически проходят все узлы MPLS сети, а затем назад, без изменений. В указанном примере они одинаково большие, потому что приходится пройти из США в Великобританию, а затем из Великобритании в США, чтобы вернуться на мой компьютер.

Если вы не видели подобного раннее, то можете потратить очень много времени на устранение проблем, которых в действительности нет.

Замечание: не все MPLS-сети будут передавать TTL входящего пакета в MPLS фрейм, поэтому TTL не всегда истекает в глубине MPLS сети. В таком случае, MPLS сеть может выглядеть как один скачок (hop) ICMP-пакета, поэтому не всегда будет понятен путь прохождения запроса внутри MPLS сети.

Перевод статьи: http://movingpackets.net/2017/10/06/misinterpreting-traceroute