Обновление Briseis

Последние несколько недель активно работал над усовершенствованием своих проектов. Сначала хотел поправить что-то одно, но, как это бывает, потянешь за ниточку и размотаешь целый клубок работы. В конечном итоге обновил всё по чуть чуть. Среди приятных изменений скрипт запуска под Linux для каждого из сервисов.

В целом же хочу отметить существенную переработку проекта Briseis, предназначенного для сбора метрик с сетевого оборудования. Кстати, примерно те же задачи решает и swtoolz-core. Но если последний предназначен для опроса оборудования по требованию и выдаче результатов пользователю, то Briseis - для опроса по расписанию и отправке результатов в Graphite. А в остальном эти сервисы очень схожи и при написании swtoolz-core часть кода была позаимствована из Briseis. Теперь же исходный проект был исправлен таким образом, чтобы перенять подход swtoolz-core, оказавшийся в ряде случаев более удобным.

Что же именно поменялось в Briseis?

- Модели теперь определяются так же, как и в swtoolz-core
- Конфигурация теперь размещается в отдельных модулях, как у swtoolz-core
- Изменен принцип выбора набора метрик для каждой итерации
- Описание было существенно переработано

Что добавилось?

- Возможность отсылать метрики строго в одни и те же интервалы времени
- Возможность корректировать счетчики при обработке, что позволяет избежать всплесков на графиках
- Возможность выполнять walk-опросы раньше, чем set
- Возможность отправлять метрики на несколько серверов Graphite
- Возможность выполнять некоторые запросы без повторных попыток

Что это значит "на пальцах"?

Программа стала более удобной и понятной интуитивно. Если кто-то уже разобрался с swtoolz-core, то без проблем освоит и poller Briseis. Помимо этого расширились возможности программы, а отправка данных стала еще более управляемой. Это позволяет использовать одну инсталляцию сервиса для выполнения различных задач одновременно.

Как этот сервис используется в моей сети?

На данный момент в моей сети установлено почти 3500 коммутаторов доступа, с которых каждые 5 минут считывается достаточно большое число параметров. Непосредственно сам опрос занимает 50 секунд и за это время с устройств собирается около 668 000 метрик. Часть из них (291к) уходит на один сервер Graphite для хранения, а другая часть (473к) - на другой, используемый для поиска аномалий (некоторые метрики отправляются на оба сервера). Данные на первом сервере неделю хранятся в оперативной памяти и используются дли отрисовки таких вот картинок:

Вверху на этой картинке приведен график ошибок, а внизу - график загрузки порта. Такое расположение позволяет обнаруживать корреляцию между трафиком и возникающими ошибками. Программа научена распознавать аномальные изменения счетчиков и, если коммутатор перезагружается, то пиков на графика не появляется.

Помимо этого программа через определенные интервалы времени сохраняет конфигурацию всех коммутаторов, а также отправляет команды на выгрузку конфигурации на TFTP-сервер. Причем для разных моделей конфигурация выгружается в разное время, чтобы не создавать DoS-атаку на сервер.

Все работает быстро и стабильно, а самая длинная операция укладывается в 5 минут. Программа настроена так, чтобы данные в Graphite поступали через равные интервалы независимо от того, выполнился ли опрос оборудования быстро или медленно (в случае, когда идет сохранение конфигурации).

P.S. Ответ на вопрос "Почему опять что-то самописное, а не %ваша_любимая_NMS%?" такой:

- Мне так удобно! :)

Система работает надежно и полностью автономно. Всю работу делают два демона на Python, изначально рассчитанные на достаточно высокую (для ISP) нагрузку. Никакой особой производительностью хост-машина обладать не должна. Производительная СУБД не требуется, диски не надрываются. Поэтому поводов менять что-либо в системе опроса доступа пока не вижу.