как настроить и собрать семантическое ядро

Содержание статьи

Что такое Key Collector

Программа Key Collector — это многофункциональный инструмент, предназначенный для получения данных, необходимых для продвижения сайта. Основной функцией кейколлектора является сбор запросов для семантического ядра. Также она обладает возможностью парсить различные показатели сайта:

• частотность и конкурентность запросов;
• ссылочные бюджеты с агрегаторов Rookee, MegaIndex, SeoPult;
• позиции сайта в поисковой выдаче Яндекса и Гугла;
• число главных страниц ресурсов в выдаче.

Кейколлектор пользуется огромной популярностью как среди SEO-специалистов, так и среди маркетологов и специалистов по контекстной рекламе. Основные достоинства программы:

1. Тонкая настройка парсинга;
2. Экспорт результатов в форматы Экселя;
3. Многопоточность парсинга благодаря поддержке прокси;
4. Подсчет стоимости ссылочного продвижения, исходя из данных ссылочных агрегаторов;
5. Хорошая тех. поддержка;
6. Подсчет стоимости кампаний контекстной рекламы;
7. Обилие мануалов и прочей обучающей литературы.

Как настроить

Несмотря на большое количество положительных моментов при работе и обширный функционал, настройка key collector требует особого внимания. Часто в работе случаются неполадки и их решению посвящены большие ветки на различных тематических форумах. Чтобы избежать наиболее распространенных ошибок, следует правильно настроить кейколлектор. Заходим в настройку кейколлектора, кликнув по соответствующей иконке.

Настройки парсинга

Главной задачей является правильная настройка парсинга. На вкладке «Общие» обращаем внимание первую графу. Как показывает опыт пользователей КК лучше всего выставлять «не более 7 слов», так как длинные фразы приводят к сбоям в работе парсера.

Касательно таймаута ожидания, то целесообразно выставить значение из диапазона 30 000-50 000 мс. В режиме сбора ставим галочку напротив «строк с неполученными данными» во избежание перезаписи данных и для заполнения пустых таблиц.

Далее переходим на вкладку Yandex.Wordstat. Важно понимать насколько обширна ваша тематика. Обычно, значение глубины парсинга или оставляют по умолчанию 0, или выставляют 1. Если тематика узкоспециализированная, то можно поставить 2, или в редких случаях даже 3 для получения максимального результата. Обратите внимание на настройку обработки частоты запросов. Здесь все зависит от ваших целей.

Поскольку с разгадыванием русской капчи часто случаются трудности, лучше ставить по-больше величину задержки. Количество потоков выставляется в зависимости от количества прокси. Если прокси отсутствуют, то оставляем значение 1.

Выставляя количество потоков учитывайте использование основного айпишника. Если у вас три прокси и вы ставите галочку на основной ip-адрес, то потоков будет четыре.

Во вкладке Гугл Эдвордс вводим адрес и пароль почты в форме логин:пароль.

Указывать логин следует без @gmail.com.

Здесь также можно выставить глубину парсинга и величину задержки. Известно, что Гугл довольно придирчив к парсерам и все подозрительные мгновенно отправляет в бан. Рекомендуется выставить большие задержки, особенно если парсить с основного IP (10 000-25 000 мс).

Поскольку статистикой Рамблера пользуются довольно редко, то парсинг будет всегда стабильным. Не стоит выставлять большое значение задержки. Что касается парсинга страниц, то оптимальное значение 5. При более высоких цифрах есть шанс спарсить всякий шлак.

Во вкладке Яндекс Директа следует указать аккаунты, через которые будет осуществляться парсинг. Чем больше аккаунтов — тем лучше, так как они могут быстро улететь в бан. Обратите внимание на строку по ограничению количества капч. Потоки выставляются по аналогии с Вордстатом.

Чем чаще высвечивается капча в аккаунте, тем скорее он будет заблокирован.
Рекомендуется в настройках выставить значение не больше 20.

Покупка и подключение прокси

Сервисов, где можно купить прокси для keycollector там много, что приведу разве что host4.biz

Не рекомендую искать бесплатные прокси, так как толку от них сущий нуль.

Для подключения прокси в кейколлекторе необходимо перейти в раздел «Сеть». Здесь нужно выбрать нужный протокол. Остальные настройки выставляете под свои нужды.

Далее, заносим данные прокси через окно «Добавить из буфера». Обратите внимание на форму записи.

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

Чтобы проверить работоспособность прокси, необходимо выбрать режим проверки (ограничимся обычным) и отправить запрос либо поисковой системе (Яндекс/Гугл), либо базе статистики (Вордстат). В случае удачной отправки, прокси засветится зеленым цветом.

Другие настройки

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

Для автоматического распознавания капчи зайдите в раздел «Антикапча» и выберите удобный для вас сервис по разгадыванию. Полученный ключ вставьте в соответствующее поле.

Раздел KEI кейколлектора позволяет занести формулы пользователя для определения показателей конкуренции, которые можно вычислить по данным Яндекса и ссылочных агрегаторов. Формулы моно вбивать в любую строку и в любом порядке. Результаты будут находится в соответствующей колонке. Ради удобства приведу полезные формулы, которые можно просто скопировать в программу.

Сезонность ключей:

• YandexWordstatAverageFreq/YandexWordstatBaseFreq*(YandexWordstatQuotePointFreq +1 )
• YandexWordstatAverageFreq/YandexWordstatBaseFreq*(YandexWordstatQuotePointFreq + 0.0001 )

Конкуренция и пустышки:

• AverageBudget/AverageTraffic + 0.0001
• YandexWordstatBaseFreq / ( YandexWordstatQuotePointFreq + 0.0001 )

Аналог Key Collector

Бесплатным аналогом кейколлектора является небезызвестный Slovoeb, в которым скопирован даже дизайн. Младший брат, так сказать. Разница состоит в том, что Словоёб ограничен по функционалу. Возможности парсинга сосредоточены на рунетовских системах, таких как Яндекс и Рамблер.

Однако через Словоеб можно собрать позиции и релевантные страницы сайта в Гугле. Большинство настроек аналогичны с КК. Экспорт файлов в Эксель присутствует.

Что делать, если программа не запускается

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

Если у вас возникнут проблемы с самой программой, то есть с софтом, то вам следует обратиться за помощью в техническую поддержку, которая осуществляет связь с пользователями через приложение SupportKC.exe. Если по каким-либо причинам доступ к приложению невозможен, можно написать на мыло [email protected].

Как пользоваться Key Collector (Кей Коллектор)

Время прочтения 4 минуты

Key Collector на текущий момент является одной из самых популярных программ среди профессиональных SEO-специалистов для сбора семантического ядра. Она имеет множество настроек, делающих трудозатраты ниже, а качество работы – выше.

В предыдущей статье мы рассмотрели, как настроить Key Collector. Сейчас мы рассмотрим пошагово, как пользоваться программой для сбора семантики.

1) Для начала нужно создать новый проект при помощи одноименной кнопки в интерфейсе программы.

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

3) Для парсинга запросов из поисковой системы Яндекс необходимо использовать иконку с красными вертикальными столбиками. В открывшемся окне можно ввести базовые ключи, по которым будет осуществляться парсинг из левой колонки Яндекс.Вордстат.

Ключи можно вводить по одному в строке или через запятую (предварительно отметив необходимое в настройках самого окна, вызываемых шестеренкой).

---

Функция распределения введенных фраз по группам в дальнейшем значительно сэкономит время при кластеризации ядра. Кнопка распределения обозначена на фото выше красной рамкой.

---

4) Процесс парсинга можно наблюдать во вкладках «Статистика» и «Журнал событий», располагающихся в нижней панели программы.

Далее рассмотрим все источники для парсинга, задействовать которые можно при помощи Key Collector.

 

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

— Кнопка запускает парсинг из правой колонки Яндекс.Вордстат. При помощи данного вида парсинга можно собрать похожие запросы, которые также могут быть полезными.

— Пакетный сбор из Google AdWords парсит запросы, используемые пользователями в поисковой выдаче Google.

— Сбор подсказок большинства поисковых систем является также важным и интересным каналом для парсинга запросов.

— Парсинг похожих поисковых запросов, обычно отображающихся внизу поисковой выдачи, тоже полезен для более широкого ядра.

— Данные, собираемые сервисом Roostat, позволяют собрать лучшие словоформы и возможные расширения. Часть подобных функций может быть выполнена также сервисом SpyWords, кнопка запуска которого располагается рядом справа в виде голубой шляпы.

— Одновременный запуск всех парсингов и статистики запросов.

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

Автор: Мария Свиридова

Настройка Key Collector | 9 важных шагов настройки программы

Время прочтения 4 минуты

Перед тем как начать использовать программу, нужно осуществить ее несложные настройки.

Их можно произвести в специальном окне, вызываемом шестерёнкой, расположенной в верхней панели слева.

1. Первая и одна из главных настроек должна быть осуществлена во вкладке «Парсинг». Тут следует ввести логин и пароль от учетных записей Яндекса и Google в подразделах Яндекс.Директ и Google AdWords соответственно. Это необходимо для того, чтобы обеспечить стабильность парсинга.

---

Важно: рекомендуется использовать ненужные учетные записи, т. к. велика возможность бана ip. Также для этой цели можно приобрести proxy-серверы (в таком случае будет необходимо отметить их использование во вкладке «Сеть»).

---

 

2. Для того чтобы существенно сэкономить время на вводе капчи, требуется зайти во вкладку «Антикапча», отметить используемый сервис и ввести ключ, генерируемый после оплаты сервиса.?0=,». Это будет способствовать получению ключевых фраз в понятном формате.

Итак, основные настройки Кей Коллектора для его более удобного использования завершены. Но для еще более «чистого» списка запросов сразу после парсинга рекомендуется выполнить еще некоторые манипуляции.

7. В том же окне настроек, во вкладке Яндекс.Вордстат, установить значение более 0 для раздела «Добавлять в таблицу фразы с частотами от xxx до 999000000» в случае, если не требуется собрать ядро по ярко выраженным сезонным товарам или услугам.

8. Далее, уже закрыв окно настроек, выбрать в верхней панели ярлык в виде щита синего цвета «Стоп-слова» и добавить туда стандартные фразы, которые точно не будут относиться к вашей тематике. Например: скачать, онлайн, бесплатно и т. п.

---

Важно: список стоп-слов не должен быть длинным, так как большое количество символов этого списка будет удлинять время парсинга.

---

9. На последнем этапе основной настройки Key Collector следует обозначить регион парсинга, т. к. в разных регионах поисковые запросы могут отличаться не только частотностями, но и словоформами. Это просто сделать, присвоив нужную локацию для выбранных методов парсинга в нижней панели Кей Коллектора.

Автор: Мария Свиридова

Key Collector — первичная настройка

👁7 628 просм.

Key Collector и семантическое ядро

Основное назначение Key Collector, это составление семантического ядра. Софт не бесплатный, но и не самый дорогой. Вполне оправдывает вложения, если вы часто сталкиваетесь с подбором ключевых запросов для сем. ядра, написания seo-статей или для настройки контекстной рекламы. Кроме того в Key Collector присутствуют такие функции как определение наиболее релевантных по версии поисковых систем страницы на исследуемом сайте, экспресс-анализ позиций в поисковой выдаче, а также сбор рекомендаций по внутренней перелинковке.

Но не путайте. Сам по себе Key Collector не является сервисом, выполняющим выше описанные задачи. Это лишь очень удобный инструмент для обработки данных, которые в него поступают из поисковых систем Google и Яндекс, а так же других специализированных сервисов, в которых вы должны быть зарегистрированы.

 

Первичная настройка Key Collector

После того как вы активировали программу Key Collector следует провести предварительную настройку для более удобной работы по составлению семантического ядра.

Создание нового проекта

Для того чтоб начать работу над новым проектом, нам нужно его создать. Жмем кнопку «Новый проект» в открывшемся интерфейсе программы

и сохраняем его в нужном каталоге на компьютере. При необходимости переименовываем проект.

Настройка для работы с Yandex.Wordstat

После того как создан новый проект, переходим по пути Файл → Настройки.

В открывшемся окне настроек на вкладке Yandex.Wordstat в графе «Добавлять в таблицу фразы с частотами от» ставим цифру 7, как на рисунке выше. Все остальные настройки в этой вкладке оставляем без изменений, и переходим на вкладку Yandex.Direct.

Настройка для работы Yandex.Direct

Здесь нам нужно будет ввести логин и пароль от заранее подготовленного аккаунта Яндекс Директ в формате [email protected]:pass1234. Логин→двоеточие→пароль. Можно вводить данные от нескольких аккаунтов, чтоб сбор данных проходил в несколько потоков и выполнялся быстрее. Для этого так же нужно будет выбрать количество потоков от 1 до 3.

Но не переусердствуйте, при использовании более 3-х потоков система Яндекс может заблокировать как используемые вами аккаунты, так и IP адрес, с которого вы проводите сбор данных.

Настройка для работы с Google AdWords

Переходим к следующей вкладке, для настройки Google AdWords. Настройка подобна как и для Yandex.Direct.

Так же для работы со сбором данных в Key Collector лучше использовать специально созданные для этого аккаунты Директа и Адвордса, чтоб не потерять рабочий аккаунт из-за наложенных санкций. При этом, в аккаунте Директа не нужно пополнять счет, но обязательно нужно создать любую рекламную кампанию, чтоб активизировать его действие. В аккаунте Google AdWord, по некоторым сведениям, для сбора поисковых подсказок нужно потратить на рекламу минимум 15$. Эта цифра может меняться в зависимости от региона, к которому принадлежит аккаунт и, собственно, правил Google AdWords. Могу сказать, что при создании нового аккаунта мне не пришлось ничего тратить на рекламу, для нормальной работы сервиса.

Настройка названия столбцов таблицы

Далее можем перейти на вкладку «Заголовки таблиц» и переименовать заголовки таблиц интерфейса Key Collector в более короткие и понятные. Но этот пункт вы можете выбирать по желанию, на общую работоспособность он не влияет.

Настройка экспорта

И последнее в окне настроек перейдем на вкладку «Экспорт» и выберем здесь формат экспорта XLSX, для того чтоб потом сохранить собранные и отсортированные нами ключи в файл для дальнейшей работы с ними в Excel.

На этом базовая настройка программы закончена. Сохраняем все изменения и переходим к настройке кампании.

Настройка региона поиска

Перед началом сбора ключевых слов для семантического ядра нам нужно задать параметры геолокации в зависимости от того в какой стране и регионе необходимо продвигать наш сайт. Эти настройки находятся в нижней части окна Кей Коллектора.

Предположим, что наш сайт будет продавать косметику в Ставрополе. Чтоб внести правильные настройки нажимаем на каждую из кнопок и вводим соответствующую информацию для Wordstat, Direct, Yandex поиск и Google поиск.

Должна получиться следующая картина:

Собственно теперь все готово для парсинга ключевых запросов. Из поисковиков Google и Яндекс.

Более подробно с процессом работы, и составления семантического ядра вы можете ознакомиться в инструкции для пользователей на официальном сайте программы перейдя по ссылке http://www.key-collector.ru/manual_index.php

Оставляйте свои комментарии, делитесь опытом использования этой программы, задавайте вопросы, подписывайтесь на обновления блога в социальных сетях.

Буду рад общению и новым знакомствам 🙂

P.S. Рекомендую прочитать статью о первичной настройке Google AdWords, расположенную по этой ссылке.

Инструкция по настройке Key Collector для эффективного парсинга

Key Collector — незаменимый инструмент при сборе семантического ядра для сайта или контекстной рекламы. Но прежде чем запускать парсинг, программу необходимо грамотно настроить. Это позволит провести сбор фраз максимально быстро и с наименьшими затратами на антикапчу.

В этой статье мы пройдемся по основным настройкам программы, подготовим инструмент, а уже саму методику сбора, чистки и расширения семантики будем рассматривать в других статьях. Эта статья открывает цикл материалов, посвященных работе с Key Collector.

Весь цикл статей:

1. Настройка Key Collector для сбора (эта статья)
2. Методика сбора (парсинга) фраз в Key Collector.
3. Эффективная чистка в Key Collector.
4. Принципы группировки (кластеризации) фраз в Key Collector (в работе, ссылка появится позже)
5. Учет, фильтры и лайфхаки при работе в Key Collector (в работе, ссылка появится позже)

Установка программы

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

Важно! Key Collector — программа, которая работает под Windows и на компьютеры Mac (Macbook, Macbook Air) с OSx не установится. Обойти это ограничение можно установкой виртуальной машины Windows, к примеру посредством утилиты Parallels Desktop.

Прокси и аккаунты Яндекс.Директ

Для работы с Key Collector мы настоятельно рекомендуем приобрести (взять в аренду на неделю или на месяц) как минимум 1 прокси-сервер. Это необходимо для того, чтобы обезопасить свой основной IP адрес от возможных блокировок, которые могут возникнуть в ходе работы Key Collector со статистическими источниками типа Яндекс.Вордстат и Яндекс.Директ.

Одного прокси будет вполне достаточно, чтобы потренироваться и понять принцип работы программы. Хорошие, индивидуальные прокси предоставляет сайт proxy-sale.com. Берем те, что для работы в Key Collector.

После покупки сервис высылает вам на почту учетные данные прокси и свежий аккаунт Яндекс.Директа, который также нам потребуется. В дальнейшем, при необходимости количество прокси можно будет увеличить, просто докупив (арендовав) столько сколько нужно. 

Сейчас нам нужно просто понять принцип настройки Key Collector, а дальнейшую докрутку можно будет сделать потом.

Переходим в настройки программы — нажимаем на иконку «шестеренки» в панели управления.

Фото 1: Меню настроек Key Collector.

Учетки для Yandex.Direct

Переходим в раздел настроек “Yandex.Direct” (Парсинг -> Yandex.Direct).

Вводим необходимые данные: логин и пароль от аккаунта Яндекс.Директ, IP прокси, порт, логин и пароль. Эти данные должны быть в письме, которое вы получили от proxy-sale. Вы можете добавить прокси вручную построчно или добавить из буфера обмена списком. Обратите внимание на формат, который требует Key Collector при вводе данных списком. Будьте внимательны и не перепутайте логин и пароль от учетки Яндекс.Директ с логином и паролем прокси сервера.

Фото 2: На первом шаге мы только вносим данные учетки и прокси, настройки будем делать потом. Это уменьшит количество ошибок и возможных проблем.

Сейчас, мы внесли данные и, тем самым, привязали учетку Яндекс.Директ к прокси серверу. Теперь все запросы в Yandex.Wordstat, Yandex.Direct или поисковую выдачу будут идти с одного и того же IP адреса (IP адрес прокси сервера) и с одной и той же учетки.

Такая привязка значительно повышает стабильность парсинга, уменьшает количество показов капчи (проверки на робота), что в итоге приводит к более быстрому сбору данных и уменьшению общего времени, затрачиваемого на сбор.

После того, как данные внесены, нам необходимо установить количество потоков в блоке 2 равным количеству прокси, которые мы приобрели. В нашем случае устанавливаем это значение равным 1 и переходим к следующему этапу.

Вкладка «Сеть»

Сюда мы должны добавить наш(и) прокси и установить ряд дополнительных настроек.

Фото 3: Основные зоны интереса во вкладке «Сеть».

Первым делом добавляем прокси в таблицу №1, отмеченную на скриншоте . Можно внести построчно, вручную или нажать кнопку «Добавить из буфера» и внести списком. Указываем IP сервера, порт, логин и пароль прокси сервера (не учетки Яндекс.Директа!). Берем эти данные из письма, которое прислал нам сервис, в котором мы приобрели прокси.

Обратите внимание на формат, который требует Key Collector, при внесении прокси списком! Если вы часто меняете прокси и работаете с большим объемом данных, то мы рекомендуем сделать формулу в Google Spreadsheets, которая бы приводила данные в нужный для Key Collector формат.

Основные настройки (2)

1. Использовать прокси серверы. Включаем данную опцию поставив галочку, HTTP остается без изменений. Для простоты, мы будем использовать HTTP прокси. SOCKS протокол требует большей сноровки и опыта и в некоторых случаях работает с ошибками, что может привести к невозможности продолжения работы.
2. Деактивация прокси, не прошедших проверку. Включаем, это мера предосторожности в случае, если возникли какие-то проблемы с прокси. После 360 секунд системой будет проведена повторная попытка подключения.

Проверка прокси (3)

Выставляем количество количество потоков равным количеству прокси. Т.е. если у нас 1 прокси, то ставим 1.

После этого мы отмечаем наши прокси галочкой (активируем их), чтобы каждая строка в блоке 1 была выделена зеленым цветом и запускаем проверки (одну за другой, по очереди):

1. Проверить в ПС Yandex
2. Проверить в Yandex.Wordstat

Проверки нужны для того, чтобы понять все ли в порядке с настройками, учеткой Яндекс.Директ и прокси сервером(ами). Если Key Collector заблокировал прокси (пометил строку красным цветом) в блоке 1 после проверки через ПС Яндекс, то проблема в настройке самого прокси сервера. Возможно, неверно введен логин, пароль или порт прокси сервера. Если же прокси не прошел проверку через Yandex.Wordstat, то проблема уже в настройках учетки Яндекс.Директ.

Последовательная проверка позволяет быстро локализовать ошибку и оперативно исправить причину.

Антикапча

Для автономной работы программы нам необходимо будет зарегистрироваться в сервисах, которые предоставляют услуги “Антикапчи”. Бюджет на данные сервисы нужен небольшой, однако это позволит использовать КК в автономной режиме. Ниже представлен перечень поддерживаемых Кей Коллектором сервисов:

Фото 4: Перечень сервисов, которые поддерживаются программой и предоставляют услуги по разгадыванию капчи.

Выбираем понравившийся сервис и регистрируемся в нем. Вносим 100-500р на баланс, получаем API ключ, который нужно будет внести в настройки ниже.

Фото 5: Настройки антикапчи (автоматическое распознавание captcha).

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

Во вкладке Настройки -> Антикапча -> Автораспознавание необходимо выбрать сервис, который вы решили использовать и ввести предоставленный вам ключ. После ввода ключа следует перезагрузить программу, чтобы Key Collector активировал ключ.

Также, вы можете ввести ограничение капч на один сеанс, то есть если в ходе сбора данных количество капч будет превышать указанный параметр — антикапча перестает работать. После перезапуска Кей Коллектора счетчик сбрасывается. Мы рекомендуем указать значение параметра равным 5000.

Настройки парсинга

Первым в списке настроек программы находится большой раздел «Парсинг», который отвечает за настройку сбора данных из разных источников.

Общие настройки

Настраиваем раздел “Общие” следующим образом:

Фото 6: Основные настройки парсинга.

Основные комментарии к настройке:

