По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Привет! Сегодня в статье мы покажем, как собирать трейсы с Cisco Unified Communications Manager (CUCM) . Это используется для траблшутинга системы, а так же эта информация будет необходима TAC инженерам Cisco при заведении заявки.
Для того чтобы снять трейсы нам понадобится программа Real-Time Monitoring Tool. О том как ее установить можно прочитать в нашей статье.
Сначала идем в меню Cisco Unified Serviceability, и переходим во вкладку Trace → Configuration. Здесь выбираем наш сервер, в строке Server, в строке Service Group выбираем CM Services, а в строке Service указываем Cisco CallManager. Дефолтные настройки показаны на скриншоте.
Убедитесь, что галочка стоит в пункте Trace On, а в выпадающем меню Debug Trace Level выбран пункт Detailed.
Тоже самое нужно повторить на других серверах кластера, если они имеются.
Далее запускаем RTMT и подключаемся к нашему серверу. Тут переходим во вкладку System → Tools → Trace & Log Central. Нажимаем Collect Files и в открывшемся окне ставим галочки в строке Cisco CallManager выбрав необходимые сервера.
Нажимаем Next и в следующем окне ставим галочки в пунктах Event Viewer → Application Log и Event Viewer → System Log.
Далее необходимо выбрать временной промежуток снятия наших данных в поле Collection Time. В этом же окне, в поле Download File Options указываем папку, в которою все будет скачиваться.
Теперь можно нажать Finish и после сбора информации нужные нам файлы окажутся в указанной ранее папке.
Семантическое управление версиями (или семвер) – это формальное соглашение для определения номера версии новых выпусков программного обеспечения. Стандарт помогает пользователям программного обеспечения понять серьезность изменений в каждом новом дистрибутиве.
Проект, использующий семантическое управление версиями, объявляет основной номер версии (major), дополнительный номер версии (minor) и номер исправления (patch) для каждого выпуска. Строка версии 1.2.3 указывает на основную версию под номером 1, дополнительную версию под номером 2 и исправление под номером 3.
Номера версий такого формата широко используются как программными пакетами, так и исполняемыми файлами конечных пользователей, такими как приложения и игры. Однако не каждый проект точно следует стандарту, установленному semver.org.
Спецификация была создана для решения проблем, вызванных несовместимостью методов управления версиями между программными пакетами, используемыми в качестве зависимостей. Под «пакетом» и «зависимостью» мы подразумеваем библиотеку кода, предназначенную для использования в другом программном проекте и распространяемую диспетчером пакетов, таким как npm, composer или nuget. Это именно то применение семантического управления версиями, которое мы рассматриваем в этой статье.
Major, Minor и Patch
Важно понимать значение трех задействованных компонентов. Вместе они намечают путь разработки проекта и соотносят влияние каждого нового выпуска на конечных пользователей.
Major number (основной номер версии) – основной номер указывает на текущую версию общедоступного интерфейса пакета. Он увеличивается каждый раз, когда вы вносите изменения, которые требуют от существующих пользователей вашего пакета обновления их собственной работы.
Minor number (дополнительный номер версии) – дополнительный номер указывает на текущую функциональную версию вашего программного обеспечения. Он увеличивается всякий раз, когда вы добавляете новую функцию, но не меняете интерфейс вашего пакета. Он сообщает пользователям о том, что были внесены значительные изменения, но пакет полностью совместимым с предыдущими версиями с предыдущим дополнительным номером.
Patch number (номер исправления) – номер исправления увеличивается каждый раз, когда вы вносите какое-то незначительное изменение, которое не влияет на общедоступный интерфейс или общую функциональность вашего пакета. Его чаще всего используют для исправления ошибок. Потребители всегда должны иметь возможность не задумываясь установить последнюю версию исправлений.
Семантическая структура версии выпуска лучше всего моделируется в виде дерева. Наверху у вас изменения общедоступного интерфейса, каждое из которых отображается на основном номере. Каждая основная версия имеет свой собственный набор дополнительных версий, в которые добавляются новые функции без нарушения совместимости с предыдущими версиями. И наконец, дополнительные версии могут время от времени отлаживаться путем исправления некоторых ошибок.
Откуда начинать?
Большинство проектов должны начинаться с версии 1.0.0. Вы публикуете свой первый общедоступный интерфейс и первоначальный неизмененный набор функций. И поскольку вам еще не приходилось вносить никаких исправления, то и версия исправления – 0.
Теперь давайте посмотрим, что же происходит, когда вы вносите изменения в свой пакет. После вашего первоначального выпуска вы получаете отчет об ошибке от пользователя. Когда вы выпустите исправление, то правильный номер версии уже будет 1.0.1. Если бы вы затем выпустили еще одну версию с исправлением ошибок, то вы бы увеличили номер исправления до 2, т.е. номер версии уже был бы 1.0.2.
Тем временем вы также работали над новой интересной функцией. Это совершенно необязательно, поэтому пользователям не нужно ничего делать для обновления. Вы выпускаете эту версию как 1.1.0. – создана новая функциональная среда, но ее еще ни разу не исправляли. К сожалению, скоро приходят отчеты об ошибках, и среди ваших пользователей начинает распространяться версия 1.1.1.
Несколько месяцев спустя вы решили провести реорганизацию кода всего проекта. Некоторые функции были удалены или теперь доступны через объединенный интерфейс. Если вы выпустите эту работу, то люди, использующие текущую версию вашего пакета, должны будут внести серьезные изменения в свой проект. Пришло время опубликовать 2.0.0. в вашем репозитории пакетов.
Поддержание старых веток
Увеличение какого-либо номера в вашей строке версий не создает точку невозврата. После публикации 1.1.1 вы могли обнаружить ошибку, присутствующую в 1.0.2. Используя ветки в вашей системе контроля версий, вы можете произвести исправления в обеих версиях. В итоге вы получите 1.1.2 и 1.0.3.
Точно также вы можете поддерживать ветку 1.х вашего проекта, несмотря на выпуск 2.0.0. Может показаться странным публиковать 1.1.2 после 2.0.1, но это вполне нормальная практика. Семантическое управление версиями не создает линейный постоянно увеличивающийся номер версии; наоборот, оно предназначено для использования в качестве части модели разработки ветвления, которое использует простоту установки исправлений, предлагаемую системами управления исходным кодом, такими как Git.
Опубликованные версии должны быть неизменяемыми. После того, как вы создали версию 2.4.3, вы не можете «обновить» его, просто добавив дополнительный код в ту же строку версии. Вы должны присваивать новый номер версии каждому выпуску, чтобы пользователи всегда могли получить доступ к каждой конкретной версии вашего пакета.
Обработка пакетов, находящихся в стадии разработки
Как правило, вы всегда обновляете основную версию своего пакета всякий раз, когда вносятся изменения, несовместимые с предыдущими версиями. Когда вы находитесь в стадии разработки, то ваша кодовая база может дорабатываться очень быстро, что приводит к публикации множества основных версий.
Вы можете этого избежать, рекламируя свой проект как 0.y.z. Значение 0 в качестве основной версии означает, что ваш пакет неустойчив. Обычные правила в отношении совместимости с предыдущими версиями тут не применяются, поэтому вы можете выпускать новые версии, увеличивая только дополнительный номер и номер исправления. Это значит, что вы можете использовать 1.0.0 для обозначения первой «завершенной» версии вашего программного обеспечения.
Вы также можете добавить дополнительные «идентификаторы» в конец строки версии, используя дефис в качестве разделителя: 1.0.0-alpha.1. Вы можете использовать такой вариант для того, чтобы четко обозначить альфа- и бета-версии. Точно также вы можете включить метаданные сборки, добавив символ +: 1.1.0-alpha.1+linux_x86.
Заключение
Согласованное использование семантического управления версиями помогает пользователям быть уверенными в вашем проекте. Они могут четко видеть, как развивается ваша кодовая база и нужно ли им самим провести какую-то работу, чтобы идти в ногу со временем.
Объявление строки семантической версии необходимо при публикации в диспетчере наиболее популярных пакетов. Тем не менее, в конечном счете, вам решать, какие номера вы устанавливаете для каждого нового выпуска. Соблюдение стандарта четко сообщает о ваших намерениях пользователям и сводит к минимуму риск непреднамеренного нарушения чужой работы.
В последние годы рынок программного обеспечения прогрессирует ударными темпами. Чтобы удержаться на плаву, компании-разработчики программного обеспечения постоянно разрабатывают новые решения и совершенствуют уже существующее программное обеспечение. И если в первом случае анализируются желания, озвучиваемые пользователями, то во втором более эффективным методом сбора данных оказывается телеметрия.
Что же это такое? Говоря по-простому, сетевая телеметрия — это процесс автоматизированного сбора данных, их накопление и передача для дальнейшего анализа. Если говорить о программном обеспечении, то анализ проводится разработчиками софта с целью оптимизации существующих программ, либо разработки и внедрения новых решений. Телеметрия в сети осуществляется посредством сбора данных с использованием сетевого протокола NetFlow или его аналогов.
Зачем же нужен NetFlow?
Сетевой протокол NetFlow был разработан в конце прошлого века компанией Cisco. Изначально он использовался как программа-распределитель пакетов данных для оптимизации работы маршрутизаторов, однако с течением времени она была заменена на более эффективную программу. Тем не менее, такой функционал, как сбор полезной статистики по использованию сетевого трафика и поныне оставляет Netflow актуальным. Правда, специализация этого протокола уже не соответствует исходной. Тем не менее, Netflow обладает функционалом, который невозможно реализовать, применяя альтернативные сетевые технологии.
Система постоянного наблюдения за работой сетевых приложений и действиями пользователей;
Сбор и учет информации об использовании сетевого трафика;
Анализ и планирование развития сети;
Распределение и управление сетевым трафиком;
Изучение вопросов сетевой безопасности;
Хранение собранных посредством телеметрии данных и их итоговый анализ;
Хотя уже существуют программные решения, обладающие схожим функционалом, решение от компании Cisco до сих пор остается одним из лучших в этой сфере. Кстати, теперь это решение называется Cisco Stealthwatch и на 95% обладает функционалом для решения исключительно задач, связанных с информационной безопасностью.
Отметим, что технологию сбора данных посредством NetFlow поддерживают не все роутеры или коммутаторы. Если Ваше устройство имеет поддержку данного протокола, то оно будет замерять проходящий трафик и передавать собранные данные в NetFlow-коллектор для последующей обработки. Передача будет осуществляться в формате датаграмм протокола UDP или пакетов протокола SCTP, поэтому на скорость работы интернета существенным образом это не повлияет.
В настоящее время решения NetFlow (как и многих других приложений) подразделяются на три типа:
Базовые технологии. Отличаются низкой ценой и довольно скудным функционалом анализа сетевого трафика. Тем не менее, для большинства пользователей или же для изучения технологии этого вполне достаточно
«Продвинутые» корпоративные варианты. Здесь базовый функционал дополнен более широким набором инструментов для предоставления расширенной отчетности анализа данных. Также эти решения содержат готовые модели оптимизации для разных сетевых устройств.
«Флагманские» корпоративные решения. Отличаются наивысшей ценой, однако при этом и наиболее широким функционалом, а также позволяют осуществлять мониторинг информационной безопасности в крупных организациях.
«А как же быть с приватностью? Ведь сбор данных ставит под угрозу частную жизнь пользователей, тайну переписки, личные сообщения и прочее» - спросит беспокойный читатель. Согласно политике приватности компании Cisco, персональные данные пользователей остаются в полной безопасности. Посредством телеметрии NetFlow анализируется исключительно передача сетевого трафика, не угрожая приватности пользователей.
Примеры решений
Также приведем несколько самых популярных сетевых анализаторов, работающих под протоколом NetFlow:
Solarwinds NetFlow Traffic Analyzer – мощный инструмент для анализа динамики трафика в сети. Программа осуществляет сбор, накопление и анализ данных, выводя их в удобном для пользователя формате. При этом можно проанализировать поведение трафика за определенные временные промежутки. Для ознакомления на сайте производителя доступна бесплатная 30-дневная версия
Flowmon – программа, предоставляющая комплекс инструментов для изучения пропускной способности сети, нагрузки на сеть в определенные периоды времени, а также обеспечения безопасности сети от DDOS-атак
PRTG Network Monitor - универсальное решение для сбора, хранения и обработки данных о поведении сети. В отличие от других подобных программ, данный инструмент работает на основе сенсоров – логических единиц, отвечающих за сбор данных по определенным аспектам изучаемого устройства.
ManageEngine NetFlow Analyzer – схожая с остальными по функционалу программа. Её выделяют из ряда других такие возможности, как гибкая настройка аналитики, а так же возможность мониторить поведение сети из любого места, благодаря приложению для телефона.
Как можно заметить, все вышеуказанные программы не только обладают схожим базовым функционалом, но и конкурируют между собой, продумывая и внедряя новые технические решения. Выбор, какой из нескольких десятков программ начать пользоваться – целиком и полностью дело конечного пользователя.