По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Что это за странные названия - Elasticsearch, Logstash и Kibana? На сегодняшний день разработка программного обеспечения одна из наиболее широких и динамично развивающихся сфер деятельности человечества. Новые идеи, программные решения, оптимизация и адаптация вот что выделяет хорошего разработчика ПО. Соответственно, выбор подходящего инструмента для создания приложений это то, от чего напрямую зависит скорость работ, а значит и развитие компании, и продвижение ее на рынке. Одним из ключевых процессов в разработке ПО является логирование. Этим термином называется фиксация каждого этапа работы программы, как правило, сохраняемого в файл, который называется логом. Этот файл обычно содержит информацию о каждой совершенной программой операции и точном времени ее совершения, что позволяет в случае неполадки просмотреть, в какой момент и на какой операции что-то пошло не так. Программное обеспечения для сбора и анализа логов не всегда универсально. По классической схеме работы, лог-файл создается при первом запуске программы, фиксирует ее поведение, затем автоматически сохраняется при закрытии программы. При следующем запуске приложения лог-файл заменяется на новый и все начинается сначала. Однако, с течением времени программы становятся все более сложными, лог-файлы, соответственно, более объемными, а навигация по ним более затруднительной. С течением времени возникла необходимость в специализированных инструментах, которые позволяют быстро и удобно работать с логами. Одним из таких решений стал комплекс программ ELK Stack, о котором и пойдет речь в этой статье. Название ELK подобрано не просто так. Это не одна программа, а, как уже было сказано выше, комплекс, состоящий из трех основных программных продуктов Elasticsearch, Logstash и Kibana. Иногда данный комплекс дополняется сторонними программами, но эти "три кита" остаются неизменными инструментами. Разберем подробнее: Elasticsearch это поисковая система, предназначенная изначально для поиска фрагментов текста, однако с гибким функционалом и широкими возможностями по настройке. Это продукт улучшения решения Apache Lucene за счет добавления нескольких нововведений, делающих поиск информации в проектах с большими объемами данных достаточно оперативным и несложным. Logstash приложение для сбора информации из различных источников, преобразования их в удобный для работы формат и направления их в хранилище для дальнейшей работы. Простота использования и возможность работать с большими объемами данных обеспечивает Logstach ряд преимуществ перед аналогичными проектами. Kibana это плагин, предназначенный специально для Elasticsearch. Он отвечает за визуализацию данных, аналитику и представление итоговой информации в удобном для восприятия виде. Данное решение позволяет достаточно быстро анализировать итоги поиска, искать закономерности и представлять на экране Вашего устройства, где именно в проекте находятся слабые места. Этот плагин также обладает широкими возможностями по конфигурированию. Таким образом, механизм сбора логов выглядит так: Logstash собирает объемные логи и помещает их в хранилище, Elasticsearch используется для поиска нужных строк в этих логах, Kibana позволяет проанализировать и визуализировать результаты поиска. Комплекс этих программных продуктов отличное решение для оперативного поиска и устранения неисправностей в программном коде, и очень удобный инструмент для разработчиков особенно тех, кто занимается созданием или внедрением отдельных элементов в крупные проекты. Кроме того, функциональность ELK позволяет его использовать в качестве централизованного хранилища журналов, агрегатора событий с удобной навигацией, аналитической системы с алгоритмом машинного обучения, а также по иным назначениям. Стоит упомянуть, что все три проекта разработаны компанией Elastic на основе открытого кода. Это позволяет сторонним разработчикам модифицировать систему, и вполне возможно, что данный продукт получит развитие и в дальнейшем будет пользоваться еще большей популярностью среди пользователей.
img
Основной задачей, серверов является быть площадкой для функционирования серверного ПО или предоставления сервиса от (англ. Service - Сервис). Одним из основных сервисов в офисе, является сервис доступа к Internet для сотрудников офиса. Данный сервис необходимо предоставлять для сотрудников в целях осуществления ими своих служебных обязанностей. Обычно данный сервис, предоставляется по заранее определенным правилам для данного офиса или сотрудников. Классическим вариантом для предоставления данного сервиса является ОС CentOS 7 + Squid. Данная Связка очень распространена. Будем считать, что у нас имеется уже установленная ОС CentOS7 с подключением в интернет и доступна по порту 22 ssh для настройки. Установка Первое, что нам необходимо сделать это обновить ОС. yum update Если машина является прокси сервером, то логично предположить, что у нее должен быть включен Firewall, следовательно, нам нужно открыть во внутрь порт, на который сервис squid будет принимать подключения от клиентов внутренней сети. В большинстве случаев используют порт 3128, но можно взять любой не занятый. Настраиваем правило на Firewall: firewall-cmd --permanent --add-port=3128/tcp И обязательно надо перезапустить сервис: firewall-cmd --reload Далее переходим к установке и настройке непосредственно самого Squid. Установка производится следующей командой: yum install squid -y Открываем файл конфигурации для правки и добавления: nano /etc/squid/squid.conf В конфигурации прописаны стандартные подсети, но иногда подсеть пользовательских ПК не совпадает со стандартной или не входит, то вносим ее в конфигурационный файл acl localnet src 217.33.25.0/24 Чтобы наш прокси сервер пропускал любой трафик, необходимо добавить следующую строчку в конфигурацию http_access allow all Очень важно, чтобы данная строчка была в конфигурации выше строчки запрещающего правила. Запрещающая строчка выглядит так: http_access deny all Следующим шагом необходимо настроить каталок для кэша: cache_dir ufs /var/spool/squid 8192 32 256 В данной команде ufs - файловая система для squid данная файловая система используется для squid, путь для хранения кэша, 8192 - размер в МБ сколько будет выделено под кэш, 32 количество каталогов первого уровня для размещения кэша, 256 количество каталогов второго уровня. Следующим шагом будет создание структуры директорий для кэширования. Это можно сделать следующей командой: squid -z и вот наш прокси-сервер уже готов можно запускать прокси сервер, командой: systemctl start squid. А чтобы необходимый сервис запускался автоматически после перезагрузки или отключения сервера добавляем сервис наш в автозапуск: systemctl enable squid Дополнительной настройки для https не требуется все должно работать по умолчанию. И обязательно перезагрузить squid следующей командой systemctl restart squid Для управления squid можно пользоваться командой service status squid, service stop squid. Если сделанные изменения не затрагивают глобальных параметров, можно вообще не перезапускать сервис целиком, а дать команду squid перечитать конфиг squid -k reconfigure. Сервер для приема и проксирования соединений готов. Следующей задачей является настройка клиентских ПК для его использования. Если офис не большой 20-30 пользователей можно решить задачу, что называется в лоб. Сделать настройку в браузере в ручном режиме: Идем, Панель управления → Свойства Браузера → Подключения → Настройка сети → убираем галочку "Автоматическая настройка сети", добавляем галочку в поле "Прокси-Сервер", использовать прокси сервер для локальных подключений, в поле адрес прописываем или FQDN имя сервера и в поле порт 3128. Важный момент! FQDN имя сервера должно правильно разрешатся в DNS службе, указанной в настройках сетевого подключения. Проверить можно просто, открываем командную строку и пишем nslookup FQDN, если команда возвращает правильный ip адрес, то все сделано правильно. Рассмотрим вариант, когда у нас большое количество пользовательских ПК 100+. Естественно в такой ситуации проблематично сразу, всем сделать настройку для использования прокси-сервера. Самый оптимальный путь в данном случае это настройка параметров браузера, через WPAD файл и доставка на ПК сотрудника через web сервис. Устанавливаем web сервис: yum install httpd -y Переходим в рабочий каталог: cd /var/www/html Создаем новый файл командой touch wpad.dat и приводим его вот к такому виду, как на картинке: Файл состоит из java скрипта основная строчка return "PROXY FQDN:3128"; Это то, что попадет в настройки в веб браузеры ваших пользователей. Первая часть готова! Далее нам надо доставить данные настройки конечным пользователям. В этом нам поможет DHCP. Можно конечно сделать, через DNS, но там больше мороки на мой взгляд. Проще всего использовать DHCP сервер, но для этого необходимо внести коррективы и добавить дополнительную опцию 252, где будет указан url файла авто настройки. Данная опция может применятся на машину или на целую подсеть, а далее уже вместе с остальными настройками попадает на конечную машину пользователя. Запускаем веб и ставим в автозагрузку: systemctl start httpd systemctl enable httpd DHCP сервер настраивается следующим образом: Открываем консоль управление DHCP сервера. В свойствах сервера выбираем управление опциями -Set predefined Option. И добавляем опцию 252 - Имя -WPAD, код 252 Тип данных - String, Описание Web Proxy WPAD. Затем в поле String добавляем значение URL по умолчанию и сохраняем параметр. После этого мы можем данную опцию применять, либо к серверу в целом либо к определенной областиподсети адресов.
img
В этой статье мы рассмотрим настройку BGP-оповещения для Network Layer Reachability Information (NLRI), а также конфигурацию политики маршрутизации BGP. Предыдущие статьи цикла про BGP: Основы протокола BGP Построение маршрута протоколом BGP Формирование соседства в BGP Видео: Основы BGP за 7 минут Оповещения NLRI Прежде чем мы начнем настраивать оповещения NLRI, используя различные команды, давайте сначала обсудим старую функцию BGP, которую Cisco отключает по умолчанию. Эта функция называется синхронизацией BGP. Для проверки того, что Cisco отключила эту функцию на вашем устройстве, выполните команду show running-configuration на одном из устройств BGP, и в выводимой информации, под пунктом «процессы» BGP, вы увидите сообщение no synchronization. Если эта функция включена, функция синхронизации не позволяет спикеру BGP вводить префиксы в BGP, если нет коррелированной записи для префикса в базовом IGP (или статических маршрутах). Это помогает предотвратить ситуации типа "черная дыра" (black hole), когда устройства на маршруте не работают с BGP и не могут переадресовать префикс BGP, потому что у них нет маршрута к этому префиксу из их IGP. Эта функция отключена по умолчанию из-за создания множества различных механизмов масштабируемости, существующих в BGP, которые позволяют настроить топологию iBGP без требования полной сетки одноранговых узлов iBGP. Еще одна причина, по которой он отключен, заключается в том, что он поощряет перераспределение префиксов BGP в базовый IGP, и это не безопасно. Существует причина, по которой Cisco уходит от использования команды network для настройки IGPs в CLI. Не очень хорошая идея в программировании, чтобы одна команда выполняла очень разные вещи, и когда она используется в разных областях. Это относится и к команде network. При использовании в IGP команда включает протокол на интерфейсе (а также влияете на то, какие префиксы объявляются), но в BGP у команды network другое назначение. Она не включает BGP на определенных интерфейсах, вместо этого она объявляет префикс, который существует (каким-то образом) на локальном устройстве, и вводит его в BGP. Хотя префикс, который вы могли бы объявить в BGP, чаще всего встречается в вашем IGPs в таблице маршрутизации. Вы можете использовать другие методы для создания префикса для оповещения. Например, вы можете создать интерфейс обратной связи, который обладает префиксом сети, который вы хотите объявить. Или вы можете создать статический маршрут или даже статический маршрут, указывающий на Null0. Одна маленькая хитрость, связанная с командой network в BGP, заключается в том, что, если ваша маска подсети для вашего префикса не находится на классовой границе IP- адреса (например, 10.0.0.0/8), то вам нужно не забыть использовать ключевое слово mask и указать правильную маску при использовании команды. Пример 1 показывает создание двух петлевых интерфейсов и объявление их префиксов в BGP. Обратите внимание, что этот пример также показывает проверку этих префиксных объявлений на маршрутизаторе ATL. Пример 1: Использование команды Network в BGP TPA1#conf t Enter configuration commands, one per line. End with CNTL/Z. TPA1(config)#interface loopback 192 TPA1(config-if)#ip address 192.168.1.1 255.255.255.0 TPA1(config-if)#exit TPA1(config)#interface loopback 172 TPA1(config-if)#ip address 172.16.10.1 255.255.255.0 TPA1(config-if)#exit TPA1(config)router bgp 100 TPA1(config-router)#network 192.168.1.0 TPA1(config-router)#network 172.16.10.0 mask 255.255.255.0 TPA1(config-router)#end TPA1# ATL# ATL#show ip bgp Хотя команда network проста и удобна, она не была бы эффективной, если бы у вас было много префиксов для оповещения. Другой вариант- перераспределить префиксы в BGP из IGP или статических маршрутов. Пример 2 демонстрирует перераспределение префиксов, которые были получены через EIGRP, в BGP. Обратите внимание при проверке, что исходный код для этих префиксов отображается как (?) указывает на неизвестность. Пример 2: перераспределение префиксов в BGP TPA1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. TPA1(config)router bgp 100 TPA1(config-router)#redistribute eigrp 100 TPA1(config-router)#end TPA1# ATL#show ip bgp Когда вы начинаете объявлять (оповещать) NLRI в BGP, вы можете столкнуться с префиксами в вашей таблице BGP (показанной с show ip bgp), которые имеют код состояния (r) вместо ожидаемого допустимого кода состояния (*). Код состояния (r) указывает на сбой RIB, означающий, что BGP попытался поместить префикс в таблицу BGP, но не смог из- за какой-то проблемы. Наиболее распространенной причиной отказа RIB является административное расстояние (AD). Например, IBGP узнал префиксы несущие ужасные объявления AD из 200. Это означает, что если ваш маршрутизатор получил префикс через IGP (даже такой плохой, как RIP с AD 120), то он будет предпочтительнее префикса IBGP. В результате протокол BGP получивший это объявление AD, не отметит префикс как действующий. Обратите внимание, что это, как правило, не происходит с префиксами EBGP-learned, поскольку они имеют очень предпочтительное объявление 20 (по умолчанию). Очень часто, если желательно иметь префикс в IGP и BGP, администраторы будут манипулировать значениями AD на своих маршрутизаторах, чтобы улучшить AD IBGP. Например, в случае RIP и BGP администратор мог бы установить AD изученных маршрутов IBGP на 119, чтобы сделать их предпочтительными по сравнению с используемым IGP. В дополнение к выявлению сбоев RIB в результатах команды show ip bgp, вы можете использовать более прямую команду show ip bgp rib-failure, чтобы увидеть любые префиксы в этом состоянии. Это особенно полезно в случае массивных таблиц BGP. Настройка политики маршрутизации BGP Довольно часто встречаются топологии, в которых вы явно не хотите объявлять префиксы в своей таблице BGP, или вы не хотите получать определенные префиксы от узла BGP. К счастью, в вашем распоряжении есть много инструментов для этого. Например, вот только некоторые методы, которые вы могли бы использовать для фильтрации префиксов: Distribute lists Extended ACLs Prefix lists AS Path filters Route maps Пример 3 демонстрирует один из методов фильтрации. Выбран подход route map, потому что все (и это правильно) любят карты маршрутов. Пример 3: Использование route map в качестве префиксного фильтра в BGP ATL# configure terminal Enter configuration commands, one per line. End with CNTL/Z. ATL(config)#ip access-list standard MYPREFIX ATL(config-std-nacl)#permit 192.168.1.0 0.0.0.255 ATL(config-std-nacl)#exit ATL(config)#route-map MYMAP deny 10 ATL(config-route-map)#match ip address MYPREFIX ATL(config-route-map)#exit ATL(config)#route-map MYMAP permit 20 ATL(config-route-map)#exit ATL(config)#router bqp 200 ATL(config-router)#neighbor 10.10.10.1 route-map MYMAP in ATL(config-router)#end ATL# ATL# clear ip bqp * soft ATL# show ip bqp Обратите внимание, перед проверкой я запускаю команду clear ip bgp * soft. Это гарантирует, что устройство сразу же обновит информацию BGP для меня, так что мне не придется ждать истечения таймера, когда дело дойдет до конвергенции BGP на новых манипуляциях с политикой, которые мы сделали. Помните, что BGP использует множество различных атрибутов пути вместо простой метрики, чтобы предоставить вам возможность легко настроить способ, по которому происходит маршрутизация. Ниже приведены некоторые из атрибутов пути, которыми вы могли бы манипулировать, чтобы настроить политику: Weight MED Local Preference AS Path Можно спросить себя, как AS Path могут быть использованы в целях маршрутизации. Поскольку манипуляция AS Path часто выполняется с помощью AS Path Prepending. Вы отравляете префикс, добавляя свой собственный номер AS к пути, чтобы сделать более длинным (менее предпочтительным) AS Path. Как и большинство наших манипуляций с атрибутом пути, это легко сделать с помощью карты маршрута. Давайте рассмотрим пример использования Local Preference для манипулирования политикой. Мы часто используем Local Preference, чтобы повлиять на то, как мы будем направлять исходящий трафик к префиксу BGP. Мы делаем это, устанавливая значения Local Preference, входящие по нескольким путям. Прежде чем мы начнем, поймите, что Local Preference - это значение, которое рассматривается довольно высоко в процессе принятия решения о наилучшем пути BGP, более высокое значение предпочтительно, и значения передаются только в обновлениях IBGP. Именно так имя LOCAL вошло в название Local Preference. Для начала я объявил тот же префикс в AS 200 (ATL и ATL2) от маршрутизаторов TPA1 и TPA2 AS 100. Глядя на пример 4, Вы можете видеть, что этот префикс (192.168.1.0) может быть достигнут с помощью следующего прыжка 10.10.10.1 и что это предпочтительный путь. Альтернативный путь, который будет использоваться в случае неудачи этого пути, будет проходить через следующий переход 10.21.21.1. Пример 4: Подготовка к использованию Local Preference ATL# show ip bqp Теперь пришло время поэкспериментировать и изменить данное поведение с помощью примера манипуляции атрибутом пути. Мой подход будет состоять в том, чтобы определить префикс, которым мы хотим манипулировать (192.168.1.0), и поднять значение локального предпочтения, чтобы оно было больше, чем значение по умолчанию 100 для пути к TPA2 на следующем прыжке 10.21.21.1. Я делаю это, манипулируя префиксом, когда он входит через путь 10.21.21.1 . Пример 5 показывает эту конфигурацию. ATL# configure terminal Enter configuration commands, one per line. End with CNTL/Z. ATL(config)#ip access-list standard OURPREFIX ATL(config-std-nacl)#permit 192.168.1.0 0.0.0.255 ATL(config-std-nacl)#exit ATL(config)#route-map SETLOCALPREF permit 10 ATL(config-route-map)#match ip address OURPREFIX ATL(config-route-map)#set local-preference 110 ATL(config-route-map)#exit ATL(config)#route-map SETLOCALPREF permit 20 ATL(config-route-map)#exit ATL(config)#router bqp 200 ATL(config-router)#neighbor 10.21.21.1 route-map SETLOCALPREF in ATL(config-router)#end ATL# ATL# clear ip bqp * soft ATL# show ip bqp Обратите внимание, что предпочтительный путь теперь проходит через следующий переход 10.21.21.1, как мы и хотели. Для этого префикса также отображается значение Local Preference - 110. Это более высокое значение является предпочтительным и изменяет выбор, сделанный процессом выбора наилучшего пути BGP.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59