1. Добавлять в таблицу фразы, содержащие не более N слов. Как показывает практика, оптимальным количеством слов является 10. Именно с этим числом мы можем получить как высокочастотные, так и среднечастотные и низкочастотные запросы. Хвост запроса мы терять не хотим, однако и сбор пустых по частотности запросов нас тоже не интересует. 10 слов в запросе вполне отвечает данным требованиям.
2. Количество повторных попыток загрузки страниц. В случае сбоя именно это количество повторных попыток сделает программа. Стандартное значение 30. Не меняем его, т.к. этого вполне достаточно для корректной работы программы.
3. Таймаут ожидания ответа от сервиса. Время ожидания загрузки страниц из сервисов. Стандартная настройка в 30000 мс подойдет для проектов любого размера.
4. Режим сбора. В данном пункте должно быть отмечено “Строки с неполученными данными” — для строк с отсутствующей информацией будут собираться данные в программе, это сократит время сбора, так как не будет повторных проверок уже заполненных данных.
5. Фильтрация символов. В примере указан довольно большой перечень символов, который будет удаляться при парсинге. Нас не интересует экспрессивность выражения потребностей пользователя в поиске, а интересует сам смысл его запроса. В то же время, такие символы как “-” и “.” могут употребляться разными пользователями по-разному, например со знанием правил написания того или иного запроса и без. Чтобы привести все к единому виду, заменяем данные символы на пробел. Замена буквы ё на е так же является корректировкой различия между запросами пользователя. Нет разницы, поступил запрос в формате ёжик или ежик, так как они несут один семантический смысл. Поэтому для удобства приводим все фразы к единому виду по данному параметру.
6. Приводить слова в нижний регистр. Также является удобной настройкой для приведения всех фраз к единому формату.

Наша конечная цель — получить список ключевых фраз в едином, понятном формате. Это упростит дальнейшую работу и облегчит процесс чистки и поиска дублей.

Yandex.Wordstat

Для сбора с Вордстата программа использует аккаунты, прописанные в настройках Яндекс.Директа (Настройки -> Парсинг -> Yandex.Direct), которые мы заполнили ранее.

Фото 7: Настройки парсинга Yandex.Wordstat.

Комментарии к настройке:

1. “Глубина парсинга” и “Парсить страниц”. Глубина парсинга работает только для сбора ключевых фраз. Для глубины парсинга рекомендуемое значение 0. Если мы ставим значение отличное от 0, то Key Collector будет делать парсинг вложенных фраз (фраз, которые «приехали» в результате прошлой попытки сбора). Потенциально, такой подход может вылиться в непредсказуемое время на парсинг ключей, т.к. мы никогда не знаем какое количество фраз мы получим при сборе той или иной фразы. Стратегию парсинга мы будем более подробно рассматривать в других статьях. Пока, для оптимального результата ставим 0 для глубины парсинга и 40 для количества страниц.
2. Добавлять в таблицу фразы с частотами от X до Y. Мы можем задать минимальную частоту фразы для сбора сразу на этапе парсинга. Однако диапазон лучше оставить максимальным, чтобы не упустить интересные формулировки и запросы. В последующем мы сможем избавиться от низкочастотных запросов в пару кликов.
3. Не снимать частоты для фраз с базовой частотой равной или ниже чем N. Данная настройка позволяет нам экономить время сбора данных при настройке на 0, так как базовая частота 0 нас в общем то не интересует, это пустые фразы, по которым нет спроса.
4. Автоматически записывать 0 в колонки частот “ “ и “!”, если базовая частота 0. Опять же экономия времени на проверку частотности, так как данные автоматически будут заполнены, мы не будем собирать для них указанные частоты.
5. Маска запросов пользовательского формата. Выставляем значение “[!QUERY]”, таким образом мы автоматически проставим нужные операторы для  запросов и получим максимально точные цифры.
6. Задержки между запросами от X до Y. Как показывает практика, значение от 25000 до 30000 вполне уместно и является близким к естественному. При возникновении блокировок мы всегда сможем изменить данный параметр в большую сторону.
7. Деактивация потоков. Количество потоков ставим равному количеству прокси серверов, которые мы настроили на прошлом этапе. Деактивацию потоков выставляем так, как указано на скриншоте. Система будет уменьшать кол-во потоков если по какой то причине прокси сервер выходит из строя, что нам и нужно.
8. При использовании группировки по месяцам. В данном случае оптимально будет установить “последний год” для учета актуальных данных.
9. Настройки режима “Собрать все виды частот”. Здесь вы можете настроить какие частоты надо собрать при использовании данного инструмента. Можно ничего не менять, т.к. в дальнейшем, при сборе мы всегда будем собирать частотности последовательно.

Фото 8: Можно задать какие именно частоты будут собираться при выборе опции «Собрать все виды частот».

Yandex.Direct

Фото 9: Настройки работы с сервисом Yandex.Direct.

1. Задержки между запросами. Задержку между запросами лучше установить от 10000 до 15000 мс, чтобы не получить блокировку и не нагружать систему. Директ очень чувствителен к парсингу и выдает много капч при агрессивном сборе.
2. Количество потоков. Ставим кол-во потоков равным количеству прокси. Настройки деактивации ставим как указано на скриншоте.

Google Adwords

Настройки источников Google Adwords как правило остаются стандартными, так как имеют ограничения, о которых нас предупреждает Кей Коллектор.

Фото 10: Настройки Google Adwords.

В целом, менять их нет необходимости. Использование точной частоты из Google Adwords когда-то использовалось для инструмента “Анализ неявных дублей”, так как точная частотность из Adwords учитывает порядок слов. На данный момент эту задачу решает сбор точной частотности по маске QUERY через Яндекс (так называемый оператор скобки [], учитывающий последовательность слов в фразе).

Rambler Adstat

Настройки для Rambler Adstat также оставить в стандартном режиме, так как данная система не используется в сборе данных. Подсказки из Rambler можно получить без регистрации и настройки аккаунтов. В целом, Rambler Adstat — устаревший инструмент и не содержит нужного объема семантики для того, чтобы было уместным тратить время на сбор данных из него. Об актуальных на сегодняшний день источниках можно прочитать в этой статье.

Фото 11: Настройки Rambler Adstat.

Поисковая выдача

Во вкладке “Поисковая выдача” меняем количество потоков в зависимости от количества прокси, отключаем использование основного IP адреса и переключаем режим деактивации потоков.

Блок настроек Yandex.XML игнорируем и не меняем там ничего. В нашей работе мы не будем пользоваться XML сервисом Яндекса, поэтому активировать его нет необходимости.

Фото 12: Настройки работы с поисковой выдачей Yandex.

Устанавливаем кол-во потоков и настройки деактивации одинаково для всех источников, с которыми мы собираемся работать: Yandex, Google, YouTube, Mail.ru.

Фото 13: Настройки работы с поисковой выдачей Google, YouTube, Mail.ru.

Подсказки

В разделе “Подсказки» проводим аналогичные настройки: выставляем количество потоков в зависимости от количества прокси, отключаем использование основного IP адреса и меняем режим деактивации потоков.

Фото 14: Настройки работы с поисковыми подсказками.

Mail.ru

Mail.ru не используется напрямую в ходе парсинга как источник, однако проводим настройку аналогичную подсказкам и выдаче: количество потоков, их деактивация и ограничение использования основного IP адреса.

Фото 15: Настройки работы со статистикой Mail.ru.

Прочее

Раздел “Прочее” включает в себя две настройки, которые можно оставить в стандартном положении. Мы будем использовать антикапчу, поэтому нам выгодно оставить все как есть и имитировать разгадывание капчи (разумеется через сервис антикапчи) с того же самого IP адреса, которому она была показана поисковой системой. Это благоприятно влияет на стабильность парсинга и уменьшает количество капч, которые показывают сервисы.

Фото 16: Прочие настройки Key Collector.

Итоги

Итак, мы прошлись по основным настройкам Key Collector, подготовили инструмент для парсинга в автономном режиме. Первоначальная настройка инструмента действительно может занять немало времени, но сэкономит вам много времени в дальнейшем, т.к. настроенная подобным образом программа работает на автопилоте и не требует внимания и контроля. Ее можно установить на виртуальную машину и оставить на ночь, не переживая о том, что парсинг остановится по той или иной причине.

В следующих статьях мы рассмотрим стратегию парсинга ключей, которая дает полную семантику. Эта стратегия одинаково хорошо подходит как для сбора семантического ядра для сайта, так и для семантики под контекстную рекламу, например для Яндекс.Директ.

Ускорение сбора в Key collector

На данной странице Вы получите инструкцию по быстрой настройке программы «Key collector». Данная инструкция позволит вам собирать поисковые запросы и не получать «CAPTCHA». Также данная информация поможет вам не только избавиться от капчи, она также поможет правильно подключить прокси, для более быстрого сбора данных.

Я долго искал оптимальные настройки программы «Кей коллектор». В интернете их очень много и все рекомендуют свои. Бывают настолько «замудренные» и противоречивые, что просто не знаешь, как поступить. В общем, как это часто бывает, подобрал настройки самостоятельно. Конечно, я ни на что не претендую. Понимаю, что специалисты могут раскритиковать мой метод, но он работает. Хотя, я не являюсь большим специалистом в работе с кей коллектором. На сегодняшний день мой результат: 252454 запроса и ни одной капчи. Сбор шел 4 ночи. Если бы зарегистрировал больше прокси, тогда бы на сбор потратил еще меньше времени. Теперь к делу.

Для данной настройки программы мне понадобилось 10 аккаунтов в яндекс почте и три прокси-сервера. Сейчас объясню подробнее.

Чтобы программа работала в несколько потоков нужны прокси-сервера. Что это значит? Все просто, программа одновременно работает по нескольким запросам. Например, вы парсите три запроса. Если ничего не настраивать и не пользоваться прокси, то данные запросы будут парситься по очереди, если же у вас настроено три прокси-сервера, то эти запросы будут парситься одновременно. А это, соответственно, в три раза быстрее. Именно так я и настроил программу. Зарегистрировал три прокси-сервера и 10 аккаунтов в яндекс почте. Зачем нужно десять аккаунтов в яндекс? Они нужны для многопоточности и ускорения сбора. Также могут пригодиться, если вдруг какой-то аккаунт будет забанен. Перейдем к подробностям.

Настройка Key Collector

Прежде чем перейдем к настройке, основные рекомендации. Возможно, вы о них уже знаете, но, на всякий случай, повторю.

• Аккаунты в яндексе должны быть специально зарегистрированы для парсинга (сбора запросов). Не используйте свой основной аккаунт, его могут заблокировать.  
• Не используйте бесплатные прокси-сервера. Я много экспериментировал с бесплатными прокси, пользовался огромным количеством, но они очень плохо работают. Постоянные ошибки в Key Collector, прерывания сбора, не корректное завершение сбора. В общем, не рекомендую, только потратите свое время.

Я же настроил программу так:

— В пункте настроек «Yandex.Direct» я добавил специально зарегистрированные 10 аккаунтов.

— В пункте «Сеть» я добавил три прокси-сервера. Данные прокси-сервера я регистрирую за копейки у этого провайдера «Proxy6». Об этом я еще расскажу ниже.

— И во всех вышеперечисленных пунктах я убрал галочку с пункта «Использовать основной IP».

— Также в этих же пунктах поставил три потока.

В целом, на этом мои настройки заканчиваются. Нужно только добавить, что в количестве потоков я исходил из количества прокси. Если вам нужно собирать ОГРОМНЫЕ базы, то вы можете использовать сколько угодно прокси серверов. Не забывайте в количестве потоков выбирать столько, сколько у вас прокси-серверов. Также нужно регистрировать большее количество аккаунтов в яндекс, чем количество прокси-серверов.

Где брать прокси?

Как и обещал, расскажу о прокси. На сервисе «proxy6» вы можете регистрировать сколько угодно прокси-серверов, в зависимости от того, сколько вам необходимо. Чтобы зарезервировать свои прокси-сервера, вам нужно:

— Зарегистрироваться на сервисе. Ссылка на «proxy6»

— Войдите в свой кабинет и нажмите на пункт меню «Купить прокси».

— Вы попадете на страницу заказа. Рекомендую выбирать третий пункт «IPv4 Shared ПРОКСИ» (на момент написания статьи называется так), потому что данный вариант самый дешевый. Вам нужно выбрать страну, количество прокси-серверов и период. После оплаты в вашем кабинете будут данные ваших прокси серверов, которые вы можете добавлять в Key Collector и пользоваться.

На этом настройка закончена. Могу лишь добавить, что с данными настройками Key Collector отлично работает. Я им пользуюсь на двух компьютерах, настройки одни и те же.

Надеюсь, что данная заметка поможет вам настроить Key Collector, и он будет радовать вас своей работой.

Добавил видео, для наглядности.

P. S. То, что вы дочитали статью до конца, говорит о вашей заинтересованности. Держите купон на скидку «rYXS0zTvFK» (вводите без кавычек). Введите его при заказе прокси-сервера у Proxy6
Успехов Вам.

Как настроить Key Collector и создать проект для контекстной рекламы

В этом уроке мы выполним подготовительную работу: скачаем Excel шаблон для настройки Яндекс Директ, создадим проект на компьютере, настроим Key Collector и рабочую среду, установим плагин для браузера Yandex Wordstat Assistant.

Рекламную кампанию будем настраивать для сайта: dias-clean.ru. Тематика: Клининговая компания. Сайт разработан на CMS WordPress. Мы не будем настраивать все направления на сайте, а выберем несколько. Вводные данные будут такие:

• ГЕО: Зеленоград, Химки, Королев
• Направление: уборка квартир, домов, коттеджей, уборка после ремонта.

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

Создание проекта

Создаем папку на компьютере. Наименование: «site.ru – Тематика».В нашем случае: dias-clean.ru – Клининговая компания. Внутри папки создаем еще одну с названием «Реклама», внутри которой папку Яндекс Директ.

Структура проекта

Рекомендую настроить синхронизацию с Google Disk, чтобы у вас был доступ к файлам и с другого компьютера, к тому же очень удобно делиться файлами, открывая их для общего доступа или на персональную почту.

В папку «Яндекс Директ» переносим файл шаблона, который можно скачать по этой ссылке. И переименовываем его. Наименование рекомендую делать такое: «direct – Направление». В нашем случае будет так: «direct – Уборка квартир».

Настройка Key Collector

Запуск программы Key Collector и его активацию мы пропускаем (если вы его только купили), я уверен, что тут вы разберетесь без меня. Поэтому переходим сразу к настройке.

Первое, что мы сделаем – это настроим техническую часть, чтобы можно было комфортно парсить и использовать нужные нам инструменты. Работу с прокси рассматривать не будем.

С такими настройками вы можете смело парсить выдачу, у вас почти не будет капчи и тем более банов аккаунтов. Прокси не понадобятся.

Все, что вам  нужно сделать –  это повторить текущие настройки на скриншотах. Нажимаем на шестеренку и переходим к настройкам.

Переходим в настройки Key Collector

Вкладка «Парсинг» – «Общие».

Вкладка «Общие»

Вкладка «Парсинг» – «Yandex.Wordstat».

Вкладка «Yandex.Wordstat»

Вкладка «Парсинг» – «Yandex.Direct».

Рекомендую зарегистрироваться и добавить минимум 5 аккаунтов. Не добавляйте личные аккаунты, для парсера нужны новые аккаунты или те, которыми вы не пользуетесь, так как есть шанс, что их заблокируют.

Вкладка «Yandex.Direct»

Вкладка «Парсинг» – «Google.Adwords».

Вкладка «Google.Adwords»

Вкладка «Парсинг» – «Поисковая выдача».

Вкладка «Поисковая выдача»Вкладка «Поисковая выдача»

Вкладка «Парсинг» – «Подсказки».

Вкладка «Подсказки»

Вкладка «Парсинг» – «Рекомендации».

Вкладка «Рекомендации»

Вкладка «Парсинг» – «LiveInternet» – пропускаем.

Вкладка «Парсинг» – «Mail.ru».

Вкладка «Mail.ru»

Вкладка «Парсинг» – «Социальные сети» – пропускаем.

Вкладка «Парсинг» – «Платные API» – пропускаем.

Вкладка «KEI & SERP».

Вкладка «KEI & SERP»

Вкладка «Сеть» – используется для настройки работы с прокси. Пока пропускаем.

Вкладка «Интерфейс» – «Прочее» – «Внешний вид»

Вкладка «Внешний вид»

Вкладка «Интерфейс» – «Прочее» – «Работа с проектом».

Вкладка «Работа с проектом»

Вкладка «Интерфейс» – «Прочее» – «Таблица данных».

Вкладка «Таблица данных»

Вкладка «Интерфейс» – «Прочее» – «Процесс парсинга».

Вкладка «Прочее»

Вкладка «Интерфейс» – «Экспорт».

Вкладка «Экспорт»

Вкладка «Интерфейс» – «Заголовки таблиц».

Вкладка «Заголовки таблиц»

Вкладка «Интерфейс» – «Анализ словоформ».

Вкладка «Анализ словоформ»

Все используемые предлоги можно посмотреть по ссылке.

Вкладка «Антикапча» – «Автораспознание».

Рекомендую использовать сервис Antigate (anti-capcha.com)

Вставляем API ключ Antigate

Как зарегистрироваться в сервисе Antigate и получить API ключ, смотрите в видео.

С такими настройками Key Collector вам достаточно пополнить сервис Antigate на 1-2 доллара, которых хватит надолго.

Вкладки «Megaindex API» и «Прочее» оставляем по умолчанию.

Подготовка рабочей среды в Key Collector и создание проекта

Далее нам нужно создать проект в Key Collector и выполнить несколько манипуляций в интерфейсе.

Создаем проект в Key Collector

Нажимаем на кнопку «Новый проект». Рекомендую использовать следующее наименование файла: «Реклама – site.ru». В нашем случае будет так: «Реклама – dias-clean.ru». Сохраняем его в папку «Реклама».

Путь сохранения проекта Key Collector

Выводим нужные нам столбцы в Key Collector и скрываем ненужные.

Отображаем нужные столбцы

После того, как задействовали нужные столбцы, сохраняем шаблон вида.

Сохраняем настройки вида

Нам осталось настроить рабочие группы. Структуру предлагаю сделать такой: 

Настройка групп

Плагин для браузера Yandex Wordstat Assistant

Последним шагом для нас будет установка плагина Yandex Wordstat Assistant, который позволит удобно собирать маски ключей в сервисе Яндекс Wordstat. Установка простая. Уверен, что справится каждый без инструкций.

Ссылка на плагин Yandex Wordstat Assistant.

После установки в сервисе Яндекс Wordstat появятся дополнительные опции.

Плагин отображается в Яндекс Wordstat

Заключение

На этом все подготовительные работы выполнены. Если какие-то моменты не понятны и требуют дополнительного разъяснения, то пишите в комментариях к уроку. 

Введение в Key Collector — самый обсуждаемый инструмент SEO в России | by Jyldyz SEO

Одна вещь, которая делает мой опыт работы SEO-специалистом гораздо более увлекательным, — это работа по двум направлениям: российскому (Яндекс) и американскому (Google). Я не скажу вам, какая из этих двух мне больше всего нравится, лучше я познакомлю вас с программным обеспечением, которое отлично работает для обеих поисковых систем — Key Collector.

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

Это один из важнейших шагов в построении семантического ядра. Key Collector может мгновенно и одновременно собирать статистику частоты для каждого ключевого слова на основе данных из Google AdWords Keyword Planner Tool, Yandex Wordstat, Rambler Adstat.

Google AdWords Keyword Planner ToolРусский аналог Keyword Planner Tool — Яндекс wordstat

Для сбора статистики выполните следующие действия:

1. Создайте новый проект в Key Collector
2. Выберите регионы, подходящие для вашего бизнеса
3. Добавьте ключевые слова, соответствующие вашей нише в раздел «Добавить фразы»
4. Выберите «G» (Google) или Rambler в качестве предпочтительной поисковой системы (ов).Яндекс доступен только в русскоязычной версии Key Collector
5. Начать сбор статистики по количеству запросов по ключевым словам

Key Collector — сбор статистики по количеству запросов

Совет: для сбора полного списка ключевых фраз используйте функцию «Поисковые предложения» . Он собирает слова, подсказанные поисковыми прогнозами от Google, Yahoo, Bing и YouTube. Хорошая новость в том, что уже добавленные ключевые слова и фразы будут проигнорированы, следовательно, в таблице не будет дубликатов.Использование этой функции значительно расширяет диапазон ключевых слов для семантического ядра за счет набора ключевых слов, которые в большинстве случаев недоступны в инструменте планирования ключевых слов Google AdWords.

Key Collector — значок для поиска предложений на панели инструментов

Все, что вам нужно сделать, это выбрать значок на панели инструментов и вставить ключевые слова или фразы. После того, как вы выберете поисковую систему и регион, программа добавит дополнительные ключевые слова за считанные секунды.

Сборщик ключей позволяет избавиться от слов на основе нескольких факторов с помощью фильтра.Вы можете отредактировать условия, чтобы отфильтровать:

1. Нерелевантные фразы
2. Ключевые слова с низким объемом поиска, CPC, конкуренцией и т. Д.
3. Дубликаты

Key Collector — функция фильтрации

В отличие от настроек фильтрации таблиц Excel, система фильтрации Key Collector выполняет не требуют крови, пота и слез для доведения своего смыслового ядра до совершенства. Он не только предоставляет полный набор инструментов, но и все условия фильтрации можно сохранить для дальнейшего использования в проектах.

На основании полученных данных можно очистить таблицу от тех фраз, для которых частота равна нулю, а также от дубликатов. Если нет необходимости работать на сайте с низкочастотными фразами, то вы можете удалить все фразы, объем поиска которых меньше 10, 20 или 30. Фильтрация также применяется после сбора связанных поисковых запросов, которые будут рассмотрены в следующий абзац.

После того, как все ненужные фразы будут отфильтрованы, вы можете расширить список ключевых слов, отсортировав их по группам, чтобы создать базу данных связанных поисковых запросов.Этот шаг называется «синтаксическим анализом», и он значительно увеличивает количество похожих ключевых слов для каждой группы из выбранной поисковой системы.

Для сбора связанных поисковых запросов:

1. Щелкните значок «G» (Google) в верхней папке
2. Добавьте выбранные фразы
3. Сортировка фраз по группам
4. Начать сбор связанных поисковых запросов и статистики

Связано с Key Collector поисковые запросы

Например, на скриншоте выше видно, что автор отсортировал ключевые слова по таким группам, как молоко, шоколад, макаронные изделия.После процесса «синтаксического анализа» программа собрала 680 связанных поисковых запросов для группы «молоко» с полной статистикой объема поиска по каждому запросу. Дополнительно рекомендуется применять расширенную систему фильтрации для каждой группы.

Это виноватое удовольствие любого SEO-специалиста. Функция предназначена для автоматической пометки всех неявных дубликатов, частота которых меньше в выбранной поисковой системе. Например, между двумя фразами, такими как «снять квартиру рядом» и «снять квартиру поблизости», программа выбирает ту, у которой больше поисков.

Чтобы найти и удалить неявные дубликаты:

1. Щелкните вкладку «Данные» в заголовке
2. Щелкните «Найти неявные дубликаты»
3. Настройте параметры интеллектуального анализа
4. Щелкните «Выполнить интеллектуальный анализ»
5. Щелкните « Удалить отмеченные элементы »

