идею с визуализацией можно развить и в этой плоскости, формируя объект топологии на основании связей и данных в Netbox, доставаемых через API. Экспериментами в этом направлении, скорее всего, и займусь.
В результате экспериментов в свободное время родилась бета-версия плагина для интеграции топологий напрямую в Netbox (функционал плагинов добавили недавно в версии 2.8.0).
Код выложил на GitHub, если кого-то заинтересует.
Это сильно зависит от применяемых на доступе технологий, типов клиентских устройств и т.д.
Для корпоративных доменных сетей минимально можно смотреть MAC-адреса на портах, по ним из ARP узнавать IP-адреса, а из IP-адресов пытаться ресолвить хостнеймы.
При внедренном 802.1x предсказуемость результата становится уже выше. И так с каждым дополнительным источником информации об устройствах.
Но сама задача, построения схемы на основе cdp/lldp мне кажется немного не нужной.
иногда получается слишком много соединений и все это трудно анализировать на схеме, в табличном виде лучше
Как и всегда, не существует универсальных решений. Инструменты хороши в совокупности, и схемы с таблицами обычно дополняют друг друга. LLPD/CDP же дает базовое понимание топологии, поверх него уже можно накладывать дополнительные слои, обогащать схему деталями по потребностям и визуализировать более сложные кейсы (например, визуализацию путей из моей прошлой статьи).
Для случаев с большим количеством линков и нод в NeXt UI, кстати, есть хороший функционал Node Sets (наборы нод), с помощью него можно группировать отдельные ноды и сворачивать их в одну пиктограмму (и разворачивать по клику) при визуализации.
нужен хороший источник sourth of truth, типа netbox или другой откуда брать информацию о линках и проверять их на правильность, используя похожий как увас скрипт. И должны быть схемы всей сети, нормальные, детальные с различными срезами и уровнями.
С необходимостью SoT в той или иной реализации полностью согласен. И идею с визуализацией можно развить и в этой плоскости, формируя объект топологии на основании связей и данных в Netbox, доставаемых через API. Экспериментами в этом направлении, скорее всего, и займусь. Если сообществу будет интересно, может, опубликую отдельную статью.
С учетом того, что у Netbox открытый код, можно даже интегрировать вкладку с визуализацией напрямую в его интерфейс (например, в /dcim/sites/$site_slug).
У меня есть другой скрипт(не совсем доработанный), который строит логическую схему сети третьего уровня, она более сложная задачка сама по себе, но им я пользуюсь более часто
Было бы интересно почитать статью с описанием подобного опыта. :)
Интересный опыт, спасибо.
И еще пара вопросов, если возможно.
Это netmiko, это pysnmp, это jinja2 и etc.
1. А Nornir не доводилось использовать? Не так давно для себя его обнаружил, выглядит многообещающе. Это дополнительная абстракция над netmiko и napalm с инвентори и мультитредингом.
2. Какой подход к безопасному хранению учеток/паролей и их импорту в скрипты используете в сетевой автоматизации?
Схема оклад+премия (квартальная, годовая) по собственному опыту и опыту знакомых практикуется многими крупными энтерпрайзами и телекомами. В особенности, на лидствующих и начальствующих позициях.
karaboz В этом случае сейчас следует указывать годовой доход, делённый на 12?
Было бы полезно сделать опцию с возможностью указания годового дохода (и окладной части по желанию).
Я ответил, что в данном примере разницы нет и оба True и даже попытался объяснить ему почему Python не C/C++.
Не могли бы раскрыть свою мысль и направить в документацию в правильном направлении?
На мой, не специализирующийся на Python, взгляд, вопрос имеет под собой почву:
a == b # сравнение по значению
a is b # сравнение по object id, на который ссылаются переменные
И в случае с мутабельными объектами разница может быть:
a = [1, 2, 3]
b = a # произойдет присвоение по ссылке
с = a.copy() # произойдет присвоение по значению
d = a[:] # произойдет присвоение по значению
# Значения всех трех переменных равны:
a == b # True
a == c # True
a == d # True
# Но переменные a и b ссылаются на один и тот же объект списка:
b is a # True
# А переменные c и d ссылаются на отдельные объекты:
c is a # False
d is a # False
# Модифицируем данные:
a.append(4)
b.append(5)
c.append(6)
d.append(7)
# И получим:
a == b # True
a == c # False
a == d # False
b is a # True
c is a # False
d is a # False
# Через переменные a и b был поочередно модифицирован один и тот же объект.
# Значения этих переменных по-прежнему равны:
a # [1, 2, 3, 4, 5]
b # [1, 2, 3, 4, 5]
# А для переменных c и d - нет:
c # [1, 2, 3, 6]
d # [1, 2, 3, 7]
Жарковато бывает редко, 5-6 дней за лето. Пляжи в получасе езды от Лиссабона. Широкие и не очень забиты людьми даже в выходные.
Стоит заметить, что вода довольно холодная (не больше 22°C в пике в августе).
Без гидрокостюма или подготовки может быть не очень комфортно.
А еще недалеко от Лиссабона есть деревня Назаре, где зимой, в сезон, приходят самые большие волны в мире, на которых катаются бигвейв-серферы (в том числе и российские). Мировые рекорды по размеру взятых волн (нынешний — 80футов/24,384м) поставлены именно там. Знакомые очевидцы этого зрелища очень советовали, планирую добраться по возможности.
Строго говоря, это не совсем так. 127.0.0.0/8 — это блок локалхост (localhost) адресов. А лупбеки (loopback) — это виртуальные интерфейсы, на которые могут назначаться любые unicast адреса, в т.ч. и локалхост. Но это может быть и, к примеру, адрес 1.2.3.4/32. Пакеты, приходящие на адреса лупбек интерфейсов, маршрутизируются хостом самому себе (отсюда и название). Адрес на лупбеке может быть доступен извне, для этого должен быть маршрут до него через адрес какой-либо из физических интерфейсов этого же хоста. Как правило, это используется для обеспечения доступности адресов и/или балансировки трафика.
Пример: на Шри-Ланку просто нет прямых рейсов из РФ
Или Москва — не Россия, или информация из статьи успела устареть в процессе написания. Аэрофлот чуть менее недели назад запустил прямые регулярные рейсы на Шри-Ланку, и АК Россия — на Бали в Индонезию. Что характерно, по ценам не сильно дороже альтернативных регулярных рейсов со стыковками через Дубай/Доху для Шри-Ланки и Сингапур для Бали. За вариантами по сёрф-направлениям регулярно слежу.
А по поводу интровертов и их soft skills интересный взгляд есть в книге Девора Зак «Нетворкинг для интровертов» («Networking for People Who Hate Networking: A Field Guide for Introverts, the Overwhelmed, and the Underconnected» by Devora Zack в оригинале).
Но вообще же разница между интровертами и экстравертами прежде всего в том, что вторые заряжаются при общении, а первые разряжаются
Для себя нашел еще одну аналогию: люди — это усилители. Не даром ведь существует выражение «на одной волне с кем-то». Экстраверты — широкополосные усилители. У них большой рабочий диапазон частот, т.е. им легче с ходу найти общий язык со многими. Интроверты же — узкополосные усилители, они резонируют с определенными категориями людей. Но ширина полосы обратно пропорциональна возможному коэффициенту усиления. Интроверты способны на кратно большую интенсивность в общении на своих рабочих частотах (попробуйте остановить интроверта, который рассказывает Вам что-то, что ему действительно интересно). Т.е. нужно учиться перестраиваться в некоторых границах и искать окружения единомышленников. И отдыхать, восстанавливаться, конечно.
Род задачи определяется точкой зрения на нее. Помимо внутренних служб, есть еще и внешние консультанты (интеграторы, вендорская техподдержка и т.д.). Для последних анализ и аудит сети, которую видишь впервые, явление несколько более частое. А доступ к оборудованию, как правило, сильно ограничен. Постановка задачи из статьи (напомню, сформулирована не мной) с этой перспективы более характерна и логична.
Кроме того, задача сводится к анализу не только префиксов/путей, а еще и маршрутов:
Пример:
PATHS TO 192.168.204.204 FROM csr1000v-01
Detailed info:
Path 1:
['csr1000v-01', 'csr1000v-03', 'csr1000v-04']
ROUTER: csr1000v-01
Matched route string:
D 192.168.204.0/24
[90/131072] via 192.168.13.203, 00:06:56, GigabitEthernet3
[90/131072] via 192.168.12.202, 00:06:56, GigabitEthernet2
ROUTER: csr1000v-03
Matched route string:
D 192.168.204.0/24
[90/130816] via 192.168.34.204, 00:37:22, GigabitEthernet2
ROUTER: csr1000v-04
Matched route string:
L 192.168.204.204/32 is directly connected, Loopback204
Path 2:
['csr1000v-01', 'csr1000v-02', 'csr1000v-04']
ROUTER: csr1000v-01
Matched route string:
D 192.168.204.0/24
[90/131072] via 192.168.13.203, 00:06:56, GigabitEthernet3
[90/131072] via 192.168.12.202, 00:06:56, GigabitEthernet2
ROUTER: csr1000v-02
Matched route string:
D 192.168.204.0/24
[90/130816] via 192.168.24.204, 00:37:26, GigabitEthernet3
ROUTER: csr1000v-04
Matched route string:
L 192.168.204.204/32 is directly connected, Loopback204
Path search on csr1000v-01 has been completed in 0.000 sec
Откуда сразу видим, что, скажем, на csr1000v-01 пакет на 192.168.204.204 уйдет по маршруту из EIGRP с двумя equal-cost (131072) next-hop'ами через 192.168.13.203 и 192.168.13.202.
D 192.168.204.0/24
[90/131072] via 192.168.13.203, 00:06:56, GigabitEthernet3
[90/131072] via 192.168.12.202, 00:06:56, GigabitEthernet2
И так далее по всей цепочке.
Даже если отбросить все ограничения выше, как добиться передачи аналогичной информации через (i)BGP?
Full View в изначальных условиях не было, я его привёл в пример лишь в качестве одного из наиболее частых и возможных случаев тяжёлых таблиц маршрутизации, чтобы обозначить верхнюю границу применимости скрипта не в попугаях.
Основная цель — узнать цепочку промежуточных устройств до любого адреса с любого из имеющихся устройств. Попутно анализируя, какими маршрутами пойдёт пакет (например, должен по EIGRP, а где-то не удаленная статика осталась и т.п.). Или альтернативно — узнать какие фаерволы нужно пройти по дороге.
Вариантов применимости может быть много. Первоначальную же постановку вопроса взял из топика на одном форуме, как и обозначил выше.
Во-первых, быстродействие, Go во много раз быстрее справляется с опросом маршрутизаторов, чем питон.
В задаче выше Питон для наиболее ресурсоемких частей кода является, если посмотреть чуть глубже, оберткой под C в модуле re и под C++ в модуле SubnetTree. Что вполне положительно сказывается на скорости работы скрипта.
Так что и производительность все же имеет смысл измерять и сравнивать под конкретные сценарии и ограничения.
И я выше сам оговорился: синхронизация в нулевом тайм-слоте в Е1, конечно же, цикловая.
И что же с многоканальностью?
Итак, имеем 2 факта:
Здесь по-моему нужно выделить несколько другие моменты:
1. Вызов на какой-то номер — это абстракция. Грубо говоря, это выглядит как «вызываемый номер Б -> маршрутизировать туда».
2. Реализация накладывается на физические (производительность оборудования, пропускная способность или емкость каналов связи и т.п.) и логические (количество линий по договору, возможности оборудования и ПО, логика маршрутизации и т.п.) ограничения операторских сетей и абонентских стыков.
«Туда» может быть как одной линией (физической или виртуальной), так и несколькими. А может быть и вовсе другим номером, если включена переадресация (безусловная или при занятости/переполнении).
К слову, абонентских стыков под один и тот же номер может быть энное количество по разным технологиям. Например, в сначала вызовы приходят в Е1, затем — в SIP-транк, а если первые два варианта недоступны — по старому медному многопарнику на FXO-порты. Как-то так обычно делается (гео)резервирование и отказоустойчивость.
По порядку и, по возможности, более конструктивно, чем оратор выше:
«Primary Rate Interface»: физический интерфейс с гарантированной доставкой пакетов и выделенными каналами по 64 килобита.
Поток E1/T1 — это коммутация каналов, а не пакетов. И никаких механизмов гарантированной доставки там нет.
от 4 до 16 E1-подключений, каждое из которых по 32 канала для голоса, несильно сжатого g.711 и сигнализации.
Во фрейме E1 30 тайм-слотов под голос, один под сигнализацию (16-й) и один под тактовую синхронизацию (0-й).
На почетном втором месте SIP со стыком через обычную ethernet-сеть или даже интернет.
И опять: «обычную Ethernet-сеть» нужно читать как «выделенный канал». В противовес публичному Интернет-каналу. На уровне L2/L1 доступ может предоставляться как угодно, лишь бы была IP-связность поверх. На то он и VoIP.
порядочность интернет-провайдеров, которые иногда настраивают QoS (но чаще – нет).
Интернет по своей природе не имеет никаких гарантий передачи данных и параметров качества обслуживания. Любой публичный трафик идет как best effort. Сетевой нейтралитет и все дела (его отмена местами — отдельная тема для разговора).
это номер сотового. Абонент сейчас уже говорит по телефону. Куда девать еще 10 входящих на этот же номер?
Внезапно, отправить на этот же сотовый второй линией или поставить в ожидание. Как Вы заметили, это логическое ограничение.
На практике можно ожидать корректную работу до 100 параллельных вызовов на один номер.
Только стоит обозначить, что это именно ваша практика. Колл-центры федерального масштаба могут иметь в разы больший поток вызов и количество линий для них.
Разделение на «городской номер», «ABC географически определенный номер», «мобильный номер», «DEF географически неопределенный номер» — оно условное. Не более чем договоренности операторов о формате и кто кому сколько будет платить за обслуживание данного конкретного номера
Есть в РФ такое Министерство Информационных Технологий и Связи, и все «не более чем договоренности» регулируются на уровне Приказов и Федеральных Законов, за нарушение которых провайдер может остаться слегка без лицензии. Географически определяемые номера законодательно привязаны к региону (отсюда и название), провайдер из Москвы не может дать номер в ABC-коде 495 абоненту из Владивостока. На DEF подобное ограничение не распространяется.
Что там будет написано: «84951234567», "+79261234567" или что еще — это уже как договорятся операторы и регуляторы в конкретной стране и регионе. И да, единого стандарта «на весь мир» у нас нету.
Увольняли по сокращению в нестабильном конце 2014 года. ИТ-Директор вызвал к себе, объяснил, что в Регионе принято решение подсократить российский ИТ-штат и перераспределить обязанности (это было подразделение международной промышленной компании, я там сисадминил), что претензий к моей работе нет, и могут, при необходимости, дать рекомендации. Предложили по соглашению сторон через месяц, аккурат с Нового Года, стать свободным человеком с тремя дополнительными окладами на карточке, разрешили до момента увольнения свободно ходить по собеседованиям в рабочее время.
Спустя почти три года могу сказать, что это увольнение в разгар кризиса под Новый Год — лучшее, что со мной случалось в карьерном плане в той компании даже с учётом попадания в техподдержку с нулем опыта и повышением до младшего сисадмина после 9.5 месяцев работы: на новом месте ушёл в специализацию по UC и сетям от энтерпрайзного шиваадминства, имею бОльшую инфраструктуру в зоне ответственности с задачами и должностью иного уровня, плюс значительно возросший доход. Но это совсем другая история.
А как бы Вы оценили плюсы и минусы реализации обозначенной в статье задачи на ELK относительно Splunk?
Одному_моему_другу приснилось доводилось делать очень похожее решение как раз на ELK: CDR'ы по SFTP с CUCM грузятся на сервер, разбираются в Logstash и складываются в индексы на Elasticsearch. На Kibana собраны дашборды под возникшие нужды. Большинство визуализаций создается в пару кликов. Дашборды можно генерировать динамически, есть возможность их вставки через iframe в сторонние ресурсы.
Плюс базовый ELK бесплатен без ограничений на объемы информации и количество нод в кластере (в противовес стоимости on-premise железа у Elastic, если мне не изменяет память, есть и SaaS-опции).
Код выложил на GitHub, если кого-то заинтересует.
Для корпоративных доменных сетей минимально можно смотреть MAC-адреса на портах, по ним из ARP узнавать IP-адреса, а из IP-адресов пытаться ресолвить хостнеймы.
При внедренном 802.1x предсказуемость результата становится уже выше. И так с каждым дополнительным источником информации об устройствах.
Как и всегда, не существует универсальных решений. Инструменты хороши в совокупности, и схемы с таблицами обычно дополняют друг друга. LLPD/CDP же дает базовое понимание топологии, поверх него уже можно накладывать дополнительные слои, обогащать схему деталями по потребностям и визуализировать более сложные кейсы (например, визуализацию путей из моей прошлой статьи).
Для случаев с большим количеством линков и нод в NeXt UI, кстати, есть хороший функционал Node Sets (наборы нод), с помощью него можно группировать отдельные ноды и сворачивать их в одну пиктограмму (и разворачивать по клику) при визуализации.
С необходимостью SoT в той или иной реализации полностью согласен. И идею с визуализацией можно развить и в этой плоскости, формируя объект топологии на основании связей и данных в Netbox, доставаемых через API. Экспериментами в этом направлении, скорее всего, и займусь. Если сообществу будет интересно, может, опубликую отдельную статью.
С учетом того, что у Netbox открытый код, можно даже интегрировать вкладку с визуализацией напрямую в его интерфейс (например, в /dcim/sites/$site_slug).
Было бы интересно почитать статью с описанием подобного опыта. :)
И еще пара вопросов, если возможно.
1. А Nornir не доводилось использовать? Не так давно для себя его обнаружил, выглядит многообещающе. Это дополнительная абстракция над netmiko и napalm с инвентори и мультитредингом.
2. Какой подход к безопасному хранению учеток/паролей и их импорту в скрипты используете в сетевой автоматизации?
Схема оклад+премия (квартальная, годовая) по собственному опыту и опыту знакомых практикуется многими крупными энтерпрайзами и телекомами. В особенности, на лидствующих и начальствующих позициях.
karaboz В этом случае сейчас следует указывать годовой доход, делённый на 12?
Было бы полезно сделать опцию с возможностью указания годового дохода (и окладной части по желанию).
В чем в примере выше ошибка по существу?
Был бы признателен за конструктивную критику.
На мой, не специализирующийся на Python, взгляд, вопрос имеет под собой почву:
И в случае с мутабельными объектами разница может быть:
Без гидрокостюма или подготовки может быть не очень комфортно.
А еще недалеко от Лиссабона есть деревня Назаре, где зимой, в сезон, приходят самые большие волны в мире, на которых катаются бигвейв-серферы (в том числе и российские). Мировые рекорды по размеру взятых волн (нынешний — 80футов/24,384м) поставлены именно там. Знакомые очевидцы этого зрелища очень советовали, планирую добраться по возможности.
Для себя нашел еще одну аналогию: люди — это усилители. Не даром ведь существует выражение «на одной волне с кем-то». Экстраверты — широкополосные усилители. У них большой рабочий диапазон частот, т.е. им легче с ходу найти общий язык со многими. Интроверты же — узкополосные усилители, они резонируют с определенными категориями людей. Но ширина полосы обратно пропорциональна возможному коэффициенту усиления. Интроверты способны на кратно большую интенсивность в общении на своих рабочих частотах (попробуйте остановить интроверта, который рассказывает Вам что-то, что ему действительно интересно). Т.е. нужно учиться перестраиваться в некоторых границах и искать окружения единомышленников. И отдыхать, восстанавливаться, конечно.
Кроме того, задача сводится к анализу не только префиксов/путей, а еще и маршрутов:
PATHS TO 192.168.204.204 FROM csr1000v-01
Detailed info:
Path 1:
['csr1000v-01', 'csr1000v-03', 'csr1000v-04']
ROUTER: csr1000v-01
Matched route string:
D 192.168.204.0/24
[90/131072] via 192.168.13.203, 00:06:56, GigabitEthernet3
[90/131072] via 192.168.12.202, 00:06:56, GigabitEthernet2
ROUTER: csr1000v-03
Matched route string:
D 192.168.204.0/24
[90/130816] via 192.168.34.204, 00:37:22, GigabitEthernet2
ROUTER: csr1000v-04
Matched route string:
L 192.168.204.204/32 is directly connected, Loopback204
Path 2:
['csr1000v-01', 'csr1000v-02', 'csr1000v-04']
ROUTER: csr1000v-01
Matched route string:
D 192.168.204.0/24
[90/131072] via 192.168.13.203, 00:06:56, GigabitEthernet3
[90/131072] via 192.168.12.202, 00:06:56, GigabitEthernet2
ROUTER: csr1000v-02
Matched route string:
D 192.168.204.0/24
[90/130816] via 192.168.24.204, 00:37:26, GigabitEthernet3
ROUTER: csr1000v-04
Matched route string:
L 192.168.204.204/32 is directly connected, Loopback204
Path search on csr1000v-01 has been completed in 0.000 sec
И так далее по всей цепочке.
Даже если отбросить все ограничения выше, как добиться передачи аналогичной информации через (i)BGP?
Full View в изначальных условиях не было, я его привёл в пример лишь в качестве одного из наиболее частых и возможных случаев тяжёлых таблиц маршрутизации, чтобы обозначить верхнюю границу применимости скрипта не в попугаях.
Основная цель — узнать цепочку промежуточных устройств до любого адреса с любого из имеющихся устройств. Попутно анализируя, какими маршрутами пойдёт пакет (например, должен по EIGRP, а где-то не удаленная статика осталась и т.п.). Или альтернативно — узнать какие фаерволы нужно пройти по дороге.
Вариантов применимости может быть много. Первоначальную же постановку вопроса взял из топика на одном форуме, как и обозначил выше.
Так что и производительность все же имеет смысл измерять и сравнивать под конкретные сценарии и ограничения.
Здесь по-моему нужно выделить несколько другие моменты:
1. Вызов на какой-то номер — это абстракция. Грубо говоря, это выглядит как «вызываемый номер Б -> маршрутизировать туда».
2. Реализация накладывается на физические (производительность оборудования, пропускная способность или емкость каналов связи и т.п.) и логические (количество линий по договору, возможности оборудования и ПО, логика маршрутизации и т.п.) ограничения операторских сетей и абонентских стыков.
«Туда» может быть как одной линией (физической или виртуальной), так и несколькими. А может быть и вовсе другим номером, если включена переадресация (безусловная или при занятости/переполнении).
К слову, абонентских стыков под один и тот же номер может быть энное количество по разным технологиям. Например, в сначала вызовы приходят в Е1, затем — в SIP-транк, а если первые два варианта недоступны — по старому медному многопарнику на FXO-порты. Как-то так обычно делается (гео)резервирование и отказоустойчивость.
Поток E1/T1 — это коммутация каналов, а не пакетов. И никаких механизмов гарантированной доставки там нет.
Во фрейме E1 30 тайм-слотов под голос, один под сигнализацию (16-й) и один под тактовую синхронизацию (0-й).
И опять: «обычную Ethernet-сеть» нужно читать как «выделенный канал». В противовес публичному Интернет-каналу. На уровне L2/L1 доступ может предоставляться как угодно, лишь бы была IP-связность поверх. На то он и VoIP.
Интернет по своей природе не имеет никаких гарантий передачи данных и параметров качества обслуживания. Любой публичный трафик идет как best effort. Сетевой нейтралитет и все дела (его отмена местами — отдельная тема для разговора).
Внезапно, отправить на этот же сотовый второй линией или поставить в ожидание. Как Вы заметили, это логическое ограничение.
Только стоит обозначить, что это именно ваша практика. Колл-центры федерального масштаба могут иметь в разы больший поток вызов и количество линий для них.
Есть в РФ такое Министерство Информационных Технологий и Связи, и все «не более чем договоренности» регулируются на уровне Приказов и Федеральных Законов, за нарушение которых провайдер может остаться слегка без лицензии. Географически определяемые номера законодательно привязаны к региону (отсюда и название), провайдер из Москвы не может дать номер в ABC-коде 495 абоненту из Владивостока. На DEF подобное ограничение не распространяется.
E.164 от ITU-T?
Увольняли по сокращению в нестабильном конце 2014 года. ИТ-Директор вызвал к себе, объяснил, что в Регионе принято решение подсократить российский ИТ-штат и перераспределить обязанности (это было подразделение международной промышленной компании, я там сисадминил), что претензий к моей работе нет, и могут, при необходимости, дать рекомендации. Предложили по соглашению сторон через месяц, аккурат с Нового Года, стать свободным человеком с тремя дополнительными окладами на карточке, разрешили до момента увольнения свободно ходить по собеседованиям в рабочее время.
Спустя почти три года могу сказать, что это увольнение в разгар кризиса под Новый Год — лучшее, что со мной случалось в карьерном плане в той компании даже с учётом попадания в техподдержку с нулем опыта и повышением до младшего сисадмина после 9.5 месяцев работы: на новом месте ушёл в специализацию по UC и сетям от энтерпрайзного шиваадминства, имею бОльшую инфраструктуру в зоне ответственности с задачами и должностью иного уровня, плюс значительно возросший доход. Но это совсем другая история.
Одному_моему_другу
приснилосьдоводилось делать очень похожее решение как раз на ELK: CDR'ы по SFTP с CUCM грузятся на сервер, разбираются в Logstash и складываются в индексы на Elasticsearch. На Kibana собраны дашборды под возникшие нужды. Большинство визуализаций создается в пару кликов. Дашборды можно генерировать динамически, есть возможность их вставки через iframe в сторонние ресурсы.Плюс базовый ELK бесплатен без ограничений на объемы информации и количество нод в кластере (в противовес стоимости on-premise железа у Elastic, если мне не изменяет память, есть и SaaS-опции).