Key Collector — поиск / удаление неявных дубликатов

Если вы хотите проверить позиции сайта в поисковых системах или проверить, какие страницы выдаются по конкретным запросам — Google SERP — идеальный инструмент для вас.Он позволяет определить позицию сайта по заданной ключевой фразе.

Необходимо выполнить простые шаги:

1. Добавьте ключевые слова, по которым вы хотите сканировать позиции веб-сайта для
2. Введите URL-адрес веб-сайта, который вы анализируете
3. Выберите желаемую поисковую систему
4. Укажите регион
5. Проверьте позиции веб-сайт

Key Collector — Анализ результатов поисковой выдачи Google

Имейте в виду, Key Collector — это сложная машина, и представленный материал охватывает только базовые подходы к построению семантического ядра.Что касается цен, программное обеспечение стоит всего 29 долларов за годовую подписку, что является выгодной сделкой с учетом множества предоставляемых функций.

Независимо от того, являетесь ли вы любителем или опытным SEO-специалистом, мы настоятельно рекомендуем вам попробовать потрясающие инструменты Key Collector. Если вам нужна помощь, мы с нетерпением ждем ваших комментариев или вопросов в разделе комментариев. Удачи!

Приложение Шредингера: О ключевых коллекционерах комиксов и их месте в мире спекуляций с комиксами

Есть несколько вещей, которые мне нравятся больше, чем просмотр длинных или коротких коробок, которые я нахожу в антикварных магазинах, секонд-хендах, блошиных рынках и т. Д. надеюсь, что что-то особенное откроется.Скажу честно: редко что-то делает. Обычно они загружаются вариациями одной и той же формулы — обычное сочетание The Nam , несущественных выпусков 80-х из Batman и Detective Comics , и я почти уверен, что все существующие копии названий, связанных с Новой Вселенной — но мои поиски всегда были связаны с одним комиксом: The Incredible Hulk # 181. Вы знаете … первое появление Росомахи? 1 За свою жизнь я просмотрел сотни — возможно, тысячи! — длинных коробок, в надежде раскрыть Святой Грааль моего комикса.

Но я всегда прихожу с пустым. Я нашел много других стоящих комиксов, среди которых моя довольно дрянная, но любимая копия The Avengers # 1, которую я обнаружила в антикварном магазине недалеко от Сиэтла за 10 долларов, была первой. Но The Incredible Hulk # 181 ускользнул от меня. № 183? Много раз. № 179? Тьфу, жестоко, да. Я даже нашел множество проблем того периода с похожим красным цветом вверху с The Incredible Hulk , написанным тем же белым цветом, что и # 181, но это были просто душераздирающие заблуждения.

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

Я знаю это по ряду причин, но я видел это воочию, когда проводил свою первую гаражную распродажу комиксов в 2018 году.Всего за первый день почти 60 человек прошли через мой сборник комиксов и всю жизнь искали свою собственную версию The Incredible Hulk # 181. Многие нашли, что купить, так как несколько клиентов ушли с целой длинной коробкой в ​​руках. Это был чертовски увлекательный опыт, и я часто задавался вопросом, не ошибаюсь ли я, продавая некоторые из своих комиксов.

В тот уик-энд я впервые обнаружил Key Collector Comics, приложение, загруженное с возможностью поиска информации практически обо всех «ключевых» комиксах — которые, для тех, кто не знает, являются важными или заметными комиксами с первым появлением или знаменательными событиями, являющимися квалификаторами — и цены на условия разного качества для каждого.Это приложение было спасением, поскольку помогло ограничить вышеупомянутые ошибки, а именно продажу ценного комикса за 50 центов или меньше. 2

В некотором роде он похож на справочник цен Wizard Magazine, за исключением того, что вместо того, чтобы увязнуть в мелочах истории комиксов 3, он фокусируется на ключах, чтобы упростить жизнь. Эта простота сделала его неотразимым для меня как фаната комиксов. Это был уникально мощный инструмент, который заставил меня почувствовать зуд, которого не удавалось достичь уже довольно долгое время.

С тех выходных в индустрии комиксов произошли некоторые неожиданные сдвиги, поскольку возникло откровенно шокирующее возрождение спекуляций 4, и трудно не связать такое приложение, как Key Collector Comics, с этим явлением. Как человек, которому одновременно нравится приложение и которому интересно узнать о тенденциях индустрии комиксов, я хотел лучше понять, что именно представляет собой Key Collector Comics и как создатель приложения Ник Коглианезе оценивает свое положение на текущем рынке. Итак, сегодня мы собираемся сделать именно это, когда мы углубимся в его происхождение, где он вписывается в сегодняшние комиксы и многое другое, исследуя напряжение, которое существует в индустрии на стыке читателя, коллекционера и спекулянта.

---

Жизнь комиксов Коглианезе началась в типичном месте: в фильме Тима Бертона « Бэтмен » 1989 года. Бэтмен был его «наркотиком для входа в комиксы», поскольку трейлер этого фильма привел его к прочтению новеллизации фильма, которая привела его к книге Фрэнка Миллера «Возвращение темного рыцаря» . На более коротком расстоянии, чем отсюда до Кевина Бэкона, Коглианезе был фанатом комиксов и на всю жизнь был привязан к этим современным мифам.

Для Coglianese было два момента, которые поставили его на путь создания приложения Key Collector Comics.Первым было решение изменить его отношение к комиксам. Как и многие фанаты комиксов, в какой-то момент вы понимаете, что «Вау, они действительно занимают лота и места». Коглианезе в свои 20 лет решил переключиться с покупки комиксов по отдельным выпускам на графические романы — «что не очень помогло сэкономить место», — признал он, — прежде чем сосредоточить свое внимание на ключевых комиксах, на которых в конечном итоге основывался его бизнес.

Вторая была продолжением той смены. Когда-то он управлял сетью сбыта алкогольной продукции, что, естественно, требовало много времени в пути.Как фанат комиксов со здоровым интересом к истории комиксов и вопросам, которые сыграли в них роль, Коглианезе сделал то, что делают многие коллекционеры: он нанес на свой путь магазины комиксов и антикварные магазины, надеясь найти в них что-то особенное. . На тот момент он был вооружен только списком, который он создал в приложении Notes на своем iPhone, — неэффективный метод, который гарантировал, что большую часть его времени он тратил на поиск номеров ошибок, чтобы определить, было ли то, что он нашел, примечательно.

Этот опыт доставил ему огромную радость — кроме того, когда кто-то, просматривая комиксы рядом с ним, нашел что-то раньше, чем он, потому что, как он заметил, «коллекционирование — это очень конкурентный процесс» — и он не делал на этом деньги.Коглианезе утверждает, что продал только один комикс, и он глубоко сожалел о продаже этого комикса, даже отказавшись назвать его из-за своего отчаяния по этому поводу. Вместо этого ценность комикса проистекала из гордости и памяти, которые пришли с их нахождением, как он сказал мне: «Моя память плохая, но я, вероятно, мог бы сказать вам, где я взял каждую из моих ключевых проблем».

«У всех есть истории, напечатанные на их страницах, но у них также есть личная история меня », — добавил он.

Ник Коглианезе из коллекционера ключей, ныряющий глубоко в легион длинных коробок

Этот опыт привел его к идее приложения, когда он наткнулся на то, что он назвал своей «коллекцией Шангри-Ла».«Это идея, к которой стремятся многие коллекционеры, в том числе и вы искренне. Смотришь, смотришь и смотришь, и вот однажды он окажется: коллекция, наполненная сокровищами, о которых ты даже не догадываешься. В то время он жил в Милуоки, и когда он посетил «Даунтаун Букс — куплено и продано» там; он наткнулся на множество замечательных комиксов по шокирующей цене. 5 Когда он спросил владельца магазина о том, какие еще комиксы у него могут быть, Коглианезе обнаружил, что это не вся коллекция владельца.У него на складе было 500 длинных ящиков . После регулярных расследований ему был предоставлен доступ к нему. Четыре месяца спустя, копаясь в этой абсурдно большой коллекции, Coglianese ушел с горой сокровищ и основой идеи приложения Key Collector Comics.

Так что же представляет собой приложение Key Collector Comics? Вы могли бы назвать это ценовым ориентиром. Некоторые называют это инструментом спекулянта. Другие могут просто назвать это подавляющим. Но Коглианес говорит, что это «путеводитель по истории комиксов через ключевые вопросы, которые представили и определили персонажей и вселенные, в которых они существуют.”

«Это ресурс, позволяющий упростить ввод удовольствие от комиксов », — сказал он. «Только представьте себе опыт кого-то ходить на конгресс или даже в магазин комиксов. Строки и ряды ящиков. Стены с сотнями книг. Если вы знаете, что есть персонаж, который вам нравится, и вы хотите узнать, какие были знаменательные моменты в их развитии, вы можете просто открыть Key Collector Comics и начните с этого ».

Как человек, который слышал припев «Откуда ты знаешь, с чего начать?» слишком много раз, чтобы вспоминать, это убедительное объяснение.Это идея очевидной ценности, которая будет иметь значение для определенных типов фанатов комиксов.

Однако идея приложения проста. Это огромная база данных с возможностью поиска, в которой вы можете просматривать названия и персонажей, чтобы найти важные проблемы из их длинных историй, а также получить общее представление о том, сколько они стоят. 6 Ищете первое появление Stilt-Man? Быстрый поиск в приложении показывает, что это Daredevil # 8. Не уверены, что этот случайный выпуск Cable , который у вас есть, чего-то стоит? Приложение может сказать вам! 7

Есть более 100 других разделов, в том числе:

• «Горячие клавиши», который отслеживает, ну, ну, ключевые комиксы, которые популярны.
• «Колода спецификаций» или раздел, предназначенный «только для развлекательных целей», который связывает пользователей с комиксами, которые могут быть потенциально ценными в какой-то момент, причем «спецификация» означает спекуляции.
• «Nick’s Picks Vol. 1 », который представляет собой список из 25 комиксов, созданных Coglianese, которые, как он отметил, могут быть ценными, но в большей степени предназначены для того, чтобы быть интересными. 8

Там много чего еще, но самое поразительное: все это вводится вручную. Coglianese сам вводит данные.Это означает быстрое время обработки, но также и много усилий с его стороны, чтобы все исследовать. Он поделился, что однажды потратил больше часа на определение того, каким именно было первое появление злодея Доктора Стрэнджа Шума-Гората. 9 Это заставляет его оставаться в курсе дел.

«Когда что-то «интересное» объявляется как вариант комикса или новый кастинг, секунд спустя я отправляю своим подписчикам push-уведомление », — сказал он. меня. «Я провожу большую часть своего времени, наблюдая за тем, что происходит в мире комиксов.”

Объявление о моем драгоценном, Невероятном Халке № 181, в Key Collector Comics

Одна вещь, которую я интересовался, как он определяет, что входит, а что нет в приложении. если все самоопределено. У него были правила, которыми он руководствовался в этом упражнении.

«Критерии для комикс, который нужно ввести в базу данных, обычно начинается со значения », — говорит Коглианезе. сказал мне. «Если мы смотрим на что-то от медного века до наших дней, это имеет перепродажу минимум 8 долларов на eBay. Затем я посмотрю на персонажа значение.Если персонаж появлялся более 15 раз или они ответственны за крупное мероприятие, то они тоже войдут. Я добавлю варианты, которые перепродаются не менее чем за 25 долларов, но они отделены от основного база данных, чтобы уменьшить беспорядок.

«Всего там 14 357 выпусков в базе. К концу дня, вероятно, будет около 14 400 ». 10

Что касается предупреждений, на которые он ссылался ранее, у них есть свой собственный набор правил. Как он отмечает, «успех приложения зависит от доверия коллекционера к ресурсу.Таким образом, он гарантирует, что все, что он называет «предупреждением о ключевой проблеме», как он это называет, «является прямым фактом, который повлияет на рынок комиксов, обычно за счет увеличения ценности проблемы». Они доступны только подписчикам, что является дополнительным преимуществом для тех, у кого есть платное членство.

Кстати, давайте поговорим об этих членствах. Как сказал мне Коглианезе, вся база данных — основная задача приложения — бесплатна, но упомянутые выше разделы, такие как «Горячие клавиши» и «Спецификация», а также предупреждения о новых ключах, поставляются с платной подпиской, которая стоит 1 доллар. .99 в месяц или 19,99 долларов в год. Coglianese делает это как для финансирования приложения, так и потому, что именно эти категории «приносят денежную выгоду» пользователям. Эти и партнерские ссылки на eBay на каждом комиксе, перечисленные в списке, которые приносят ему комиссию, но не увеличивают расходы для покупателя, являются тем, что финансирует платформу.

---

Причина, по которой я хотел написать о приложении Key Collector Comics, если честно, заключалась не в его полезности или не в том, что я лично получил от него удовольствие.Причина в том, что он неотделим от бума спекулянтов, который мы наблюдаем сегодня в комиксах. Сайты спекулянтов, доски объявлений и приложения, такие как Key Collector Comics, являются неотъемлемой частью этой тенденции. Они действуют как механизм, который почти диктует, что актуально, а что нет, используя информацию о комиксах для определения ключевых моментов сегодняшнего дня.

Хотя многое из этого основано на фактах — особенно в фильмах или других адаптационных новостях, — другие становятся ситуацией с курицей и яйцом, как и те, которые когда-то подпитывались журналом Wizard Magazine.Некоторые подозревали, что журнал использовался для искусственного увеличения продаж и цен на определенные издания. Это, конечно, вызывает беспокойство и в отношении чего-то вроде приложения Key Collector Comics, поскольку оно может сказать: «Эй, Captain Marvel # 8 — большое дело, потому что оно содержит первое появление Звезды!» или « Reaver # 1 — ключ недели!» и внезапно магазины по всему миру распродаются благодаря быстрому push-уведомлению. Это темная территория, и при ненадлежащем использовании может возникнуть настоящая проблема.Это небольшой шаг к комиксам, эквивалентным инсайдерской торговле.

Взгляните на запись для Reaver # 1 в комиксах Key Collector, помеченную как «Ключ недели» в ту неделю, когда она была выпущена

. Делает ли это такие приложения, как Key Collector Comics, плохой вещью? Это во многом зависит от того, кого вы спрашиваете. Я разговаривал с продавцами о приложении, и у большинства из них были сложные отношения с ним, и один прямо сказал, что они не уверены, что оно подходит для комиксов. Они любят его как ресурс, поскольку он действительно помогает людям в этом отношении.Тем не менее, создание «ключевых» комиксов с сомнительной ценностью и установление ценового руководства были проблемами, как мне сказал один из них: «eBay — это нереальность». Легко понять, почему, поскольку сегодняшние распродажи комиксов со скидками усеяны «ключами» от вчерашнего дня. Краткосрочные спекуляции редко приводят к долгосрочным выгодам, о ком бы вы ни говорили.

Конечно, стоит также отметить, что некоторых розничных продавцов это не просто устраивает, они активно работают с Coglianese. Джесси Джеймс Комикс из Аризоны, например, напрямую сотрудничал с Key Collector Comics, разработав «Коробочный набор комиксов Key Collector», который действовал как слепой ящик для коллекционеров комиксов.Некоторые видят ценность в этих приложениях и сайтах.

Большая часть сложностей возникает из-за напряженности, создаваемой сегодняшним составом покупателей на рынке. На мой взгляд, можно выделить три основных типа. Есть читатели, которые покупают комиксы в основном для того, чтобы читать их. Есть коллекционеры, которые ищут сокровища, которые заставляют их испытывать гордость и радость от того, что они приобрели. Кроме того, есть спекулянты, которые либо хотят на короткое время бросить вызов, либо овладеть следующим гигантом, прежде чем он станет ценным.11

Первый в основном смотрит на эти инструменты как на что-то важное, даже если его руководство им тоже помогает. Для коллекционера безмерный интерес представляют комиксы Key Collector. Я буквально часами просматривал поиск по персонажам и названиям только потому, что считаю историю комиксов увлекательной. Это отстойное время и кое-что, что помогло мне так, как часто делает Википедия, когда в моих знаниях по комиксам есть дыра. А для спекулянтов это очевидная ценность.Для них это похоже на подсчет карт, дающий им преимущество перед другими в их районе с точки зрения приобретения следующей «большой» книги.

Запись о Batman: Damned # 1 на Key Collector Comics

Конечно, магазины уже начали сопротивляться усилиям последнего типа. Розничные продавцы следят за этими приложениями, чтобы узнать, что популярно, и ограничить количество, которое покупатель может купить. Вы можете спросить, зачем они это сделали. Продажа есть продажа, верно? Что ж, если вы продаете весь свой инвентарь Batman Damned # 1 спекулянтам, желающим перевернуть их все на eBay, и вы заказываете выпуск № 2, исходя из идеи, что он был продан в вашем магазине, тогда кто будет покупать выпуск №2? Конечно, это не будут люди, которые собирались купить комикс, чтобы прочитать его, поскольку изначально они не могли купить копию.12 Это неустойчивая практика, которая ставит читателей и спекулянтов почти в прямой конфликт, поскольку успех последних ведет к неудаче первых.

Как я уже сказал, это сложно.

---

Что думает обо всем этом Коглианезе? Он точно ничего не слышал раньше.

«Многие говорили это это приложение для спекулянтов, что понятно, потому что на данный момент оно горячая кнопка, которая привлекает много внимания », — сказал мне Коглианезе.«Тем не менее, среднее время, затрачиваемое на приложение на одного человека, составляет более восьми минут, что Думаю, мне, наверное, не стоит говорить, но меня не уволят.

«Теоретически, как спекулянт, вы можете зайти в приложение, посмотреть раздел спекуляций, найти что нового, может быть, одну или две книги и продолжайте свой день. Тридцать секунд. Но так много интересной информации и (так много) разных категории, (с) новым содержанием, добавляемым в течение дня, которое просто интересно просматривать.”

Как отмечалось выше, это опыт, который я могу подтвердить. Приятно просматривать. Для поклонника комиксов и коллекционеров иногда он предлагает связь с историей средства массовой информации и его персонажами, которые трудно найти. Раньше было практически невозможно найти в одном месте. И одному богу известно, что информации об этом очень много. По оценке Coglianese, аспект спекуляций в приложении составляет лишь примерно один процент его содержания, однако ярлык «приложение спекулянта» — это то, от чего он не может избавиться, несмотря на то, что не было элемента вовлечения спекулянтов с точки зрения содержания до 15 месяцев. его существование.13

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

«Американские комиксы сейчас вплетены в ткань поп-культуры многих культур, и важно сохранить генезис их создания», — сказал мне Коглианезе.Я недавно видел, как это подчеркивается лично.

Объявление о Странных Людях Икс № 282 — первом эпизодическом появлении Бишопа — в Key Collector Comics

. В этом году на гаражной распродаже в моем магазине один из посетителей моего магазина был владельцем местной компании, занимающейся трафаретной печатью и дизайном. Он больше не покупает новые комиксы, но в детстве был большим фанатом, который теперь любит фильмы. Как взрослый человек с настоящими деньгами в наши дни, он стремился приобрести или выкупить известные книги из всей истории комиксов.Он купил первое эпизодическое появление Бишопа у Uncanny X-Men у меня, а также New Mutants # 1, и он по горячим следам преследовал множество ключевых вопросов из истории Людей Икс и Паука. Мужчина. Его не было там, чтобы найти комиксы для перепродажи. Он просто хотел что-то особенное, что он мог бы назвать своим, используя теплые эмоции, которые вызывали у него эти персонажи.

Эти коллекционеры реальны, и они так же важны на рынке, как и все остальные. Но влияние спекулянтов велико, как и его влияние.Я видел это воочию: Friendly Neighborhood Spider-Man # 6 распроданы в моем магазине, прежде чем я смог купить его благодаря этой стороне индустрии. Что вызвало интерес спекулянтов? Это было первое появление Паучьего Укуса, персонажа, который, по предположениям покупателей, станет новым помощником Человека-паука. На самом деле это была совсем не история. Это привело к тому, что многие спекулянты застряли с очень хорошим, но в конечном итоге не таким ценным комиксом. Я спросил Коглианезе об этом названии конкретно.

«Это интересный пример, и то же самое происходит прямо сейчас с Marvel Comics Presents # 6 14, где цены доходят до смешного уровня, но никто не знает, насколько значимым будет персонаж», — сказал он мне. «Спекуляция — палка о двух концах, потому что легко разочароваться, если кто-то занимается ею только ради финансовой выгоды, чрезмерно расширяет свои возможности или имеет нереалистичные ожидания».

Он заметил еще одну вещь о конкретных названиях, привлекающих внимание из-за спекуляций, и это в то время как некоторые книги могут иметь такой искусственный, неустойчивый интерес из-за этого — например, выпуск Friendly Neighborhood Spider-Man — другие может увидеть, что интерес на вторичном рынке стимулирует беспрецедентный рост.Пример, который он использовал, был одним из самых заметных успехов прошлого года: Immortal Hulk . По его мнению, не создатели или персонаж вызвали шумиху, благодаря которой эта игра стала одной из 10 крупнейших продавцов. Это был вторичный рынок.

«Книга действительно не вызывала серьезного интереса, пока возможно, шесть выпусков, и многие из них были связаны с Immortal Hulk # 2, который затмил 100 долларов на вторичном рынке недель. после его выпуска », — сказал мне Коглианезе.« Бессмертный У Hulk # 1 было около 85 тысяч копий, купленных розничными продавцами, которые упали до около 45 тыс. копий было куплено с выпуском №2 и так продолжалось до №16, где количество заказанных копий превысило первый выпуск.

«Я думаю, что во многом это связано со спекуляциями. Он получил люди, чтобы начать читать книгу, чтобы понять, что может произойти так они могут размышлять о проблемах со спиной, которые могут нагреться из-за персонажа реинтродукция. Также для тех, кто собирается в магазин комиксов каждую неделю и видя, что он был распродан, (это) вызвало чувство страха упустить.”

Соедините это с безмерным качеством названия, и вы получите задатки гигантского хита. И хотя Коглианезе строит догадки, они совпадают с реальностью. Я спросил своих друзей в ComicHub — наборе инструментов для розничных продавцов, который также отслеживает сквозные продажи в участвующих магазинах, — и фактические продажи клиентам совпадают с изложенным им сценарием, и теперь название пытается найти свой истинный уровень после заказов из магазины резко увеличились. Нормальное истощение начинает охватывать 20+ проблем.Это не означает, что спекуляции были единственной причиной успеха Immortal Hulk . Но он определенно сыграл свою роль в увиденном подъеме, как в интересах потребителей, так и в плане заметности. 15

Это связано с теорией самого Коглианезе о росте спекулянтов в современных комиксах, и именно так практика упорядочивания открывает возможности для вторичного рынка. Возможно, не случайно, что рост рынка спекулянтов совпал с тем, что розничные торговцы закрывали люки 16 из-за беспорядков в отрасли.В то время как другой заметный бум спекулянтов в 90-х годах сопровождался огромным количеством заказов, пиком которых стал тираж X-Men № 1 в 8,1 миллиона экземпляров, в наши дни печатается гораздо меньше копий. Это ведет к внутреннему дефициту предложения. Однажды у меня был розничный торговец, который предположил, что один-единственный покупатель может завоевать рынок комиксов в одном городе за день, и это реальная вещь. Кроме того, в отличие от 90-х годов, благодаря развитию Интернета появились широкие возможности для связи покупателей и продавцов.Объедините это вместе, и вы получите идеальный рецепт этого штанги.

Обложка Эндрю Робинсона к Человеку-пауку из Friendly Neighborhood # 6

Недавно в Твиттере кто-то спросил меня, можно ли комиксы Moneyball — то есть делать то, что делали бейсбольные команды, и находить неэффективность рынка, чтобы добиться успеха в том, что вы делаете — и вся эта идея является примером того, почему это так сложно. У всех в комиксах свое видение успеха. Это затрудняет поиск подходящего для всех ответа.Издатели хотят продавать комиксы розничным торговцам, но некоторым может быть все равно, приведут ли они к продажам их клиентам. Розничные продавцы хотят продавать клиентам, которые покупают не только этот выпуск, но и следующий выпуск, и тот, который после него. Читатели, коллекционеры и спекулянты действуют с разными целями. Прямой рынок настроен не столько как совместная индустрия, сколько на индустрию боевых действий, хотя это не тот путь, который, вероятно, принесет наибольшую выгоду любому игроку. 17

Но если кто и нашел способ обойти эту систему, так это спекулянтская сторона отрасли.Сегодняшние низкие порядковые номера позволяют обеспечить определенный уровень контроля над рынком, который трудно представить в других отраслях, поскольку существует реальная причина и следствие, связанное с тем, что делают или говорят сайты и приложения, такие как Key Collector Comics. Это заставляет задуматься, популярны ли книги потому, что они на самом деле горячие, или потому, что так написано в этих приложениях. Этот выпуск Friendly Neighborhood Spider-Man — прекрасный тому пример. Он был признан целью из-за уменьшения количества заказов и первого появления очевидного главного персонажа, который при прочтении вопроса оказался не «важным» в том смысле, на который они надеялись.18 Это настоящий интерес, вызванный теоретической ценностью, и часто остается неясным, оправдаются ли последние. Но искусственная стоимость никому не выгодна, что вызывает озабоченность у спекулянтов.

Key Collector Comics является частью игры, будь то Coglianese намеревается быть или нет. Продавец сравнил приложение с Виагарой, что может показаться как досягаемость, но выслушай меня. Виагара изначально задумывалась как сердце лекарства до тех пор, пока они не осознали, что оно имеет гораздо большую ценность, чем то, что мы узнали это для.То же самое и с этим приложением? Нашла ли она свою истинное призвание к чему-то, для чего оно не предназначалось? Опять же, ответы наверняка зависит от того, кого спрашивали.

---

Комиксы о коллекционере ключей предназначен для читателей, желающих узнать больше о своих любимых персонажах.

Комиксы о коллекционере ключей для коллекционеров, которые хотят найти сокровище, о котором они не знали, они всегда хотел.

Комиксы о коллекционере ключей это приложение для спекулянтов, питающее вторичный рынок комиксов, что одновременно и плохо одновременно.

Что это? Если я проголосовали, все трое одновременно, и опять же, это зависит от того, кого вы спрашиваете потому что все дело в том, кто им пользуется. Ценность приложения полностью зависит от на вашу цель с этим. Такова природа почти всего в мире который содержит некоторый уровень власти. Эффективность приложения определяется его пользователем, что делает его не совсем отличным от персонажей, чьи истории он рекламирует. С большой силой приходит большая ответственность и все такое. К сожалению нет все несут ответственность.

Но разве природа комиксов Key Collector? Я так не думаю. Если бросить вызов, чтобы решить будь то чистый положительный или чистый отрицательный результат, я бы выбрал первое, как единое целое так или иначе, это вызывает у людей восторг от комиксов и эмоций, которые связаны с этими специальными проблемами и персонажами.

И после разговора с Коглианезе о том, что он делает, почему он это делает, и обо всем остальном из Key Collector Comics, я искренне верю, что он не какой-то злодей с усами, подпитывающий рынок спекулянтов.Он страстный поклонник и коллекционер комиксов, и делится этим через свое приложение. Я спросил его о его любви к комиксам и длинному нырянию с боксом, и, честно говоря, я многое увидел в том, что он сказал.

Обложка вечно преследуемого Невероятного Халка # 181

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

«Ваше сердце немного заскакивает».

Это шутка, которую я мог бы представить своей жене после того, как часами провел в антикварном магазине, просматривая длинные коробки, бесконечно следуя The Incredible Hulk # 181. Странная вещь в опыте такого фаната комиксов, как Коглианезе или я, заключается в том, что покупка такого комикса в обычном качестве — скажем, покупка его на eBay — просто не будет прежней.Речь идет о погоне и об эмоциях, связанных с поиском чего-то, что значит для вас весь мир в груде комиксов, которые в противном случае были забыты.

Неудивительно, что в отрасли сложилась сложная отношения с Key Collector Comics и подобными сервисами. Несмотря на В соответствии с намерениями Коглианеса, некоторые используют приложение в качестве руководства для таких игр, как No One Left to Fight или Reaver , просто потому, что это предлагается каждая первая проблема может быть горячей, обеспечивая шаткое положение, в котором основная часть инвентаря достается спекулянтам, а не читателям.Может быть хорошо с этим — кажется, будто Бессмертный Халк извлекли выгоду из интереса вторичного рынка, подняв его до законного положения — но и плохо.

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

Установка и развертывание коллектора

| Документация InsightIDR

Следующий процесс связывает Collector в вашей сети с Amazon Web Services (AWS), где размещены серверы InsightIDR. Обратите внимание, что учетные данные не хранятся в AWS.

Для облачных сред установка Collector необходима для понимания взаимосвязи между IP-адресами и активами. Чтобы атрибутировать активы, вы должны установить Insight Agent на все активы в вашей среде и подготовить сборщик для доставки журналов агента в InsightIDR.Insight Agent — единственный источник актуальной информации об IP-адресе хоста в облачных средах. Системы, на которых запущен агент Insight Agent, должны иметь доступ к сети для связи с сборщиком через порты 5508, 6608 и 8037, а сборщик должен иметь возможность подключаться к платформе Insight через порт 443. Дополнительные сведения см. В разделе «Порты, используемые InsightIDR».

Вы можете установить Collector в следующих операционных системах:

Кроме того, просмотрите раздел «Обработка сборщика и развертывание в вашей сети» для наиболее простого перехода.

Настройка исключения антивируса

Приложения безопасности конечных точек (такие как McAfee Threat Intelligence Exchange, CylancePROTECT, Carbon Black и другие) могут помечать, блокировать или удалять сборщик из ваших активов в зависимости от ваших настроек обнаружения и ответа.

Чтобы этого не произошло, мы рекомендуем вам настроить правило списка разрешений для каталога сборщика, чтобы ваше программное обеспечение безопасности конечных точек случайно не нацелилось на него.

Установка

Чтобы загрузить и установить файл Collector:

1. Перейдите в свою учетную запись в Insight.rapid7.com.
2. В левом меню выберите вкладку Сбор данных .
3. Выберите меню Setup Collector из доступного раскрывающегося списка и выберите свою операционную систему.

Установка Windows

Начнется загрузка zip-файла. Это будет исполняемый файл.

Обратите внимание, что вы можете загрузить пакет установщика Collector на свой локальный компьютер, а затем передать исполняемый файл на хост сервера Collector, если это проще, чем загрузка напрямую с хоста сервера.

1. Запустите файл .exe и следуйте инструкциям мастера приложения. Допустимы все параметры установки по умолчанию.
2. Скопируйте ключ активации из мастера, чтобы связать установленное программное обеспечение с InsightIDR.
3. Вернитесь к InsightIDR в своем веб-браузере и выберите Data Collection слева.
4. В раскрывающемся меню справа выберите Setup Collector , а затем выберите Activate Collector.

5. Дайте имя Collector, а затем введите ключ активации из мастера установки.
6. Нажмите кнопку Активировать .

Установка Linux

Программа установки Linux .sh загрузится на ваш компьютер. Убедитесь, что у вас есть права на чтение и запись на вашем компьютере, чтобы внести эти изменения.

Чтобы установить Collector на удаленном хосте Linux:

1. Отправьте сценарий установщика InsightSetup-Linux64.sh на целевой хост Linux, используя выбранный вами метод.
2. SSH в целевую систему и перейдите в текущий каталог установщика.
3. Измените разрешения сценария, чтобы сделать его исполняемым, с помощью следующей команды: chmod + x InsightSetup-Linux64.sh
4. Запустите следующий сценарий от имени пользователя root, чтобы запустить установщик: sudo ./InsightSetup-Linux64.sh
5. Мастер терминала проведет вас через процесс установки. Просмотрите системные настройки и запросы лицензии, чтобы начать установку.
6. По завершении установки скопируйте значение, показанное рядом с Ключ агента:
7. Вернитесь к InsightIDR в своем веб-браузере и выберите Data Collection слева.
8. В раскрывающемся меню справа выберите Setup Collector , а затем выберите Activate Collector.
9. Дайте имя Collector, а затем введите ключ активации из мастера установки.
10. Нажмите кнопку Активировать .

Обработка сборщика

При нажатии кнопки «Активировать» вы увидите, что процесс активации начинается с сообщением о состоянии «Ожидание подключения …».

Это может занять несколько минут, поскольку ваше локальное программное обеспечение Collector достигает платформы Insight и передает общий секрет (ключ активации).После завершения первоначального рукопожатия будет сгенерирована уникальная пара криптографических ключей. Эти криптографические ключи используются для всех последующих коммуникаций платформы Collector с Insight. После обмена ключами вы должны увидеть показатели работоспособности хоста сервера.

Развертывание в сети

Если все требования соблюдены, InsightIDR должен работать и собирать данные в течение нескольких минут. Установка Collector похожа на «рукопожатие» между системой и платформой, которое затем позволяет InsightIDR видеть и собирать данные из ранее настроенных источников событий.

Вы можете сразу приступить к добавлению источников событий; просто нажмите на тот, который хотите добавить, и заполните необходимые поля. Для получения дополнительной информации см. Источники событий InsightIDR.

Устранение неполадок

Для получения дополнительной информации см. Устранение неполадок коллектора.

Настройка сборщика потоков — Snowplow Docs

Stream Collector имеет ряд доступных параметров конфигурации.

Базовая конфигурация

Шаблон

Загрузите файл конфигурации шаблона с GitHub: config.hocon.sample.

Теперь откройте файл config.hocon.sample в любом редакторе.

Конфигурация потока

Вам нужно будет указать имена ваших хороших и плохих потоков:

• collector.streams.good : имя хорошего входного потока инструмента, который вы выбираете в качестве приемника. Это поток, в котором будут храниться успешно собранные события.
• сборщик.streams.bad : имя неверного входного потока инструмента, который вы выбрали в качестве приемника. Это поток, в котором будут храниться плохие строки. В настоящее время сборщик может создавать два типа плохих строк. Плохая строка size_violation указывает, что событие было слишком большим, чтобы соответствовать ограничениям потока для отдельных записей — 1 МБ для Kinesis и 256 КБ для SQS. generic_error неправильная строка оборачивает ошибки, возникающие, когда строка запроса не может быть проанализирована, например, из-за недопустимых символов.
• collector.streams.useIpAddressAsPartitionKey : использовать ли IP входящего события в качестве ключа раздела для хорошего потока / темы. (Этот параметр применяется к приемнику Kinesis, но не к приемнику SQS.)

Настройки HTTP

Также проверьте настройки службы HTTP:

• интерфейс коллектора
• порт коллектора

Настройки буфера

Вам также необходимо установить соответствующие лимиты для:

• коллектор.streams.buffer.byteLimit (максимально разрешено для Kinesis — 1000000, а для SQS 256000)
• collector.streams.buffer.recordLimit (максимально разрешено для Kinesis — 500 и для SQS 10)
• collector.streams.buffer. timeLimit

Этот буфер заполняется событиями по мере их поступления на сборщик и сбрасывается при каждом достижении одного из указанных выше пороговых значений. Параметры byteLimit и recordLimit обеспечивают соблюдение ограничений Kinesis и SQS на размер запросов на запись.Нет ограничений на значение timeLimit .

Дополнительные возможности конфигурации

Мойки

Параметр collector.streams.sink.enabled определяет, в какой из поддерживаемых приемников записывать необработанные события:

• «kinesis» для записи Thrift-сериализованных записей и строк ошибок в поток Kinesis
• «kafka» для записи Thrift-сериализованных записей и строк ошибок в тему Kafka
• «googlepubsub» для записи Thrift -сериализовать записи и строки ошибок в тему Google PubSub
• "stdout" для записи сериализованных в формате Base64 записей и строк ошибок в stdout и stderr соответственно
• "nsq" для записи сериализованных записей и ошибок в кодировке Thrift строк в тему NSQ
• «sqs» для записи сериализованных записей и строк ошибок в очередь SQS.

Если вы переключаетесь на "stdout" , мы рекомендуем установить ‘Akka.loglevel = OFF’ и ‘akka.loggers = []’ для предотвращения отладки Akka. информация о загрязнении вашего потока событий на stdout.

Вы должны заполнить оставшуюся часть раздела collector.streams.sink в соответствии с вашим выбором в качестве раковина.

Чтобы использовать stdout как приемник, закомментируйте все в collector.streams.sink , но collector.streams.sink.enabled , который должен быть установлен на stdout .

Для SQS убедитесь, что вы настроили стандартную очередь, а не FIFO.

Заголовок политики P3P установлен в collector.p3p , и если не установлен, заголовок политики P3P по умолчанию:

 
  policyRef = "/ w3c / p3p.xml", CP = "NOI DSP COR NID PSA OUR IND COM NAV STA"  
  Язык кода: JavaScript (javascript)  

Установка доменного имени

Задайте имя файла cookie с помощью сборщика .cookie.name настройка. Для обеспечения обратной совместимости с более ранними версиями сборщика используйте строку «sp» в качестве имени файла cookie.

Сборщик отвечает на действительные запросы заголовком Set-Cookie , который может указывать или не указывать домен для файла cookie.

Если домен не указан, cookie будет установлен для полного домена сборщика, например collector.snplow.com . Это будет означать, что приложения, запущенные в другом месте на *.snplow.com не сможет получить к нему доступ. Если вам не нужно предоставлять доступ к cookie из других приложений в домене, то вы можете игнорировать настройки доменов и fallbackDomain .

В более ранних версиях можно было указать домен для привязки файла cookie. Например, если установить значение .snplow.com , файл cookie был бы доступен другим приложениям, работающим на * .snplow.com . Чтобы сделать то же самое в этой версии, используйте параметр fallbackDomain , но убедитесь, что больше не включает начальную точку:

 
  fallbackDomain = "snplow.com " 
  Язык кода: JavaScript (javascript)  

Установленный сборщиком файл cookie может обрабатываться браузерами по-разному в зависимости от того, считается ли он основным или сторонним файлом cookie. В более ранних версиях (0.15.0 и ранее), если у вас было две конечные точки сборщика, одна на коллекторе .snplow.com и одна на коллекторе .snplow.net , вы могли указать только один из этих доменов в конфигурации. Это означало, что вы могли установить только сторонние файлы cookie на стороне сервера .snplow.com или .snplow.net , но не на обоих. Начиная с версии 0.16.0, вы можете указать список доменов, которые будут использоваться для cookie ( обратите внимание на отсутствие начальной точки ):

 
  доменов = [
  "snplow.com"
  "snplow.net"
]  
  Язык кода: JavaScript (javascript)  

Какой домен будет использоваться в заголовке Set-Cookie , определяется путем сопоставления доменов из Origin заголовок запроса в указанный список.Используется первое совпадение. Если совпадений не найдено, будет использоваться резервный домен, если настроен. Если fallbackDomain не настроен, cookie будет привязан к полному домену сборщика.

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

Примеры:

• domain.com будет соответствовать заголовкам Origin , таким как домен .com , www.domain.com и secure.client.domain.com
• client.domain.com будет соответствовать заголовку Origin , например, secure.client.domain.com , но не domain.com или www.domain.com .

Отключение файлов cookie

Настройку cookie из сборщика можно полностью отключить в конфигурационном файле:

 
  cookie {
  включен = ложь
...
}  
  Язык кода: JavaScript (javascript)  

Независимо от этого параметра, если сборщик получит запрос с настраиваемым заголовком SP-Anonymous: * , cookie не будет установлен.Вы можете контролировать, установлен ли этот заголовок в вашей реализации отслеживания.

Настройка атрибутов

Secure , HttpOnly и SameSite для файла cookie

Вы можете управлять значениями этих атрибутов в заголовке ответа Set-Cookie , указав их в файле collector.cookie :

 
  secure = true
httpOnly = false
sameSite = "None"  
  Язык кода: PHP (php)  

Параметр sameSite является необязательным.Если вы его опустите, будет принято значение по умолчанию Нет .

Установка продолжительности cookie

Срок действия cookie установлен в collector.cookie.expiration . Если значение не указано, cookie по умолчанию истекает через год (т. Е. 365 дней). Если вы вообще не хотите устанавливать сторонний файл cookie, его можно отключить, установив для collector.cookie.enabled значение false . Как вариант, можно было бы добиться, если бы коллектор .cookie.expiration имеет значение 0 (начиная с версии 0.4.0).

Настройка пользовательских путей

Сборщик отвечает файлом cookie на запросы с путем, который соответствует протоколу поставщика / версии . Ожидаемые значения:

• com.snowplowanalytics.snowplow / tp2 для протокола отслеживания 2
• r / tp2 для редиректов
• com.snowplowanalytics.iglu / v1 для Iglu Webhook.

Вы также можете сопоставить любой допустимый путь (т. Е. Двухсегментный) одному из трех значений по умолчанию через коллектор .дорожки раздел конфигурационного файла. Ваш собственный путь должен быть ключом и значение должно быть одним из соответствующих путей по умолчанию. Оба должны быть полные допустимые пути, начинающиеся с косой черты в начале:

 
  пути {
  "/com.acme/track" = "/com.snowplowanalytics.snowplow/tp2"
  "/com.acme/redirect" = "/ r / tp2"
  "/com.acme/iglu" = "/com.snowplowanalytics.iglu/v1"
}  
  Язык кода: JavaScript (javascript)  

Привязка порта TLS и сертификат (до 2.4.0)

В качестве дополнительной меры безопасности теперь можно прервать соединение TLS / SSL непосредственно в scala-stream-collector с помощью проверенной в бою Lightbend SSL Config. Мы ввели несколько новых параметров конфигурации, чтобы приспособиться к различным рабочим процессам и конфигурациям. Есть два раздела конфигурации, которые можно переопределить для достижения ожидаемого рабочего процесса: collector.ssl и ssl-config .

Первый раздел высокого уровня, который позволяет:

• коллектор.ssl.enable — включить ssl termination
• collector.ssl.redirect — нужно ли выполнять автоматическое обновление с http на https
• collector.ssl.port — порт, на котором должен быть запущен сервер TLS / SSL

Последний позволяет использовать низкоуровневую конфигурацию TLS / SSL, предоставляемую Lightbend SSL Config. Например, для запуска сервера автоматического обновления с поддержкой SSL можно использовать следующую конфигурацию:

 ssl {
  enable = true
  redirect = true
  порт = 443
} 

Однако эта конфигурация будет использовать определенные средой сертификаты, прикрепленные к JVM.Чтобы переопределить поведение по умолчанию и использовать настраиваемый сертификат, низкоуровневый раздел можно определить как:

 ssl-config {
  keyManager = {
    магазины = [
      {type = "PKCS12", classpath = false, path = $ {CERT_FILE}, password = "pass"}
    ]
  }
}


 

Привязка порта TLS и сертификат (2.4.0+)

Начиная с версии 2.4.0, сертификаты были удалены из раздела конфигурации « akka » в параметры системы JVM. Раздел « Настройка JSSE » в справочной документации Java 11 JSSE подробно объясняет все системные свойства.Блок конфигурации SSL по-прежнему требуется.

 ssl {
  enable = true
  redirect = true
  порт = 443
} 

Следующие свойства JVM используются чаще всего.

Системное свойство	Пользовательский элемент	По умолчанию	Примечания
javax.net.ssl.keyStore	Хранилище ключей по умолчанию; см. Настройка хранилищ ключей и доверенных хранилищ по умолчанию, типов хранилищ и паролей хранилищ	Нет
javax.net.ssl.keyStorePassword	Пароль хранилища ключей по умолчанию; см. Настройка хранилищ ключей и доверенных хранилищ по умолчанию, типов хранилищ и паролей хранилищ	Нет	Не рекомендуется указывать пароль таким образом, чтобы его могли обнаружить другие пользователи. Пароль не может быть пустым.
javax.net.ssl.keyStoreType	Тип хранилища ключей по умолчанию; см. Настройка хранилищ ключей и доверенных хранилищ по умолчанию, типов хранилищ и паролей хранилищ	PKCS12
jdk.tls.server.cipherSuites	Наборы шифров, включенные по умолчанию на стороне сервера. См. Определение включенных наборов шифров по умолчанию	См. Наборы шифров SunJSSE, чтобы определить, какие наборы шифров включены по умолчанию.	Внимание: Эти системные свойства можно использовать для настройки слабых наборов шифров, или настроенные наборы шифров могут быть слабыми в будущем. Не рекомендуется использовать эти системные свойства без понимания рисков.
jdk.tls.server.protocols	Протоколы установления связи по умолчанию для серверов TLS / DTLS. См. Поставщик SunJSSE	Нет	Чтобы настроить включенный по умолчанию набор протоколов на стороне сервера поставщика SunJSSE, укажите протоколы в списке, разделенном запятыми, в кавычках. Протоколы в этом списке являются стандартными именами протоколов SSL, как описано в разделе «Имена стандартных алгоритмов безопасности Java». Обратите внимание, что это Системное Свойство влияет только на набор протоколов по умолчанию (SSLContext алгоритмов SSL, TLS и DTLS).Если приложение использует зависящий от версии SSLContext (SSLv3, TLSv1, TLSv1.1, TLSv1.2, TLSv1.3, DTLSv1.0 или DTLSv1.2) или явно устанавливает версию включенного протокола, это Системное Свойство не влияет .

Настройка буфера SQS (2.0.0+)

Отсутствие автоматического масштабирования в Kinesis приводит к дросселированию потоков в случае пиков трафика, и Stream Collector начинает накапливать события, чтобы повторить их позже. Если накопление продолжается достаточно долго, Stream Collector исчерпает память.Чтобы предотвратить возможность поломки сборщика, мы решили сделать возможным настройку буфера SQS, который может обеспечить дополнительную уверенность во время экстремальных всплесков трафика.

SQS используется для постановки в очередь любого сообщения, которое Stream Collector не смог отправить в Kinesis, а приложение sqs2kinesis затем отвечает за чтение сообщений из SQS и запись в Kinesis, когда оно будет готово. В случае каких-либо сбоев API AWS существует механизм повтора, который пытается отправить очередь SQS 10 раз.

Ключи, настроенные для потока Kinesis, хранятся как атрибуты сообщения SQS для сохранения информации. Обратите внимание: сообщения SQS не могут быть такими большими, как сообщения Kinesis. Предел составляет 256 КБ на сообщение, но мы отправляем сообщения в кодировке Base64, поэтому ограничение снижается до 192 КБ для исходного сообщения.

Настройка очередей SQS

(Этот раздел применим только к случаю, когда SQS используется в качестве резервного приемника, когда Kinesis недоступен. Если вы используете SQS в качестве основного приемника, то настройки ниже следует игнорировать, а потоки хорошие и плохие должны настраиваться как обычно под потока.хорошие и потоков. плохие соответственно.)

Чтобы начать использовать эту функцию, вам сначала необходимо настроить очереди SQS. Две отдельные очереди требуются для хороших (сырых) событий и плохих событий. Затем сборщик должен быть проинформирован об именах очередей, и это можно сделать, добавив их как записи в файл config.hocon:

.

 
  sqsGoodBuffer = {хороший-sqs-queue-url}
sqsBadBuffer = {bad-sqs-queue-url}  
 

Телеметрия

Начиная с версии 2.4.0 снегоочистителя сборщика будет собирать сердцебиение с некоторой метаинформацией о приложении. Это функция отказа, означающая, что она должна быть явно отключена, чтобы остановить ее. Схема доступна здесь.

В базе телеметрия отправляет имя и версию приложения каждый час. Это сделано для того, чтобы помочь нам улучшить продукт, нам нужно понять, что популярно, чтобы мы могли сосредоточить наши усилия на разработке в нужном месте. Вы можете помочь нам, указав userProvidedId в файле конфигурации.

 телеметрия {
    userProvidedId = myCompany
 } 

Поместите следующую запись в файл конфигурации, чтобы отключить телеметрию.

 телеметрия {
    disable = true
 } 

Exabeam Data Lake Database Log Collector

Для создания сертификатов и установления безопасного соединения от хоста сборщика к базе данных MySQL:

Примечание

В следующем примере папка / mysql_keys представляет каталог хранилища ключей.

1. Выполните следующие команды для создания ключей центра сертификации (CA):

    openssl genrsa 2048> /mysql_keys/ca-key.pem
   openssl req -sha1 -new -x509 -nodes -days 3650 -key /mysql_keys/ca-key.pem> /mysql_keys/ca-cert.pem 

2. Выполните следующие команды, чтобы создать ключ SSL и сертификат сервера:

    openssl req -sha1 -newkey rsa: 2048 -days 3650 -nodes -keyout /mysql_keys/server-key.pem> /mysql_keys/server-req.pem
   openssl x509 -sha1 -req -in / mysql_keys / server-req.pem -days 3650 -CA /mysql_keys/ca-cert.pem -CAkey /mysql_keys/ca-key.pem -set_serial 01> /mysql_keys/server-cert.pem
   openssl rsa -in /mysql_keys/server-key.pem -out /mysql_keys/server-key.pem 

3. Выполните следующие команды, чтобы создать клиентский ключ SSL и сертификат:

    openssl req -sha1 -newkey rsa: 2048 -days 3650 -nodes -keyout /mysql_keys/client-key.pem> /mysql_keys/client-req.pem
   openssl x509 -sha1 -req -in /mysql_keys/client-req.pem -days 3650 -CA / mysql_keys / ca-cert.pem -CAkey /mysql_keys/ca-key.pem -set_serial 01> /mysql_keys/client-cert.pem
   openssl rsa -in /mysql_keys/client-key.pem -out /mysql_keys/client-key.pem 

4. Импортировать клиентский закрытый ключ и сертификат в хранилище ключей:

    openssl pkcs12 -export -in client-cert.pem - inkey client-key.pem -name "mysqlclient" -passout pass: mypassword -out client-keystore.p12
   keytool -importkeystore -srckeystore client-keystore.p12 -srcstoretype pkcs12 -srcstorepass mypassword -destkeystore keystore -deststoretype JKS -deststorepass mypassword 

5. Импортировать сертификат ЦС в trustore:

   Myportimportaliasqlc-ac-keytool -AC.pem \ -keystore truststore -storepass mypassword

6. Отправить хранилище доверенных сертификатов и хранилище ключей на сервер LMS.

1. Откройте файл /etc/my.cnf в любом текстовом редакторе.

2. Вставьте следующие строки в раздел [mysqld] файла my.cnf :

    ssl-cipher = DHE-RSA-AES256-SHA
   ssl-ca = / mysql_keys / ca-cert.pem
   ssl-cert = / mysql_keys / server-cert.pem
   ssl-key = / mysql_keys / ключ-сервер.pem 

3. Вставьте следующие строки в раздел [client] файла my.cnf (если раздел [client] не существует, необходимо добавить раздел [client] ):

    SSL-сертификат = / mysql_keys / client-cert.pem
   ssl-key = / mysql_keys / client-key.pem 

4. Ваш обновленный файл my.cnf должен выглядеть следующим образом:

    [mysqld]
   max_connections = 500
   журнал медленных запросов
   
   max_allowed_packet = 268435456
   open_files_limit = 10000
   по умолчанию-хранилище-движок = MyISAM
   innodb_file_per_table = 1
   схема производительности = 0
   
   ssl-cipher = DHE-RSA-AES256-SHA
   ssl-ca = / mysql_keys / ca-cert.pem
   ssl-cert = / mysql_keys / server-cert.pem
   ssl-ключ = / mysql_keys / server-key.pem
   [клиент]
   ssl-cert = / mysql_keys / client-cert.pem
   ssl-key = / mysql_keys / client-key.pem 

5. Сохраните изменения в файле /etc/my.cnf и выйдите из текстового редактора.

6. Выполните следующую команду, чтобы обновить права доступа к файлам каталога / mysql_keys и его файлов:

    chown -Rf mysql. / mysql_keys 

7. Перезапустите MySQL:

    sudo systemctl restart mysqld 

   Просмотрите активную конфигурацию SSL MySQL для проверки активности:

    mysql -e "показать такие переменные, как '% ssl%';"
   Результат будет напоминать следующий пример:
   + --------------- + ------------------------ +
   | Имя_переменной | Значение |
   + --------------- + ------------------------ +
   | have_openssl | ДА |
   | have_ssl | ДА |
   | ssl_ca | / mysql_keys / ca-cert.пем |
   | ssl_capath | |
   | ssl_cert | /mysql_keys/server-cert.pem |
   | ssl_cipher | DHE-RSA-AES256-SHA |
   | ssl_key | /mysql_keys/server-key.pem |
   + --------------- + ------------------------ + 

MySQL может проверять X Атрибуты сертификата .509 в дополнение к обычной аутентификации, основанной на имени пользователя и учетных данных. Чтобы ограничить доступ только с некоторых хостов, мы можем сделать это с помощью SSL-сертификатов на стороне клиента. Задайте параметры сертификата, которые мы хотим проверить для конкретного клиента и пользователя, изменив GRANT пользователя, что означает, что у клиента должен быть действующий сертификат:

1. Grant all на testdb.* — testuser , идентифицированный паролем , требует X509; перезапустите службу базы данных MySQL:

    sudo systemctl restart mysqld 

2. Откройте порт 3306 в правилах брандмауэра или просто остановите брандмауэр на сервере.

1. Поместите хранилище доверенных сертификатов и хранилище ключей в этот каталог:

    / opt / exabeam / config / common / kafka / ssl / 

2. Поместите загруженный драйвер MySQL JDBC (например, mysql-connector- java-5.1.42-bin.jar) в:

    / opt / exabeam / data / lms / dblog 

3. Добавить доверенных сертификатов и ключей в dblog jvm.options файл:

   1. Открыть jvm. :

       sudo vim /opt/exabeam/config/lms/dblog/jvm.options 

   2. Добавьте это в конец файла:

       -Djavax.net.ssl.trustStore = / opt / logstash / ssl / <ИМЯ ФАЙЛА TRUSTSTORE>
      -Djavax.net.ssl.trustStoreType = JKS
      -Djavax.net.ssl.trustStorePassword = <ПАРОЛЬ TRUSTSTORE> -Djavax.net.ssl.keyStore = / opt / logstash / ssl / <ИМЯ ФАЙЛА КЛЮЧЕВОГО ХРАНИЛИЩА> -Djavax.net.ssl.keyStoreType = JKS-Djavax.net.ssl.keyStorePassword = <КЛЮЧ-ПАРОЛЬ> 

4. Настройте jdbc_connection_string во входном файле logstash dblog для подключения к базе данных Oracle:

   Расположение файла:

    sudo vim /opt/exabeam/config/lms/dblog/conf/log-input-db 

   Строка подключения:

    jdbc: mysql: // <ИМЯ ХОСТА СЕРВЕРА>: 3306 / <ИМЯ БАЗЫ ДАННЫХ>? UseSSL = true & verifyServerCertificate = true & requireSSL = true 

   Пример входного файла logstash:

    input {
   # пример конфигурации для подключения к БД MySQL
   jdbc {
   jdbc_driver_library => "/ opt / jdbc-drivers / mysql-connector-java-5.1.42-bin.jar "
   jdbc_driver_class => "com.mysql.jdbc.Driver"
   jdbc_connection_string => "
   jdbc: mysql: //10.10.2.181: 3306 / testdb? useSSL = true & verifyServerCertificate = true & requireSSL = true "
   jdbc_user => "testuser" jdbc_password => "пароль"
   jdbc_validate_connection => истина
   расписание => "* * * * *"
   заявление => «ВЫБРАТЬ * от клиентов»
   last_run_metadata_path => "/opt/logstash/config/.last_run"
   } 

   Подождите 3 минуты, а затем проверьте журналы dblog, чтобы проверить активность.

    sudo journalctl -u exabeam-lms-dblog -e 

   Должно быть найдено следующее сообщение:

    [2018-09-28T14: 26: 00,157] [INFO] [logstash.inputs.jdbc] (0,000767s) SELECT * от клиентов 

Устранение неполадок сборщика OPC, который не запускается | Документация по Historian 8.1

Если сборщик OPC не запускается при перезагрузке компьютера, это может быть вызвано следующими причинами:

• Сборщику недостаточно свободного места для создания файлов буфера при запуске.
• Historian пытается запустить сборщик OPC до полного запуска сервера OPC.

Чтобы изолировать причину проблемы перезапуска, просмотрите файл журнала OPC Collector в папке C: \ Historian Data \ LogFiles или последние сообщения журнала в средстве просмотра событий Windows. Как только вы определите, что может быть причиной проблемы, вы можете попытаться исправить ее, добавив новый параметр DWORD , MinimumDiskFreeBufferSize , в реестр Windows для OPC Collector.

Советы по просмотру сообщений журнала сборщика OPC

При просмотре файла журнала сборщика OPC или сообщений журнала из средства просмотра событий имейте в виду:

• Если вы заметили сообщение о том, что Historian не смог создать буферные файлы, то проблема, скорее всего, заключается в том, что у вас недостаточно свободного места для файлов буферов.
• Если вы заметили попытку подключения OPC Collector, попытку инициализации COM, а затем завершение работы, причиной ошибки, скорее всего, является то, что OPC Collector пытается запустить до полного запуска OPC Server.
• Если вы посмотрите файлы журнала и не увидите ничего особенного, кроме попытки запуска и сообщения о завершении работы, то начните с предположения, что сервер OPC не запускается полностью. Если обходной путь для этой проблемы не работает, попробуйте отрегулировать размер буфера.

Если недостаточно свободного места для файлов буфера

Если окажется, что для файлов буферов недостаточно свободного места, либо освободите дисковое пространство, либо измените размер буфера в реестре Windows, добавив новое значение DWORD , MinimumDiskFreeBufferSize , для OPC Collector.В качестве рекомендации попробуйте использовать 10 или 20 МБ в качестве значения размера буфера. Если проблема все еще существует, попробуйте немного уменьшить значение, пока не найдете то, что работает.

1. Выберите «Выполнить» в меню «Пуск». Появится диалоговое окно «Выполнить».
2. Введите Regedit и нажмите Enter. Появится редактор реестра.
3. Найдите ключ ComputerName_OPC1_CollectorName , где ComputerName — это имя вашего компьютера, OPC1 — назначенное значение, а CollectorName — имя вашего коллектора.Вы можете найти этот ключ здесь:

     HKEY_LOCAL_MACHINE \ SOFTWARE \ Intellution, Inc. \ iHistorian \ Services \ OPCCollector \ ComputerName_OPC1_CollectorName4  

4. Добавьте новое значение DWORD . Введите имя MinimumDiskFreeBufferSize , выберите десятичный вариант и установите для значения небольшое число, например 10 или 20. Введенное вами значение представляет количество МБ.
5. Закройте реестр Windows и перезагрузите компьютер.
6. Если Collector не подключается к Historian Server, проверьте файл журнала в папке Logfiles на компьютере-сборщике.

   Если в журнале все еще указано, что Historian ??? не смог создать буферные файлы ???, то повторите шаги 1-6, на этот раз с меньшим числом.

После того, как коллектор OPC подключается к Historian Server, коллектор также должен появиться в Historian Administrator. Затем вы можете изменить размер файла буфера в нижней части вкладки General сборщика.

Сборщик OPC пытается запуститься до полного запуска сервера OPC

Если выясняется, что OPC Collector запускается до запуска OPC Server, вам необходимо указать время задержки для запуска OPC Collector.Чтобы указать эту временную задержку, вы добавляете новое значение DWORD , MachineUpTimeDelay , в реестр Windows для сборщика OPC. Вы можете установить значение этого DWORD равным количеству секунд, в течение которых сборщик OPC откладывает свой запуск. Рекомендуется сначала попробовать 120 секунд. Если проблема все еще существует, попробуйте немного увеличить значение, пока не найдете то, что работает.

Коллектор OPC зависает при первом чтении опроса

Если чтение по запросу начинается более чем за несколько секунд, когда сборщик OPC опрашивает ваш сервер OPC, вам может потребоваться изменить режим First Read Mode , используемый сборщиком OPC.Укажите режим, используя REGEDIT , чтобы создать значение DWORD OPCFirstReadMode в сборщике OPC. Точный файл REG не может быть предоставлен, поскольку он отличается для разных серверов OPC, но вот пример для редактора реестра Windows версии 5.00:

  HKEY_LOCAL_MACHINE \ SOFTWARE \ Intellution, Inc. \ iHistorian \ Services \ OPCCollector \ T20_OPC_Matrikimulation_OPC_OPC_OPC_OPC_OPC_ OPCFirstReadMode "= dword: 00000001  

Допустимые значения: 1 и 2, 2 — значение по умолчанию.

Используйте 1, чтобы сборщик выполнял более быстрое чтение OPC_DS_CACHE при первом опросе вместо более медленного чтения OPC_ DS_DEVICE .

Примечание. Для создания или изменения значения требуется перезапуск коллектора.

Проверка элементов перед добавлением в группу сбора по опросу

Чтобы проверить элементы перед добавлением их в опрашиваемые группы сбора из сборщика OPC, вам может потребоваться использовать OPCValidateBeforeAdd .Укажите режим, используя REGEDIT , чтобы создать значение DWORD OPCValidateBeforeAdd под сборщиком OPC. Невозможно предоставить точный файл REG , поскольку он отличается для разных серверов OPC, но вот пример:

  [HKEY_LOCAL_MACHINE \ SOFTWARE \ Intellution, Inc. \ iHistorian \ Services \ OPCCollector \ MYPC_OPC_Matrikon_OPC_Simulation
«OPCValidateBeforeAdd» = dword: 00000001  

Установите значение 1, если вы хотите, чтобы сборщик OPC проверял элементы перед добавлением их в опрашиваемую коллекцию.

Пример: задержка запуска сборщика OPC для сервера OPC CIMPLICITY

Чтобы добавить задержку запуска для OPC Collector для CIMPLICITY OPC Server, выполните следующие действия:

1. Выберите «Выполнить» в меню «Пуск». Появится диалоговое окно «Выполнить».
2. Введите Regedit и нажмите Enter. Появится редактор реестра.
3. Найдите ключ ComputerName_OPC1_CollectorName , где ComputerName — это имя вашего компьютера, OPC1 — назначенное значение, а CollectorName — имя вашего сборщика CIMPLICITY.Вы можете найти этот ключ здесь:

     HKEY_LOCAL_MACHINE \ SOFTWARE \ Intellution, Inc. \ iHistorian \ Services \ OPCCollector \ ComputerName_OPC1_CollectorName  

4. Добавьте новое значение DWORD . Введите имя MachineUpTimeDelay , выберите десятичный параметр и задайте небольшое число, например 120. Введенное вами значение представляет количество секунд.
5. Закройте реестр Windows и перезагрузите компьютер.
6. Если OPC Collector по-прежнему не запускается, проверьте файл журнала в папке Logfiles на компьютере-сборщике.Если в журнале указаны те же сообщения, повторите шаги 1–5 еще раз, но на этот раз увеличьте значение MachineUpTimeDelay .

Глава 3. Настройка развертывания ведения журналов кластера OpenShift Container Platform 4.5

3.1. О настраиваемом ресурсе Cluster Logging

Чтобы настроить ведение журнала кластера OpenShift Container Platform, необходимо настроить настраиваемый ресурс (CR) ClusterLogging .

3.1.1. О настраиваемом ресурсе ClusterLogging

Чтобы внести изменения в среду ведения журнала кластера, создайте и измените настраиваемый ресурс (CR) ClusterLogging .

Инструкции по созданию или изменению CR приведены в этой документации по мере необходимости.

Ниже приведен пример типичного настраиваемого ресурса для ведения журнала кластера.

Пример ClusterLogging настраиваемый ресурс (CR)

 apiVersion: "logging.openshift.io/v1"
вид: "ClusterLogging"
метаданные:
  имя: "экземпляр" 1
  пространство имен: "openshift-logging" 2
спецификация:
  managementState: «Управляемый» 3
  logStore:
    тип: "elasticsearch" 4
    Политика удержания:
      заявление:
        maxAge: 1д.
      ниже:
        maxAge: 7 дней
      аудит:
        maxAge: 7 дней
    elasticsearch:
      nodeCount: 3
      Ресурсы:
        пределы:
          память: 16Gi
        Запросы:
          ЦП: 500 м
          память: 16Gi
      место хранения:
        storageClassName: "gp2"
        размер: «200 г»
      redundancyPolicy: «SingleRedundancy»
  визуализация: 5
    тип: "кибана"
    кибана:
      Ресурсы:
        пределы:
          память: 736Mi
        Запросы:
          ЦП: 100 м
          память: 736Mi
      реплик: 1
  курирование: 6
    тип: "куратор"
    куратор:
      Ресурсы:
        пределы:
          память: 256Mi
        Запросы:
          ЦП: 100 м
          память: 256Mi
      расписание: «30 3 * * *»
  коллекция: 7
    журналы:
      тип: "свободно"
      свободно:
        Ресурсы:
          пределы:
            память: 736Mi
          Запросы:
            ЦП: 100 м
            память: 736Mi 

1

Имя CR должно быть , экземпляр .

2

CR должен быть установлен в пространство имен openshift-logging .

3

Состояние управления Оператором ведения журнала кластера. Если установлено значение unmanaged , оператор находится в неподдерживаемом состоянии и не будет получать обновления.

4

Параметры хранилища журналов, включая политику хранения, количество узлов, запросы и ограничения ресурсов, а также класс хранилища.

5

Параметры визуализатора, включая запросы и ограничения ресурсов, а также количество реплик модуля.

6

Настройки курирования, включая запросы и ограничения ресурсов, а также расписание курирования.

7

Настройки сборщика журналов, включая запросы ресурсов и ограничения.

3.2. Настройка сборщика журналов

Платформа контейнеров OpenShift использует Fluentd для сбора журналов операций и приложений из вашего кластера и обогащает данные модулем Kubernetes и метаданными проекта.

Вы можете настроить ограничения ЦП и памяти для сборщика журналов и переместить модули сборщика журналов на определенные узлы. Все поддерживаемые модификации сборщика журналов могут быть выполнены через раздел spec.collection.log.fluentd в настраиваемом ресурсе (CR) ClusterLogging .

3.2.1. О неподдерживаемых конфигурациях

Поддерживаемый способ настройки ведения журнала кластера — его настройка с использованием параметров, описанных в этой документации.Не используйте другие конфигурации, так как они не поддерживаются. Парадигмы конфигурации могут меняться в разных выпусках OpenShift Container Platform, и такие случаи могут быть корректно обработаны только в том случае, если все возможности конфигурации контролируются. Если вы используете конфигурации, отличные от описанных в этой документации, ваши изменения исчезнут, поскольку оператор Elasticsearch и оператор ведения журнала кластера согласовывают любые различия. Операторы возвращают все в определенное состояние по умолчанию и по дизайну.

Если вы должны выполнять конфигурации, не описанные в документации OpenShift Container Platform, вы должны установить для своего оператора регистрации кластера или оператора Elasticsearch значение Unmanaged . Среда ведения журнала неуправляемого кластера не поддерживается и не получает обновления, пока вы не вернете ведение журнала кластера на Управляемый .

3.2.2. Просмотр модулей сборщика журналов

Вы можете использовать команду oc get pods --all-namespaces -o wide , чтобы увидеть узлы, на которых развернут Fluentd.

Процедура

Выполните следующую команду в проекте openshift-logging :

 $ oc get pods --selector component = fluentd -o wide -n openshift-logging 

Пример вывода

 NAME READY STATUS ВОЗВРАЩАЕТСЯ В СТАТУС AGE IP NODE NOMINATED NODE READINESS GATES
fluentd-8d69v 1/1 Бег 0 134 м 10.130.2.30 master1.example.com <нет> <нет>
fluentd-bd225 1/1 Бег 0 134 м 10.131.1.11 master2.example.com <нет> <нет>
fluentd-cvrzs 1/1 Бег 0 134 мин 10.130.0.21 master3.example.com <нет> <нет>
fluentd-gpqg2 1/1 Бег 0 134 мин 10.128.2.27 worker1.example.com <нет> <нет>
fluentd-l9j7j 1/1 Бег 0 134 м 10.129.2.31 worker2.example.com <нет> <нет> 

3.2.3. Настройка ограничений ЦП и памяти сборщика журналов

Сборщик журналов позволяет настраивать ограничения как для ЦП, так и для памяти.

Процедура

1. Отредактируйте пользовательский ресурс (CR) ClusterLogging в проекте openshift-logging :

    $ oc изменить экземпляр ClusterLogging 

    $ oc изменить экземпляр ClusterLogging
   
   apiVersion: "logging.openshift.io/v1"
   вид: "ClusterLogging"
   метаданные:
     имя: "экземпляр"
   
   ....
   
   спецификация:
     коллекция:
       журналы:
         свободно:
           Ресурсы:
             пределы: 1
               память: 736Mi
             Запросы:
               ЦП: 100 м
               память: 736Mi 

   1

   При необходимости укажите ограничения и запросы ЦП и памяти.Показанные значения являются значениями по умолчанию.

3.2.4. О предупреждениях сборщика журналов

Следующие предупреждения генерируются сборщиком журналов. Вы можете просмотреть эти предупреждения в веб-консоли OpenShift Container Platform на странице Alerts пользовательского интерфейса предупреждений.

Таблица 3.1. Оповещения Fluentd Prometheus

Оповещение	Сообщение	Описание	Уровень серьезности
FluentdErrorsHigh	За последнюю минуту fluentd сообщил об ошибках .	Fluentd сообщает о большем количестве проблем, чем указано, по умолчанию 10.	Критический
FluentdNodeDown	Прометей не смог очистить fluentd более чем на 10 метров.	Fluentd сообщает, что Prometheus не удалось очистить конкретный экземпляр Fluentd.	Критический
FluentdQueueLengthBurst	За последнюю минуту длина буферной очереди fluentd увеличилась более чем на 32. Текущее значение - .	Fluentd сообщает, что он перегружен.	Предупреждение
FluentdQueueLengthIncreasing	За последние 12 часов длина буферной очереди fluentd постоянно увеличивалась более чем на 1.Текущее значение: <значение>.	Fluentd сообщает о проблемах с использованием очереди.	Критический

3.2.5. Удаление неиспользуемых компонентов, если вы не используете хранилище журналов Elasticsearch по умолчанию

Как администратор, в том редком случае, когда вы пересылаете журналы в стороннее хранилище журналов и не используете хранилище журналов Elasticsearch по умолчанию, вы можете удалить несколько неиспользуемых компонентов из кластера журналов.

Другими словами, если вы не используете хранилище журналов Elasticsearch по умолчанию, вы можете удалить внутренние компоненты Elasticsearch logStore , Kibana visualization и log curation из настраиваемого ресурса ClusterLogging (CR). Удаление этих компонентов не является обязательным, но экономит ресурсы.

Предположим, что ClusterLogForwarder CR пересылает данные журнала во внутренний кластер Elasticsearch, и вы удаляете компонент logStore из ClusterLogging CR.В этом случае внутренний кластер Elasticsearch не будет присутствовать для хранения данных журнала. Это отсутствие может привести к потере данных.

Процедура

1. Отредактируйте пользовательский ресурс (CR) ClusterLogging в проекте openshift-logging :

    $ oc изменить экземпляр ClusterLogging 

2. Если они присутствуют, удалите logStore , визуализацию , curation строф из ClusterLogging CR.

3. Сохранить коллекцию строфа ClusterLogging CR. Результат должен выглядеть примерно так:

    apiVersion: "logging.openshift.io/v1"
   вид: "ClusterLogging"
   метаданные:
     имя: "экземпляр"
     пространство имен: "openshift-logging"
   спецификация:
     managementState: «Управляемый»
     коллекция:
       журналы:
         тип: "свободно"
         свободно: {} 

4. Убедитесь, что модули Fluentd развернуты повторно:

    $ oc get pods -n openshift-logging 

3.3. Настройка хранилища журналов

Платформа контейнеров OpenShift использует Elasticsearch 6 (ES) для хранения и организации данных журнала.

Вы можете вносить изменения в свое хранилище журналов, в том числе:

• хранилище для вашего кластера Elasticsearch
• репликация сегментов между узлами данных в кластере, от полной репликации до отсутствия репликации
• внешний доступ к данным Elasticsearch

Elasticsearch — это приложение, интенсивно использующее память.Каждому узлу Elasticsearch требуется 16 ГБ памяти как для запросов памяти, так и для ограничений, если вы не укажете иное в настраиваемом ресурсе ClusterLogging . Первоначальный набор узлов OpenShift Container Platform может быть недостаточно большим для поддержки кластера Elasticsearch. Вы должны добавить дополнительные узлы в кластер OpenShift Container Platform для работы с рекомендованной или большей памятью.

Каждый узел Elasticsearch может работать с меньшим объемом памяти, хотя это не рекомендуется для производственных сред.

3.3.1. Перенаправить журналы аудита в хранилище журналов

Поскольку внутреннее хранилище журналов Elasticsearch платформы контейнеров OpenShift не обеспечивает безопасное хранилище для журналов аудита, по умолчанию журналы аудита не хранятся во внутреннем экземпляре Elasticsearch.

Если вы хотите отправить журналы аудита во внутреннее хранилище журналов, например, для просмотра журналов аудита в Kibana, вы должны использовать API пересылки журналов. Log Fowarding API в настоящее время является функцией предварительного просмотра технологий.

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

Процедура

Чтобы использовать API пересылки журналов для пересылки журналов аудита во внутренний экземпляр Elasticsearch:

1. Если API пересылки журналов не включен:

   1. Отредактируйте пользовательский ресурс (CR) ClusterLogging в проекте openshift-logging :

       $ oc изменить экземпляр ClusterLogging 

   2. Добавьте кластерный журнал .openshift.io/logforwardingtechpreview и установлено значение включено :

       apiVersion: "logging.openshift.io/v1"
      вид: "ClusterLogging"
      метаданные:
        аннотации:
          clusterlogging.openshift.io/logforwardingtechpreview: включено 1
        имя: "экземпляр"
        пространство имен: "openshift-logging"
      спецификация:
      
      ...
      
        коллекция: 2
          журналы:
            тип: "свободно"
            свободно: {} 

      1

      Включает и отключает API пересылки журналов. Значение позволяет использовать пересылку журналов.

      2

      Блок spec.collection должен быть определен для использования Fluentd в ClusterLogging CR.

2. Создайте YAML-файл LogForwarding CR или отредактируйте существующий CR:

   • Создайте CR для отправки всех типов журналов во внутренний экземпляр Elasticsearch. Вы можете использовать следующий пример без каких-либо изменений:

      apiVersion: логирование.openshift.io/v1alpha1
     вид: LogForwarding
     метаданные:
       имя: экземпляр
       пространство имен: openshift-logging
     спецификация:
       disableDefaultForwarding: true
       выходы:
         - имя: clo-es
           тип: elasticsearch
           конечная точка: 'elasticsearch.openshift-logging.svc: 9200' 1
           секрет:
             имя: fluentd
       трубопроводы:
         - наименование: audit-pipeline 2
           inputSource: logs.audit
           outputRefs:
             - одежда
         - имя: app-pipeline 3
           inputSource: logs.app
           outputRefs:
             - одежда
         - наименование: инфра-трубопровод 4
           inputSource: журналы.инфра
           outputRefs:
             - одежда 

     1

     Конечная точка Параметр указывает на внутренний экземпляр Elasticsearch.

     2

     Этот параметр отправляет журналы аудита в указанную конечную точку.

     3

     Этот параметр отправляет журналы приложения в указанную конечную точку.

     4

     Этот параметр отправляет журналы инфраструктуры в указанную конечную точку.

     Вы должны настроить конвейер и вывод для всех трех типов журналов: приложений, инфраструктуры и аудита. Если вы не укажете конвейер и вывод для типа журнала, эти журналы не сохраняются и будут потеряны.

   • Если у вас есть существующий LogForwarding CR, добавьте вывод для внутреннего экземпляра Elasticsearch и конвейер к этому выводу для журналов аудита. Например:

      apiVersion: "logging.openshift.io/v1alpha1 "
     вид: "ЛогПересылка"
     метаданные:
       имя: экземпляр
       пространство имен: openshift-logging
     спецификация:
       disableDefaultForwarding: true
       выходы:
        - имя: elasticsearch 1
          тип: "elasticsearch"
          конечная точка: elasticsearch.openshift-logging.svc: 9200
          секрет:
             имя: fluentd
        - имя: elasticsearch-insecure
          тип: "elasticsearch"
          конечная точка: elasticsearch-insecure.messaging.svc.cluster.local
          небезопасно: правда
        - имя: secureforward-offcluster
          тип: "вперед"
          конечная точка: https: // secureforward.offcluster.com:24224
          секрет:
             имя: secureforward
       трубопроводы:
        - имя: контейнер-журналы
          inputSource: logs.app
          outputRefs:
          - secureforward-offcluster
        - название: инфра-логи
          inputSource: logs.infra
          outputRefs:
          - elasticsearch-небезопасный
        - имя: audit-logs 2
          inputSource: logs.audit
          outputRefs:
          - elasticsearch 

     1

     Выход для внутреннего экземпляра Elasticsearch.

     2

     Конвейер для отправки журналов аудита внутреннему экземпляру Elasticsearch.

3.3.2. Настройка времени хранения журнала

Вы можете указать, как долго хранилище журналов Elasticsearch по умолчанию хранит индексы, используя отдельную политику хранения для каждого из трех источников журналов: журналы инфраструктуры, журналы приложений и журналы аудита. Политика хранения, которую вы настраиваете с помощью параметра maxAge в настраиваемом ресурсе ведения журнала кластера (CR), учитывается в расписании пролонгации Elasticsearch и определяет, когда Elasticsearch удаляет пролонгированные индексы.

Elasticsearch выполняет пролистывание индекса, перемещая текущий индекс и создавая новый индекс, когда индекс соответствует любому из следующих условий:

• Индекс старше значения rollover.maxAge в Elasticsearch CR.
• Размер индекса превышает 40 ГБ × количество первичных сегментов.
• Количество документов индекса превышает 40960 КБ × количество первичных сегментов.

Elasticsearch удаляет пролонгированные индексы, удаляются на основе настроенной вами политики хранения.

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

Если вы не укажете политику хранения для всех трех источников журналов, будут сохранены только журналы из источников с политикой хранения. Например, если вы установили политику хранения для журналов инфраструктуры и приложений, но не задали политику хранения для журналов аудита, журналы аудита не будут сохранены, и в Elasticsearch или Kibana не будет индекса audit- .

Предварительные требования

• Необходимо установить ведение журнала кластера и Elasticsearch.

Процедура

Чтобы настроить время хранения журнала:

1. Отредактируйте ClusterLogging CR, чтобы добавить или изменить параметр retentionPolicy :

    apiVersion: "logging.openshift.io/v1"
   вид: "ClusterLogging"
   ...
   спецификация:
     managementState: «Управляемый»
     logStore:
       тип: "elasticsearch"
       retentionPolicy: 1
         заявление:
           maxAge: 1д.
         ниже:
           maxAge: 7 дней
         аудит:
           maxAge: 7 дней
       elasticsearch:
         nodeCount: 3
   ... 

   1

   Укажите время, в течение которого Elasticsearch должен сохранять каждый источник журнала. Введите целое число и обозначение времени: недели (w), часы (h / H), минуты (m) и секунды (s). Например, 1d за один день. Журналы старше maxAge удаляются. По умолчанию журналы хранятся в течение семи дней.

2. Вы можете проверить настройки в настраиваемом ресурсе Elasticsearch (CR).

   Например, оператор ведения журнала кластера обновил следующий Elasticsearch CR, чтобы настроить политику хранения, которая включает параметры для пролонгации активных индексов для журналов инфраструктуры каждые восемь часов, а свернутые индексы удаляются через семь дней после пролонгации.Платформа контейнеров OpenShift проверяет каждые 15 минут, чтобы определить, нужно ли переносить индексы.

    apiVersion: "logging.openshift.io/v1"
   вид: "Elasticsearch"
   метаданные:
     имя: "elasticsearch"
   спецификация:
   ...
     indexManagement:
       политики: 1
         - наименование: инфра-политика
           фазы:
             удалять:
               minAge: 7д 2
             горячий:
               действия:
                 перекатывать:
                   maxAge: 8ч 3
           Интервал опроса: 15м 4
   ... 

   1

   Для каждого источника журналов политика хранения указывает, когда следует удалять и пролонгировать журналы для этого источника.

   2

   Когда OpenShift Container Platform удаляет перенесенные индексы. Это значение maxAge , которое вы задали в ClusterLogging CR.

   3

   Возраст индекса для OpenShift Container Platform, который следует учитывать при переносе индексов. Это значение определяется из maxAge , установленного вами в ClusterLogging CR.

   4

   Когда OpenShift Container Platform проверяет, нужно ли переносить индексы.Этот параметр установлен по умолчанию и не может быть изменен.

   Изменение Elasticsearch CR не поддерживается. Все изменения политик хранения необходимо вносить в ClusterLogging CR.

   Оператор Elasticsearch развертывает задание cron для переноса индексов для каждого сопоставления с использованием определенной политики, запланированной с использованием pollInterval .

    $ oc get cronjobs 

   Пример вывода

    NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE
   elasticsearch-delete-app * / 15 * * * * Ложь 0 <нет> 27 с
   elasticsearch-delete-audit * / 15 * * * * Ложь 0 <нет> 27 с
   elasticsearch-delete-infra * / 15 * * * * Ложь 0 <нет> 27 с
   elasticsearch-rollover-app * / 15 * * * * Ложь 0 <нет> 27 с
   elasticsearch-rollover-audit * / 15 * * * * Ложь 0 <нет> 27 с
   elasticsearch-rollover-infra * / 15 * * * * Ложь 0 <нет> 27s 

3.3.3. Настройка запросов ЦП и памяти для хранилища журналов

Спецификация каждого компонента допускает корректировку запросов как процессора, так и памяти. Вам не придется вручную настраивать эти значения, поскольку оператор Elasticsearch устанавливает значения, достаточные для вашей среды.

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

Каждый узел Elasticsearch может работать с меньшим объемом памяти, хотя это , а не , рекомендованное для производственных развертываний. Для производственного использования у вас должно быть не менее 16 Ги по умолчанию, выделенных для каждого модуля. Желательно выделить как можно больше, до 64 Ги на под.

Предварительные требования

• Необходимо установить ведение журнала кластера и Elasticsearch.

Процедура

1. Отредактируйте пользовательский ресурс (CR) ClusterLogging в проекте openshift-logging :

    $ oc редактировать экземпляр ClusterLogging 

    apiVersion: "logging.openshift.io/v1 "
   вид: "ClusterLogging"
   метаданные:
     имя: "экземпляр"
   ....
   спецификация:
       logStore:
         тип: "elasticsearch"
         elasticsearch:
           ресурсы: 1
             пределы:
               память: 16Gi
             Запросы:
               cpu: "1"
               память: "64Gi"
           прокси: 2
             Ресурсы:
               пределы:
                 память: 100 Ми
               Запросы:
                 память: 100Mi 

   1

   При необходимости укажите запросы ЦП и памяти для Elasticsearch.Если вы оставите эти значения пустыми, оператор Elasticsearch установит значения по умолчанию, которых должно хватить для большинства развертываний. Значения по умолчанию: 16Gi для запроса памяти и 1 для запроса ЦП.

   2

   При необходимости укажите запросы ЦП и памяти для прокси-сервера Elasticsearch. Если вы оставите эти значения пустыми, оператор Elasticsearch установит значения по умолчанию, которых должно хватить для большинства развертываний. Значения по умолчанию: 256Mi для запроса памяти и 100m для запроса CPU.

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

Например:

 ресурсов:
        пределы:
          cpu: "8"
          память: «32Gi»
        Запросы:
          cpu: "8"
          память: "32Gi" 

Kubernetes обычно придерживается конфигурации узла и не позволяет Elasticsearch использовать указанные ограничения. Установка одного и того же значения для и запросов гарантирует, что Elasticsearch может использовать требуемые ЦП и память, при условии, что на узле есть ЦП и доступная память.

3.3.4. Настройка политики репликации для хранилища журналов

Вы можете определить, как сегменты Elasticsearch реплицируются между узлами данных в кластере.

Предварительные требования

• Необходимо установить ведение журнала кластера и Elasticsearch.

Процедура

1. Отредактируйте пользовательский ресурс (CR) ClusterLogging в проекте openshift-logging :

    $ oc редактировать экземпляр кластерного журнала 

    apiVersion: "logging.openshift.io/v1 "
   вид: "ClusterLogging"
   метаданные:
     имя: "экземпляр"
   
   ....
   
   спецификация:
     logStore:
       тип: "elasticsearch"
       elasticsearch:
         redundancyPolicy: «SingleRedundancy» 1 

   1

   Укажите политику избыточности для шардов. Изменение применяется после сохранения изменений.

   • Полный резерв . Elasticsearch полностью реплицирует первичные сегменты для каждого индекса на каждый узел данных. Это обеспечивает высочайшую безопасность, но за счет наибольшего необходимого объема диска и самой низкой производительности.
   • Множественный резерв . Elasticsearch полностью реплицирует первичные сегменты для каждого индекса на половину узлов данных. Это обеспечивает хороший компромисс между безопасностью и производительностью.
   • Одинарный резерв . Elasticsearch создает по одной копии первичных сегментов для каждого индекса. Журналы всегда доступны и могут быть восстановлены, если существует как минимум два узла данных. Лучшая производительность, чем MultipleRedundancy, при использовании 5 или более узлов.Вы не можете применить эту политику к развертыванию одного узла Elasticsearch.
   • ZeroRedundancy . Elasticsearch не делает копии основных шардов. Журналы могут быть недоступны или утеряны в случае отказа узла. Используйте этот режим, если вас больше заботит производительность, чем безопасность, или если вы реализовали собственную стратегию резервного копирования / восстановления диска / PVC.

Количество первичных сегментов для шаблонов индекса равно количеству узлов данных Elasticsearch.

3.3.5. Уменьшение масштаба модулей Elasticsearch

Уменьшение количества модулей Elasticsearch в кластере может привести к потере данных или снижению производительности Elasticsearch.

Если вы уменьшаете масштаб, вы должны уменьшать масштаб по одному модулю за раз и позволять кластеру повторно сбалансировать сегменты и реплики. После того, как статус работоспособности Elasticsearch вернется к , зеленый , вы можете уменьшить масштаб на другой модуль.

Если для кластера Elasticsearch установлено значение ZeroRedundancy , вам не следует уменьшать размер модулей Elasticsearch.

3.3.6. Настройка постоянного хранилища для хранилища журналов

Elasticsearch требует постоянного хранилища. Чем быстрее хранилище, тем выше производительность Elasticsearch.

Использование хранилища NFS в качестве тома или постоянного тома (или через NAS, например Gluster) не поддерживается для хранилища Elasticsearch, поскольку Lucene полагается на поведение файловой системы, которое NFS не предоставляет. Могут возникнуть повреждение данных и другие проблемы.

Предварительные требования

• Необходимо установить ведение журнала кластера и Elasticsearch.

Процедура

1. Измените ClusterLogging CR, чтобы указать, что каждый узел данных в кластере привязан к утверждению постоянного тома.

    apiVersion: "logging.openshift.io/v1"
   вид: "ClusterLogging"
   метаданные:
     имя: "экземпляр"
   
   ....
   
    спецификация:
       logStore:
         тип: "elasticsearch"
         elasticsearch:
           nodeCount: 3
           место хранения:
             storageClassName: "gp2"
             размер: «200G» 

В этом примере указывается, что каждый узел данных в кластере привязан к утверждению постоянного тома, которое запрашивает «200 ГБ» хранилища AWS General Purpose SSD (gp2).

Если вы используете локальный том для постоянного хранения, не используйте необработанный блочный том, который описан с помощью volumeMode: block в объекте LocalVolume . Elasticsearch не может использовать необработанные блочные тома.

3.3.7. Настройка хранилища журналов для emptyDir storage

Вы можете использовать emptyDir со своим хранилищем журналов, что создает временное развертывание, при котором все данные модуля теряются при перезапуске.

При использовании emptyDir, если хранилище журналов перезапущено или повторно развернуто, вы потеряете данные.

Предварительные требования

• Необходимо установить ведение журнала кластера и Elasticsearch.

Процедура

1. Отредактируйте ClusterLogging CR, указав emptyDir:

    спецификация:
       logStore:
         тип: "elasticsearch"
         elasticsearch:
           nodeCount: 3
           склад: {} 

3.3.8. Выполнение перезапуска скользящего кластера Elasticsearch

Выполните непрерывный перезапуск при изменении карты конфигурации elasticsearch или любой из конфигураций развертывания elasticsearch- * .

Кроме того, рекомендуется непрерывный перезапуск, если узлы, на которых работает модуль Elasticsearch, требуют перезагрузки.

Предварительные требования

• Необходимо установить ведение журнала кластера и Elasticsearch.
• Установите инструмент OpenShift Container Platform es_util

Процедура

Чтобы выполнить скользящий перезапуск кластера:

1. Перейдите к проекту openshift-logging :

    $ oc проект openshift-logging 

2. Получите имена модулей Elasticsearch:

    $ ок получить стручки | grep elasticsearch- 

3. Выполните синхронизированную очистку сегментов с помощью инструмента OpenShift Container Platform es_util , чтобы убедиться, что нет незавершенных операций, ожидающих записи на диск перед завершением работы:

    $ oc exec  -c elasticsearch - es_util --query = "_ flush / synced" -XPOST 

   Например:

    $ oc exec -c elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch - es_util --query = "_ flush / synced" -XPOST 

   Пример вывода

    {"_shards": всего ": 4," успешно ": 4," не удалось ": 0},".security ": {" total ": 2," success ": 2," failed ": 0},". kibana_1 ": {" total ": 2," success ": 2," failed ": 0}} 

4. Предотвратить балансировку сегментов при намеренном отключении узлов с помощью инструмента es_util платформы OpenShift Container Platform:

    $ oc exec  -c elasticsearch - es_util --query = "_ cluster / settings" -XPUT -d '{"persistent": {"cluster.routing.allocation.enable": "primaries"}}' 

   Например:

    $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch - es_util --query = "_ cluster / settings" -XPUT -d '{"persistent": {"cluster.routing.allocation.enable ":" primaries "}} '

   Пример вывода

    {" подтверждено ": true," persistent ": {" cluster ": {" routing ": {" allocation ": {" enable ":" primaries "}}}}," transient ": 

5. После выполнения команды для каждого развертывания ES-кластера:

   1. По умолчанию кластер Elasticsearch платформы контейнеров OpenShift блокирует развертывание на своих узлах. Используйте следующую команду, чтобы разрешить развертывание и позволить модулю принимать изменения:

       $ oc rollout возобновить развертывание / <имя-развертывания> 

      Например:

       $ oc rollout возобновить развертывание / elasticsearch-cdm-0-1 

      Пример вывода

       развертывание.extension / elasticsearch-cdm-0-1 возобновлено 

      Развернут новый модуль. После того, как у модуля будет готовый контейнер, можно переходить к следующему развертыванию.

       $ ок получить стручки | grep elasticsearch- 

      Пример вывода

       НАЗВАНИЕ ГОТОВ СОСТОЯНИЕ ВОССТАНОВЛЕНИЕ ВОЗРАСТА
      elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6k 2/2 Выполняется 0 22 ч.
      elasticsearch-cdm-5ceex6ts-2-f799564cb-l9mj7 2/2 Выполняется 0 22 ч.
      elasticsearch-cdm-5ceex6ts-3-585968dc68-k7kjr 2/2 Running 0 22h 

   2. После завершения развертывания сбросьте модуль, чтобы запретить развертывание:

       $ oc rollout pause deployment / <имя-развертывания> 

      Например:

       $ oc rollout pause deployment / elasticsearch-cdm-0-1 

      Пример вывода

       развертывание.extension / elasticsearch-cdm-0-1 приостановлено 

   3. Убедитесь, что кластер Elasticsearch находится в состоянии зеленый или желтый :

       $ oc exec  -c elasticsearch - es_util --query = _cluster / health? Pretty = true 

      Если вы выполнили развертывание модуля Elasticsearch, который использовали в предыдущих командах, модуль больше не существует, и здесь вам потребуется новое имя модуля.

      Например:

       $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch - es_util --query = _cluster / health? Pretty = true 

       {
        "имя_кластера": "elasticsearch",
        "status": "желтый", 1
        "timed_out": ложь,
        «количество_узлов»: 3,
        "number_of_data_nodes": 3,
        "active_primary_shards": 8,
        «active_shards»: 16,
        "relocating_shards": 0,
        "initializing_shards": 0,
        "unassigned_shards": 1,
        "delayed_unassigned_shards": 0,
        «количество_время_задач»: 0,
        "number_of_in_flight_fetch": 0,
        "task_max_waiting_in_queue_millis": 0,
        «active_shards_percent_as_number»: 100.0
      } 

      1

      Прежде чем продолжить, убедитесь, что значение этого параметра — зеленый или желтый .

6. Если вы изменили карту конфигурации Elasticsearch, повторите эти шаги для каждого модуля Elasticsearch.

7. После того, как все развертывания для кластера будут развернуты, повторно включите балансировку сегментов:

    $ oc exec  -c elasticsearch - es_util --query = "_ cluster / settings" -XPUT -d '{"persistent": {"cluster.routing.allocation.enable ":" all "}} '

   Например:

    $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch - es_util --query = "_ cluster / settings" -XPUT -d '{"persistent": {"cluster.routing.allocation.enable ":" all "}} '

   Пример вывода

    {
     "подтверждено": правда,
     "настойчивый" : { },
     "transient": {
       "cluster": {
         "routing": {
           "allocation": {
             "включить все"
           }
         }
       }
     }
   } 

3.3.9. Предоставление службы хранилища журналов как маршрута

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

Вы можете получить доступ к хранилищу журналов извне, создав маршрут повторного шифрования, свой токен OpenShift Container Platform и установленный сертификат CA хранилища журналов.Затем обратитесь к узлу, на котором размещена служба хранилища журналов, с помощью запроса cURL, который содержит:

Внутри вы можете получить доступ к службе хранилища журналов, используя IP-адрес кластера хранилища журналов, который можно получить с помощью любой из следующих команд:

 $ oc get service elasticsearch -o jsonpath = {. Spec.clusterIP} -n openshift-logging 

Пример вывода

 172.30.183.229 

 $ oc get service elasticsearch -n openshift-logging 

Пример вывода

 ИМЯ ТИП КЛАСТЕР-IP ВНЕШНИЙ IP-ПОРТ (-И) ВОЗРАСТ
Кластер эластичного поиска IP 172.30.183.229 <нет> 9200 / TCP 22h 

Вы можете проверить IP-адрес кластера с помощью команды, подобной следующей:

 $ oc exec elasticsearch-cdm-oplnhinv-1-5746475887-fj2f8 -n openshift-logging - curl -tlsv1.2 --insecure -H "Авторизация: предъявитель $ {token}" "https://172.30.183.229 : 9200 / _cat / health "

Пример вывода

% Всего% Получено% Xferd Средняя скорость Время Время Время Время Ток
                                 Выгрузка Всего израсходовано Оставшаяся скорость
100 29 100 29 0 0 108 0 -: -: - -: -: - -: -: - 108 

Предварительные требования

• Необходимо установить ведение журнала кластера и Elasticsearch.
• У вас должен быть доступ к проекту, чтобы иметь доступ к журналам.

Процедура

Чтобы открыть доступ к хранилищу журналов извне:

1. Перейдите к проекту openshift-logging :

    $ oc проект openshift-logging 

2. Извлеките сертификат CA из хранилища журналов и запишите в файл admin-ca :

    $ oc extract secret / elasticsearch --to =.--keys = admin-ca 

3. Создайте маршрут для службы хранилища журналов в виде файла YAML:

   1. Создайте файл YAML со следующим:

       apiVersion: route.openshift.io/v1
      вид: Маршрут
      метаданные:
        имя: elasticsearch
        пространство имен: openshift-logging
      спецификация:
        хозяин:
        к:
          вид: Сервис
          имя: elasticsearch
        tls:
          прекращение: повторно зашифровать
          destinationCACertificate: | 1 

      1

      Добавьте сертификат CA хранилища журналов или используйте команду на следующем шаге./ / «>> <имя-файла> .yaml

   2. Создайте маршрут:

       $ oc create -f <имя-файла> .yaml 

      Пример вывода

       route.route.openshift.io/elasticsearch создан 

4. Убедитесь, что сервис Elasticsearch открыт:

   1. Получите токен этой служебной учетной записи, который будет использоваться в запросе:

       $ токен = $ (oc whoami -t) 

   2. Задайте созданный вами маршрут elasticsearch в качестве переменной среды.

       $ routeES = `oc get route elasticsearch -o jsonpath = {. Spec.host}` 

   3. Чтобы убедиться, что маршрут был успешно создан, выполните следующую команду, которая обращается к Elasticsearch через открытый маршрут:

       curl -tlsv1.2 --insecure -H "Авторизация: предъявитель $ {token}" "https: // $ {routeES}" 

      Ответ выглядит примерно так:

      Пример вывода

       {
        "имя": "elasticsearch-cdm-i40ktba0-1",
        "имя_кластера": "elasticsearch",
        "cluster_uuid": "0eY-tJzcR3KOdpgeMJo-MQ",
        "версия": {
        «число»: «6.8,1 ",
        "build_flavor": "oss",
        "build_type": "zip",
        "build_hash": "Неизвестно",
        "build_date": "Неизвестно",
        "build_snapshot": правда,
        "lucene_version": "7.7.0",
        "minimum_wire_compatibility_version": "5.6.0",
        "minimum_index_compatibility_version": "5.0.0"
      },
        "<тег>": "<для поиска>"
      } 

3.4. Настройка визуализатора журнала

Платформа контейнеров OpenShift использует Kibana для отображения данных журнала, собранных при ведении журнала кластера.

Вы можете масштабировать Kibana для обеспечения избыточности и настраивать ЦП и память для узлов Kibana.

3.4.1. Настройка ограничений ЦП и памяти

Компоненты ведения журнала кластера позволяют настраивать ограничения как для ЦП, так и для памяти.

Процедура

1. Отредактируйте пользовательский ресурс (CR) ClusterLogging в проекте openshift-logging :

    $ oc редактировать экземпляр ClusterLogging -n openshift-logging 

    apiVersion: "logging.openshift.io/v1 "
   вид: "ClusterLogging"
   метаданные:
     имя: "экземпляр"
   
   ....
   
   спецификация:
     managementState: «Управляемый»
     logStore:
       тип: "elasticsearch"
       elasticsearch:
         nodeCount: 2
         ресурсы: 1
           пределы:
             память: 2Gi
           Запросы:
             ЦП: 200 м
             память: 2Gi
         место хранения:
           storageClassName: "gp2"
           размер: «200 г»
         redundancyPolicy: «SingleRedundancy»
     визуализация:
       тип: "кибана"
       кибана:
         ресурсы: 2
           пределы:
             память: 1 Ги
           Запросы:
             ЦП: 500 м
             память: 1 Ги
         прокси:
           ресурсы: 3
             пределы:
               память: 100 Ми
             Запросы:
               ЦП: 100 м
               память: 100 Ми
         реплик: 2
     курирование:
       тип: "куратор"
       куратор:
         ресурсы: 4
           пределы:
             память: 200 Ми
           Запросы:
             ЦП: 200 м
             память: 200 Ми
         расписание: "* / 10 * * * *"
     коллекция:
       журналы:
         тип: "свободно"
         свободно:
           ресурсы: 5
             пределы:
               память: 736Mi
             Запросы:
               ЦП: 200 м
               память: 736Mi 

   1

   При необходимости укажите ограничения ЦП и памяти и запросы к хранилищу журналов.Для Elasticsearch необходимо настроить как значение запроса, так и предельное значение.

   2 3

   При необходимости укажите ограничения ЦП и памяти и запросы для визуализатора журналов.

   4

   При необходимости укажите ограничения ЦП и памяти и запросы для куратора журнала.

   5

   При необходимости укажите ограничения ЦП и памяти и запросы для сборщика журналов.

3.4.2. Масштабирование избыточности для узлов визуализатора журнала

Вы можете масштабировать модуль, в котором размещается визуализатор журнала, для обеспечения избыточности.

Процедура

1. Отредактируйте пользовательский ресурс (CR) ClusterLogging в проекте openshift-logging :

    $ oc изменить экземпляр ClusterLogging 

    $ oc изменить экземпляр ClusterLogging
   
   apiVersion: "logging.openshift.io/v1 "
   вид: "ClusterLogging"
   метаданные:
     имя: "экземпляр"
   
   ....
   
   спецификация:
       визуализация:
         тип: "кибана"
         кибана:
           реплик: 1 1 

   1

   Укажите количество узлов Kibana.

3.4.3. Использование допусков для управления размещением модуля визуализатора журнала

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

Вы применяете допуски к модулю визуализатора журнала через настраиваемый ресурс (CR) ClusterLogging и применяете taints к узлу через спецификацию узла. Заражение на узле — это пара ключ: значение , которая инструктирует узел отразить все поды, которые не переносят заражение. Использование определенной пары ключ: значение , которой нет в других модулях, гарантирует, что на этом узле может работать только модуль Kibana.

Предварительные требования

• Необходимо установить ведение журнала кластера и Elasticsearch.

Процедура

1. Используйте следующую команду, чтобы добавить заражение к узлу, на котором вы хотите запланировать модуль визуализатора журнала:

    Узлы администрирования $ oc <имя-узла> <ключ> = <значение>: <эффект> 

   Например:

    $ oc adm taint nodes node1 kibana = node: NoExecute 

   Этот пример помещает заражение на node1 , который имеет ключ kibana , значение node и эффект заражения NoExecute .Вы должны использовать эффект заражения NoExecute . NoExecute планирует только модули, соответствующие заражению, и удаляет существующие модули, которые не совпадают.

2. Отредактируйте раздел визуализации в ClusterLogging CR, чтобы настроить допуск для модуля Kibana:

    визуализация:
       тип: "кибана"
       кибана:
         терпимости:
         - клавиша: «кибана» 1
           оператор: "Существует" 2
           эффект: "NoExecute" 3
           терпение Секунды: 6000 4 

   1

   Укажите ключ, который вы добавили к узлу.

   2

   Задайте оператор Exists , чтобы запросить ключ , значение /, /, эффект , чтобы соответствовать параметрам.

   3

   Задайте эффект NoExecute .

   4

   При желании можно указать параметр терпимости , чтобы установить, как долго модуль может оставаться привязанным к узлу перед тем, как его выселят.

Этот допуск соответствует заражению, создаваемому командой oc adm taint . Под с этим допуском сможет планировать на node1 .

3.5. Настройка хранилища журналов кластера

Elasticsearch - это приложение, интенсивно использующее память. При установке ведения журнала кластера по умолчанию развертывается 16 ГБ памяти как для запросов памяти, так и для ограничений памяти. Первоначальный набор узлов OpenShift Container Platform может быть недостаточно большим для поддержки кластера Elasticsearch.Вы должны добавить дополнительные узлы в кластер OpenShift Container Platform для работы с рекомендованной или большей памятью. Каждый узел Elasticsearch может работать с меньшим объемом памяти, хотя это не рекомендуется для производственных сред.

3.5.1. Рекомендации по хранению для ведения журналов кластера и OpenShift Container Platform

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

Оператор Elasticsearch называет PVC, используя имя ресурса Elasticsearch. Дополнительные сведения см. В Постоянном хранилище Elasticsearch.

Если вы используете локальный том для постоянного хранения, не используйте необработанный блочный том, который описан с помощью volumeMode: block в объекте LocalVolume . Elasticsearch не может использовать необработанные блочные тома.

Fluentd отправляет любые журналы из systemd journal и / var / log / container / в Elasticsearch.

Поэтому заранее подумайте, сколько данных вам нужно и что вы собираете данные журнала приложений. Некоторые пользователи Elasticsearch обнаружили, что необходимо постоянно поддерживать абсолютное потребление хранилища на уровне около 50% и ниже 70%. Это помогает избежать зависания Elasticsearch во время крупных операций слияния.

По умолчанию при 85% Elasticsearch перестает выделять новые данные узлу, при 90% Elasticsearch пытается переместить существующие сегменты с этого узла на другие узлы, если это возможно.Но если ни один из узлов не имеет свободной емкости ниже 85%, Elasticsearch фактически отклоняет создание новых индексов и становится КРАСНЫМ.

Эти низкие и высокие значения водяного знака являются значениями по умолчанию для Elasticsearch в текущем выпуске. Вы можете изменить эти значения, но вы также должны применить любые изменения к предупреждениям. Предупреждения основаны на этих значениях по умолчанию.

3.5.2. Дополнительные ресурсы

3.6. Настройка ограничений ЦП и памяти для компонентов ведения журнала кластера

Вы можете настроить ограничения как ЦП, так и памяти для каждого из компонентов ведения журнала кластера по мере необходимости.

3.6.1. Настройка ограничений ЦП и памяти

Компоненты ведения журнала кластера позволяют настраивать ограничения как для ЦП, так и для памяти.

Процедура

1. Отредактируйте пользовательский ресурс (CR) ClusterLogging в проекте openshift-logging :

    $ oc редактировать экземпляр ClusterLogging -n openshift-logging 

    apiVersion: "logging.openshift.io/v1"
   вид: "ClusterLogging"
   метаданные:
     имя: "экземпляр"
   
   ....
   
   спецификация:
     managementState: «Управляемый»
     logStore:
       тип: "elasticsearch"
       elasticsearch:
         nodeCount: 2
         ресурсы: 1
           пределы:
             память: 2Gi
           Запросы:
             ЦП: 200 м
             память: 2Gi
         место хранения:
           storageClassName: "gp2"
           размер: «200 г»
         redundancyPolicy: «SingleRedundancy»
     визуализация:
       тип: "кибана"
       кибана:
         ресурсы: 2
           пределы:
             память: 1 Ги
           Запросы:
             ЦП: 500 м
             память: 1 Ги
         прокси:
           ресурсы: 3
             пределы:
               память: 100 Ми
             Запросы:
               ЦП: 100 м
               память: 100 Ми
         реплик: 2
     курирование:
       тип: "куратор"
       куратор:
         ресурсы: 4
           пределы:
             память: 200 Ми
           Запросы:
             ЦП: 200 м
             память: 200 Ми
         расписание: "* / 10 * * * *"
     коллекция:
       журналы:
         тип: "свободно"
         свободно:
           ресурсы: 5
             пределы:
               память: 736Mi
             Запросы:
               ЦП: 200 м
               память: 736Mi 

   1

   При необходимости укажите ограничения ЦП и памяти и запросы к хранилищу журналов.Для Elasticsearch необходимо настроить как значение запроса, так и предельное значение.

   2 3

   При необходимости укажите ограничения ЦП и памяти и запросы для визуализатора журналов.

   4

   При необходимости укажите ограничения ЦП и памяти и запросы для куратора журнала.

   5

   При необходимости укажите ограничения ЦП и памяти и запросы для сборщика журналов.

3.7. Использование допусков для управления размещением модулей журналирования кластера

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

Ошибки и допуски просты: пара ключ: значение . Заражение на узле указывает узлу отразить все стручки, которые не переносят заражение.

Ключ - это любая строка до 253 символов, а значение - это любая строка до 63 символов.Строка должна начинаться с буквы или цифры и может содержать буквы, цифры, дефисы, точки и символы подчеркивания.

Пример CR ведения журнала кластера с допусками

 apiVersion: "logging.openshift.io/v1"
вид: "ClusterLogging"
метаданные:
  имя: "экземпляр"
  пространство имен: openshift-logging
спецификация:
  managementState: «Управляемый»
  logStore:
    тип: "elasticsearch"
    elasticsearch:
      nodeCount: 1
      допуски: 1
      - клавиша: «логирование»
        оператор: "Существует"
        эффект: "NoExecute"
        терпение секунд: 6000
      Ресурсы:
        пределы:
          память: 8Gi
        Запросы:
          ЦП: 100 м
          память: 1 Ги
      место хранения: {}
      redundancyPolicy: "ZeroRedundancy"
  визуализация:
    тип: "кибана"
    кибана:
      допуски: 2
      - клавиша: «логирование»
        оператор: "Существует"
        эффект: "NoExecute"
        терпение секунд: 6000
      Ресурсы:
        пределы:
          память: 2Gi
        Запросы:
          ЦП: 100 м
          память: 1 Ги
      реплик: 1
  коллекция:
    журналы:
      тип: "свободно"
      свободно:
        допуски: 3
        - клавиша: «логирование»
          оператор: "Существует"
          эффект: "NoExecute"
          терпение секунд: 6000
        Ресурсы:
          пределы:
            память: 2Gi
          Запросы:
            ЦП: 100 м
            память: 1Gi 

1

Это допущение добавлено к модулям Elasticsearch.

2

Эта терпимость добавлена ​​к стручку Кибана.

3

Этот допуск добавлен к модулям сборщика журналов.

3.7.1. Использование допусков для управления размещением модуля хранилища журналов

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

Вы применяете допуски к модулям хранилища журналов через настраиваемый ресурс (CR) ClusterLogging и применяете taints к узлу через спецификацию узла.Заражение на узле - это пара ключ: значение , которая инструктирует узел отразить все поды, которые не переносят заражение. Использование определенной пары ключ: значение , которой нет в других модулях, гарантирует, что на этом узле могут работать только модули хранилища журналов.

По умолчанию модули хранилища журналов имеют следующие допуски:

 допусков:
- эффект: «NoExecute»
  ключ: "node.kubernetes.io/disk-pressure"
  оператор: «Существует» 

Предварительные требования

• Необходимо установить ведение журнала кластера и Elasticsearch.

Процедура

1. Используйте следующую команду, чтобы добавить заражение к узлу, на котором вы хотите запланировать модули ведения журнала кластера:

    Узлы администрирования $ oc <имя-узла> <ключ> = <значение>: <эффект> 

   Например:

    $ oc adm taint узлов node1 elasticsearch = node: NoExecute 

   Этот пример помещает заражение на node1 , который имеет ключ elasticsearch , значение node и эффект заражения NoExecute .Узлы с эффектом NoExecute планируют только модули, соответствующие заражению, и удаляют существующие модули, которые не совпадают.

2. Отредактируйте раздел logstore файла ClusterLogging CR, чтобы настроить допуск для модулей Elasticsearch:

    журнал
       тип: "elasticsearch"
       elasticsearch:
         nodeCount: 1
         терпимости:
         - клавиша: «elasticsearch» 1
           оператор: "Существует" 2
           эффект: "NoExecute" 3
           терпение Секунды: 6000 4 

   1

   Укажите ключ, который вы добавили к узлу.

   2

   Укажите, что оператор Exists требует наличия на узле заражения с ключом elasticsearch .

   3

   Задайте эффект NoExecute .

   4

   При желании можно указать параметр терпимости , чтобы установить, как долго модуль может оставаться привязанным к узлу перед тем, как его выселят.

Этот допуск соответствует заражению, создаваемому командой oc adm taint .Модуль с таким допуском может быть запланирован на node1 .

3.7.2. Использование допусков для управления размещением модуля визуализатора журнала

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

Вы применяете допуски к модулю визуализатора журнала через настраиваемый ресурс (CR) ClusterLogging и применяете taints к узлу через спецификацию узла.Заражение на узле - это пара ключ: значение , которая инструктирует узел отразить все поды, которые не переносят заражение. Использование определенной пары ключ: значение , которой нет в других модулях, гарантирует, что на этом узле может работать только модуль Kibana.

Предварительные требования

• Необходимо установить ведение журнала кластера и Elasticsearch.

Процедура

1. Используйте следующую команду, чтобы добавить заражение к узлу, на котором вы хотите запланировать модуль визуализатора журнала:

    Узлы администрирования $ oc <имя-узла> <ключ> = <значение>: <эффект> 

   Например:

    $ oc adm taint nodes node1 kibana = node: NoExecute 

   Этот пример помещает заражение на node1 , который имеет ключ kibana , значение node и эффект заражения NoExecute .Вы должны использовать эффект заражения NoExecute . NoExecute планирует только модули, соответствующие заражению, и удаляет существующие модули, которые не совпадают.

2. Отредактируйте раздел визуализации в ClusterLogging CR, чтобы настроить допуск для модуля Kibana:

    визуализация:
       тип: "кибана"
       кибана:
         терпимости:
         - клавиша: «кибана» 1
           оператор: "Существует" 2
           эффект: "NoExecute" 3
           терпение Секунды: 6000 4 

   1

   Укажите ключ, который вы добавили к узлу.

   2

   Задайте оператор Exists , чтобы запросить ключ , значение /, /, эффект , чтобы соответствовать параметрам.

   3

   Задайте эффект NoExecute .

   4

   При желании можно указать параметр терпимости , чтобы установить, как долго модуль может оставаться привязанным к узлу перед тем, как его выселят.

Этот допуск соответствует заражению, создаваемому командой oc adm taint . Под с этим допуском сможет планировать на node1 .

3.7.3. Использование допусков для управления размещением контейнера сборщика бревен

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

Вы применяете допуски к ведению журнала модулей сборщика с помощью настраиваемого ресурса (CR) ClusterLogging и применяете taints к узлу через спецификацию узла.Вы можете использовать taints и допуски, чтобы гарантировать, что модуль не будет вытеснен из-за проблем с памятью и процессором.

По умолчанию модули сборщика журналов имеют следующие допуски:

 допусков:
- ключ: "node-role.kubernetes.io/master"
  оператор: "Существует"
  эффект: "NoExecute" 

Предварительные требования

• Необходимо установить ведение журнала кластера и Elasticsearch.

Процедура

1. Используйте следующую команду, чтобы добавить заражение к узлу, на котором вы хотите, чтобы модули сборщика журналов были запланированы для модулей сборщика журналов:

    Узлы администрирования $ oc <имя-узла> <ключ> = <значение>: <эффект> 

   Например:

    $ oc adm taint nodes node1 collector = node: NoExecute 

   Этот пример помещает заражение на node1 , у которого есть ключ сборщика , значение node и эффект заражения NoExecute .Вы должны использовать эффект заражения NoExecute . NoExecute планирует только модули, соответствующие заражению, и удаляет существующие модули, которые не совпадают.

2. Отредактируйте раздел коллекции настраиваемого ресурса (CR) ClusterLogging , чтобы настроить допуск для модулей сборщика журналов:

    коллекция:
       журналы:
         тип: "свободно"
         свободно:
           терпимости:
           - ключ: «коллектор» 1
             оператор: "Существует" 2
             эффект: "NoExecute" 3
             терпение Секунды: 6000 4 

   1

   Укажите ключ, который вы добавили к узлу.

   2

   Задайте оператор Exists , чтобы запросить ключ , значение /, /, эффект , чтобы соответствовать параметрам.

   3

   Задайте эффект NoExecute .

   4

   При желании можно указать параметр терпимости , чтобы установить, как долго модуль может оставаться привязанным к узлу перед тем, как его выселят.

Этот допуск соответствует заражению, создаваемому командой oc adm taint . Под с этим допуском сможет планировать на node1 .

3.7.4. Дополнительные ресурсы

Дополнительные сведения о порчах и допусках см. В разделе Управление размещением подов с помощью порчи узлов.

3.8. Перемещение ресурсов ведения журнала кластера с помощью селекторов узлов

Вы можете использовать селекторы узлов для развертывания модулей Elasticsearch, Kibana и Curator на разных узлах.

3.8.1. Перемещение ресурсов ведения журнала кластера

Вы можете настроить оператор ведения журнала кластера для развертывания модулей для любого или всех компонентов ведения журнала кластера, Elasticsearch, Kibana и Curator на разных узлах. Вы не можете переместить модуль оператора регистрации кластера из установленного места.

Например, вы можете переместить модули Elasticsearch на отдельный узел из-за высоких требований к ЦП, памяти и диску.

Предварительные требования

• Необходимо установить ведение журнала кластера и Elasticsearch.Эти функции не устанавливаются по умолчанию.

Процедура

1. Отредактируйте пользовательский ресурс (CR) ClusterLogging в проекте openshift-logging :

    $ oc редактировать экземпляр ClusterLogging 

    apiVersion: logging.openshift.io/v1
   вид: ClusterLogging
   
   ...
   
   спецификация:
     коллекция:
       журналы:
         свободно:
           ресурсы: null
         тип: fluentd
     курирование:
       куратор:
         nodeSelector: 1
           узел-роль.kubernetes.io/infra: ''
         ресурсы: null
         расписание: 30 3 * * *
       тип: куратор
     logStore:
       elasticsearch:
         nodeCount: 3
         nodeSelector: 2
           node-role.kubernetes.io/infra: ''
         redundancyPolicy: SingleRedundancy
         Ресурсы:
           пределы:
             ЦП: 500 м
             память: 16Gi
           Запросы:
             ЦП: 500 м
             память: 16Gi
         место хранения: {}
       тип: elasticsearch
     managementState: Управляемый
     визуализация:
       кибана:
         nodeSelector: 3
           узел-роль.kubernetes.io/infra: ''
         прокси:
           ресурсы: null
         реплик: 1
         ресурсы: null
       тип: кибана
   
   ... 

1 2 3

Добавьте параметр nodeSelector с соответствующим значением к компоненту, который вы хотите переместить. Вы можете использовать nodeSelector в показанном формате или использовать пары <ключ>: <значение> в зависимости от значения, указанного для узла.

Проверка

Чтобы убедиться, что компонент переместился, вы можете использовать команду oc get pod -o wide .

Например:

• Вы хотите переместить модуль Kibana с узла ip-10-0-147-79.us-east-2.compute.internal :

   $ oc get pod kibana-5b8bdf44f9-ccpq9 -o wide 

  Пример вывода

   ИМЯ ГОТОВНОСТЬ СОСТОЯНИЕ ВОССТАНАВЛИВАЕТСЯ ВОЗРАСТ IP-УЗЛА НОМИНИРОВАННЫЕ ШЛЮЗЫ ГОТОВНОСТИ УЗЛА
  kibana-5b8bdf44f9-ccpq9 2/2 Выполняется 0 27 с 10.129.2.18 ip-10-0-147-79.us-east-2.compute.internal <нет> <нет> 

• Вы хотите переместить Kibana Pod на узел ip-10-0-139-48.us-east-2.compute.internal , выделенный узел инфраструктуры:

   $ oc получить узлы 

  Пример вывода

   ИМЯ СТАТУС РОЛИ ВОЗРАСТ ВЕРСИЯ
  ip-10-0-133-216.us-east-2.compute.internal Готовый мастер 60m v1.18,3
  ip-10-0-139-146.us-east-2.compute.internal Готовый мастер 60m v1.18.3
  ip-10-0-139-192.us-east-2.compute.internal Готовый рабочий 51m v1.18.3
  ip-10-0-139-241.us-east-2.compute.internal Готовый рабочий 51m v1.18.3
  ip-10-0-147-79.us-east-2.compute.internal Готовый рабочий 51m v1.18.3
  ip-10-0-152-241.us-east-2.compute.internal Готовый мастер 60m v1.18.3
  ip-10-0-139-48.us-east-2.compute.internal Готовность Инфра 51m v1.18.3 

  Обратите внимание, что у узла есть метка node-role.kubernetes.io/infra: '' :

   $ oc get node ip-10-0-139-48.us-east-2.compute.internal -o yaml 

  Пример вывода

   вид: Узел
  apiVersion: v1
  метаданные:
    имя: ip-10-0-139-48.us-east-2.compute.internal
    selfLink: /api/v1/nodes/ip-10-0-139-48.us-east-2.compute.internal
    uid: 62038aa9-661f-41d7-ba93-b5f1b6ef8751
    resourceVersion: '39083'
    creationTimestamp: '2020-04-13T19: 07: 55Z'
    ярлыки:
      узел-роль.kubernetes.io/infra: ''
  ... 

• Чтобы переместить модуль Kibana, отредактируйте ClusterLogging CR, чтобы добавить селектор узлов:

   apiVersion: logging.openshift.io/v1
  вид: ClusterLogging
  
  ...
  
  спецификация:
  
  ...
  
    визуализация:
      кибана:
        nodeSelector: 1
          node-role.kubernetes.io/infra: ''
        прокси:
          ресурсы: null
        реплик: 1
        ресурсы: null
      тип: кибана 

  1

  Добавьте селектор узла, чтобы он соответствовал метке в спецификации узла.

• После сохранения CR текущий модуль Kibana прекращает работу и развертывается новый модуль:

   $ oc get pods 

  Пример вывода

   НАЗВАНИЕ ГОТОВ СОСТОЯНИЕ ВОЗРАСТ НАЗАД
  cluster-logging-operator-84d98649c4-zb9g7 1/1 Бег 0 29 мин.
  elasticsearch-cdm-hwv01pf7-1-56588f554f-kpmlg 2/2 Бег 0 28 мес.
  elasticsearch-cdm-hwv01pf7-2-84c877d75d-75wqj 2/2 Бег 0 28 мес.
  elasticsearch-cdm-hwv01pf7-3-f5d95b87b-4nx78 2/2 Бег 0 28 м
  fluentd-42dzz 1/1 Бег 0 28м
  fluentd-d74rq 1/1 Бег 0 28м
  fluentd-m5vr9 1/1 Бег 0 28м
  fluentd-nkxl7 1/1 Бег 0 28м
  fluentd-pdvqb 1/1 Бег 0 28м
  fluentd-tflh6 1/1 Бег 0 28м
  kibana-5b8bdf44f9-ccpq9 2/2 Завершение 0 4 мин. 11 сек.
  kibana-7d85dcffc8-bfpfp 2/2 Запуск 0 33s 

• Новый модуль находится на ip-10-0-139-48.us-east-2.compute.internal узел:

   $ oc get pod kibana-7d85dcffc8-bfpfp -o wide 

  Пример вывода

   НАЗВАНИЕ ГОТОВНОСТЬ СОСТОЯНИЕ ВОССТАНОВЛЕНИЕ ВОЗРАСТ IP-УЗЛА НОМИНИРОВАННЫЕ ШЛЮЗЫ ГОТОВНОСТИ УЗЛА
  kibana-7d85dcffc8-bfpfp 2/2 Выполняется 0 43s 10.131.0.22 ip-10-0-139-48.us-east-2.compute.internal <нет> <нет> 

• Через несколько секунд оригинальная капсула Kibana будет удалена.

   $ oc get pods 

  Пример вывода

   НАЗВАНИЕ ГОТОВ СОСТОЯНИЕ ВОЗРАСТ НАЗАД
  cluster-logging-operator-84d98649c4-zb9g7 1/1 Бег 0 30 м
  elasticsearch-cdm-hwv01pf7-1-56588f554f-kpmlg 2/2 Бег 0 29 мес.
  elasticsearch-cdm-hwv01pf7-2-84c877d75d-75wqj 2/2 Бег 0 29 мес.
  elasticsearch-cdm-hwv01pf7-3-f5d95b87b-4nx78 2/2 Бег 0 29м
  fluentd-42dzz 1/1 Бег 0 29м
  fluentd-d74rq 1/1 Бег 0 29м
  fluentd-m5vr9 1/1 Бег 0 29м
  fluentd-nkxl7 1/1 Бег 0 29м
  fluentd-pdvqb 1/1 Бег 0 29 мес.
  fluentd-tflh6 1/1 Бег 0 29м
  kibana-7d85dcffc8-bfpfp 2/2 Запуск 0 62s 

3.9. Настройка systemd-journald и Fluentd

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

Мы рекомендуем установить RateLimitInterval = 1s и RateLimitBurst = 10000 (или даже больше, если необходимо), чтобы журнал не терял записи.

3.9.1. Настройка systemd-journald для ведения журнала кластера

По мере увеличения масштаба проекта в среду ведения журнала по умолчанию может потребоваться некоторая корректировка.

Например, если вам не хватает журналов, вам, возможно, придется увеличить ограничения скорости для journald. Вы можете настроить количество сообщений, которые будут храниться в течение определенного периода времени, чтобы при ведении журнала кластера не использовались чрезмерные ресурсы без потери журналов.

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

Процедура

1. Создайте журнал journald.conf с необходимыми настройками:

    Сжатие = да 1
   ForwardToConsole = нет 2
   ForwardToSyslog = нет
   MaxRetentionSec = 1 месяц 3
   RateLimitBurst = 10000 4
   RateLimitInterval = 1 с
   Хранилище = постоянное 5
   SyncIntervalSec = 1 с 6
   SystemMaxUse = 8g 7
   SystemKeepFree = 20% 8
   SystemMaxFileSize = 10M 9 

   1

   Укажите, нужно ли сжимать журналы перед записью в файловую систему. Укажите да , чтобы сжимать сообщение, или нет , чтобы не сжимать.По умолчанию да .

   2

   Настройте пересылку сообщений журнала. По умолчанию , но не для каждого. Указать:

   • ForwardToConsole для пересылки журналов на системную консоль.
   • ForwardToKsmg для пересылки журналов в буфер журнала ядра.
   • ForwardToSyslog для пересылки демону системного журнала.
   • ForwardToWall для пересылки сообщений в виде сообщений на стене всем вошедшим в систему пользователям.

   3

   Укажите максимальное время для хранения записей журнала. Введите число, чтобы указать секунды. Или укажите единицу измерения: «год», «месяц», «неделя», «день», «ч» или «м». Введите 0 , чтобы отключить. По умолчанию 1 месяц .

   4

   Настройте ограничение скорости.Если в течение интервала времени, определенного параметром RateLimitIntervalSec , получено больше журналов, чем указано в параметре RateLimitBurst , все последующие сообщения в пределах интервала отбрасываются, пока интервал не истечет. Рекомендуется установить RateLimitInterval = 1 с и RateLimitBurst = 10000 , которые являются значениями по умолчанию.

   5

   Укажите, как хранятся журналы. По умолчанию постоянный :

   • volatile для хранения журналов в памяти в / var / log / journal / .
   • постоянный для хранения журналов на диск в / var / log / journal / . systemd создает каталог, если он не существует.
   • auto для хранения журналов в / var / log / journal / , если каталог существует. Если он не существует, systemd временно сохраняет журналы в / run / systemd / journal .
   • нет , чтобы не хранить журналы. systemd удаляет все журналы.

   6

   Укажите тайм-аут перед синхронизацией файлов журнала на диск для журналов ERR , WARNING , NOTICE , INFO и DEBUG logs.systemd выполняет синхронизацию сразу после получения журнала CRIT , ALERT или EMERG . По умолчанию 1 с .

   7

   Укажите максимальный размер журнала. По умолчанию 8g .

   8

   Укажите, сколько места на диске systemd должен оставить свободным. По умолчанию 20% .

   9

   Укажите максимальный размер для отдельных файлов журнала, постоянно хранящихся в / var / log / journal .По умолчанию 10M .

   Если вы удаляете ограничение скорости, вы можете увидеть повышенную загрузку ЦП демонами ведения системного журнала, поскольку он обрабатывает любые сообщения, которые ранее были заблокированы.

   Для получения дополнительной информации о настройках systemd см. Https://www.freedesktop.org/software/systemd/man/journald.conf.html. Параметры по умолчанию, перечисленные на этой странице, могут не применяться к OpenShift Container Platform.

2. Преобразуйте журнал .conf в base64:

    $ экспорт jrnl_cnf = $ (cat /journald.conf | base64 -w0) 

3. Создайте новый объект MachineConfig для мастера или рабочего и добавьте параметры journal.conf :

   Например:

    apiVersion: machineconfiguration.openshift.io/v1
   вид: MachineConfig
   метаданные:
     ярлыки:
       machineconfiguration.openshift.io/role: worker
     название: 50-corp-journald
   спецификация:
     config:
       зажигание:
         версия: 2.2.0
       место хранения:
         файлы:
         - содержание:
             источник: данные: текст / простой; кодировка = utf-8; base64, $ {jrnl_cnf}
           режим: 0644 1
           перезапись: истина
           путь: /etc/systemd/journald.conf 2 

   1

   Установите разрешения для файла journal.conf . Рекомендуется установить 0644 разрешений.

   2

   Укажите путь к файлу journal.conf в кодировке base64.

4. Создайте конфигурацию машины:

    $ oc apply -f <имя файла> .yaml 

   Контроллер обнаруживает новый объект MachineConfig и генерирует новую версию rendered-worker- .

5. Следите за статусом развертывания новой визуализированной конфигурации на каждом узле:

    $ oc describe machineconfigpool / worker 

   Пример вывода

    Имя: worker
   Пространство имён:
   Этикетки: конфигурация машины.openshift.io/mco-built-in=
   Аннотации: <нет>
   Версия API: machineconfiguration.openshift.io/v1
   Вид: MachineConfigPool
   
   ...
   
   Условия:
     Сообщение:
     Причина: все узлы обновляются до rendered-worker-4517bcea7c93bd446f4830bc64e 

3.10. Настройка куратора лога

Вы можете настроить время хранения журнала. То есть вы можете указать, как долго хранилище журналов Elasticsearch по умолчанию хранит индексы, настроив отдельную политику хранения для каждого из трех источников журналов: журналов инфраструктуры, журналов приложений и журналов аудита.Инструкции см. В разделе Настройка времени хранения журнала.

Настройка времени хранения журнала является рекомендуемым методом для обработки данных журнала: он работает как с текущей моделью данных, так и с предыдущей моделью данных из OpenShift Container Platform 4.4 и более ранних версий.

При желании, чтобы удалить индексы Elasticsearch, использующие модель данных из OpenShift Container Platform 4.4 и более ранних версий, вы также можете использовать Elasticsearch Curator. В следующих разделах объясняется, как использовать Elasticsearch Curator.

Elasticsearch Curator устарел в OpenShift Container Platform 4.7 (OpenShift Logging 5.0) и будет удален в OpenShift Logging 5.1.

3.10.1. Настройка расписания Куратора

Вы можете указать расписание для Curator с помощью настраиваемого ресурса Cluster Logging , созданного установкой OpenShift Logging.

Куратор Elasticsearch устарел в OpenShift Container Platform 4.7 (OpenShift Logging 5.0) и будет удален в OpenShift Logging 5.1.

Предварительные требования

• Необходимо установить ведение журнала кластера и Elasticsearch.

Процедура

Чтобы настроить расписание Куратора:

1. Отредактируйте пользовательский ресурс ClusterLogging в проекте openshift-logging :

    $ oc редактировать экземпляр кластерного журнала 

    apiVersion: "logging.openshift.io/v1 "
   вид: "ClusterLogging"
   метаданные:
     имя: "экземпляр"
   
   ...
   
     курирование:
       куратор:
         расписание: 30 3 * * * 1
       тип: куратор 

   Часовой пояс устанавливается на основе хост-узла, на котором работает модуль куратора.

3.10.2. Настройка удаления индекса Куратора

Вы можете настроить Elasticsearch Curator для удаления данных Elasticsearch, которые используют модель данных до OpenShift Container Platform версии 4.5. Вы можете настроить для каждого проекта и глобальные параметры.Глобальные настройки применяются к любому не указанному проекту. Настройки для каждого проекта имеют приоритет над глобальными настройками.

Elasticsearch Curator устарел в OpenShift Container Platform 4.7 (OpenShift Logging 5.0) и будет удален в OpenShift Logging 5.1.

Предварительные требования

• Необходимо установить ведение журнала кластера.

Процедура

Чтобы удалить индексы:

1. Отредактируйте пользовательский файл конфигурации Curator OpenShift Container Platform:

    $ oc edit configmap / куратор 

2. При необходимости установите следующие параметры:

    конфиг.yaml: |
     название проекта:
       действие
         единица: значение 

   Доступные параметры:

   Таблица 3.2. Варианты проекта

   Имя переменной	Описание
   имя_проекта	Фактическое название проекта, например myapp-devel . Для журналов операций OpenShift Container Platform используйте имя .операции в качестве имени проекта.
   действие	Действие, которое нужно предпринять, в настоящее время разрешено только удалить .
   шт.	Период, используемый для удаления, дня , недели или месяца .
   значение	Количество единиц.

   Таблица 3.3. Параметры фильтра

   Имя переменной	Описание
   . По умолчанию	Используйте .по умолчанию как имя_проекта , чтобы установить значения по умолчанию для проектов, которые не указаны.
   .regex	Список регулярных выражений, соответствующих названиям проектов.
   узор	Допустимый и правильно экранированный шаблон регулярного выражения, заключенный в одинарные кавычки.

Например, чтобы настроить Curator на:

• Удалить индексы в проекте myapp-dev старше 1 день
• Удалить индексы в проекте myapp-qe старше 1 неделя
• Удалить операций журналов старше 8 недель
• Удалите все остальные индексы проектов после того, как им исполнится 31 день
• Удалите индексы старше 1 дня, соответствующие ^ project \.проект \ .. + \ - тест \ .. * $ ' удалять: дней: 2

  Когда вы используете месяца в качестве $ UNIT для операции, Curator начинает отсчет в первый день текущего месяца, а не в текущий день текущего месяца. Например, если сегодня 15 апреля, и вы хотите удалить индексы, которые на 2 месяца старше сегодняшнего (delete: months: 2), Curator не удаляет индексы, датированные более ранним, чем 15 февраля; он удаляет индексы старше 1 февраля. То есть он возвращается к первому дню текущего месяца, а затем возвращается на два целых месяца с этой даты.Если вы хотите быть точным с Curator, лучше использовать дни (например, delete: days: 30 ).

  3.11. Техническое обслуживание и поддержка

  3.11.1. О неподдерживаемых конфигурациях

  Поддерживаемый способ настройки ведения журнала кластера - его настройка с использованием параметров, описанных в этой документации. Не используйте другие конфигурации, так как они не поддерживаются. Парадигмы конфигурации могут меняться в разных выпусках OpenShift Container Platform, и такие случаи могут быть корректно обработаны только в том случае, если все возможности конфигурации контролируются.Если вы используете конфигурации, отличные от описанных в этой документации, ваши изменения исчезнут, поскольку оператор Elasticsearch и оператор ведения журнала кластера согласовывают любые различия. Операторы возвращают все в определенное состояние по умолчанию и по дизайну.

  Если вы должны выполнять конфигурации, не описанные в документации OpenShift Container Platform, вы должны установить для своего оператора регистрации кластера или оператора Elasticsearch значение Unmanaged .Среда ведения журнала неуправляемого кластера не поддерживается и не получает обновления, пока вы не вернете ведение журнала кластера на Управляемый .

  3.11.2. Неподдерживаемые конфигурации

  Вы должны установить Cluster Logging Operator в неуправляемое состояние, чтобы изменить следующие компоненты:

  • работа cron cron
  • Elasticsearch CR
  • развертывание Кибаны
  • свободно.conf файл
  • набор демонов Fluentd

  Вы должны установить оператор Elasticsearch в неуправляемое состояние, чтобы изменить следующий компонент:

  • файлы развертывания Elasticsearch.

  Явно неподдерживаемые случаи включают:

  • Настройка ротации журнала по умолчанию . Вы не можете изменить конфигурацию ротации журналов по умолчанию.
  • Настройка местоположения собранного журнала .Вы не можете изменить расположение выходного файла сборщика журналов, по умолчанию это /var/log/fluentd/fluentd.log .
  • Сбор журнала регулирования . Вы не можете снизить скорость чтения журналов сборщиком журналов.
  • Настройка сбора журналов Разбор JSON . Вы не можете форматировать сообщения журнала в JSON.
  • Настройка сборщика журналов с использованием переменных среды .Вы не можете использовать переменные среды для изменения сборщика журналов.
  • Настройка того, как сборщик журналов нормализует журналы . Вы не можете изменить нормализацию журнала по умолчанию.
  • Настройка Curator в развертываниях по сценарию . Вы не можете настроить курирование журналов в сценариях развертывания.
  • Использование файла действий куратора . Вы не можете использовать карту конфигурации Curator для изменения файла действий Curator.

  3.11.3. Политика поддержки неуправляемых операторов

  Состояние управления Оператора определяет, активно ли Оператор управляет ресурсами для связанного с ним компонента в кластере, как задумано. Если для оператора установлено неуправляемое состояние , он не реагирует на изменения в конфигурации и не получает обновления.

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

  Оператор можно перевести в неуправляемое состояние с помощью следующих методов:

  • Индивидуальная конфигурация оператора

    Индивидуальные операторы имеют в своей конфигурации параметр managementState . Доступ к нему можно получить по-разному, в зависимости от оператора. Например, оператор регистрации кластера выполняет это, изменяя настраиваемый ресурс (CR), которым он управляет, в то время как оператор выборки кластера использует ресурс конфигурации всего кластера.

    Изменение параметра managementState на Unmanaged означает, что Оператор не осуществляет активного управления своими ресурсами и не будет предпринимать никаких действий, связанных с соответствующим компонентом. Некоторые операторы могут не поддерживать это состояние управления, поскольку оно может повредить кластер и потребовать ручного восстановления.

    Изменение отдельных операторов в состояние Unmanaged делает этот конкретный компонент и функциональность неподдерживаемыми.