log pass
Смотреть что такое «log pass» в других словарях:
log|roll|ing — «LG ROH lihng, LOG », noun. 1. the act of giving political aid in return for a like favor, especially in order to pass legislation: »Our logrolling, our stumps and their politics…are yet unsung (Emerson). 2. a) the act of rolling floating logs,… … Useful english dictionary
pass — Synonyms and related words: OK, abalienate, abandon, abysm, abyss, accept, access, accredit, act like, administer, adopt, advance, affiliate, affirm, aggrandize, agree to, aisle, alien, alienate, alley, allow, ambulatory, amen, amortize, answer,… … Moby Thesaurus
White Pass and Yukon Railway — White Pass Yukon Rwy., Stand 2006[1] Legende … Deutsch Wikipedia
Chip log — A chip log, also called common log, ship log or just log, is a navigation tool used by mariners to estimate the speed of a vessel through water. Contents 1 Construction 2 Usage 3 Origins … Wikipedia
Matthew Callahan Log Cabin — U.S. National Register of Historic Places … Wikipedia
Oonche Log — Directed by Brij Produced by R.K. Kapoor Sayeeda Sadanah R.P. Sharma Written by Anjaan(lyrics) Starring Rajesh … Wikipedia
Stampede Pass — Infobox Mountain Pass Name = Stampede Pass Photo = Caption = Elevation = convert|3672|ft|m Location= Washington, USA Range = Cascade Range Coordinates = coord|47|17|0|N|121|21|4|W|type:pass Topographic Traversed by = Forest Service Road 54 and… … Wikipedia
Badger Pass Ski Area — (also known as Badger Pass) is a resort in Yosemite National Park. It is situated five miles south southeast of the Chinquapin intersection of Wawona Road (HWY 41 continuation) with Glacier Point Road in the southern area of Yosemite National… … Wikipedia
White Pass and Yukon Corporation — White Pass Yukon Rwy., Stand 2006[1] Legende … Deutsch Wikipedia
White Pass and Yukon Route — White Pass Yukon Rwy., Stand 2006[1] Legende … Deutsch Wikipedia
Как мы работаем с логами (сбор, хранение, анализ при помощи Graylog)
Всем привет! В этой статье мы хотим поделиться нашим опытом использования полезной платформы Graylog, которая ежедневно помогает собирать, надежно хранить и анализировать логи с десятков серверов, окутанных заботой нашей поддержки 🙂
Это первая часть статьи, в которой мы собрали в одном месте информацию, которая поможет установить и настроить Graylog, плюс, расскажем почему мы остановились имено на этой платформе.
Вторая часть, которая появится совсем скоро, будет содержать примеры использования и их реализацию.
Какую задачу мы решали?
Можно долго рассуждать о важности серверных логов и привести много примеров ситуаций, в которых они жизненно необходимы, но так как речь пойдет именно о сторонней системе и ее особенностях, то выделим ряд важных моментов:
Удобно, когда все логи хранятся в одном месте.
Круто, когда есть отчеты и возможность автоматически их проанализировать.
Полезно, когда логи можно посмотреть даже при “упавшем” сервере или после того как злоумышленник “прибрался” за собой.
Бесценно, когда о возникшей ошибке в логах будет оповещение.
Сформулировали задачу так:
“Подобрать бесплатное open source решение для сбора и анализа логов, не перегруженное функционалом, производительное, простое в установке и использовании.”
Почему Graylog?
Это не единственная и, возможно, далеко не самая лучшая платформа, но она широко распространена, прошла проверку временем и все еще поддерживается разработчиками.
Но, начать мы решили с анализа “конкурентов”.
Альтернативы
Splunk
Классный, модный, современный Splunk соответствует подавляющему большинству потребностей и скорее всего, может даже больше.
Но есть три момента, которые не понравились:
В нужной конфигурации решение платное.
Это закрытое решение.
Компания, без объяснений причин покинула рынок РФ.
Но, если вас это не смущает, немного полезной информации по платформе:
С этим “претендентом” не получилось, идем дальше.
Например, тут и тут его часто сравнивают с ELK, который и рассмотрим.
Что же пошло не так?
Некоторые фишки все же платные, например, уведомления и контроль доступа (однако, после некоторых событий часть данного функционала стала бесплатной).
Систему сложно настроить, “из коробки” она работать не будет.
Еще нужно упомянуть Open Distro, которая развивается на базе ELK, но полностью бесплатная, что не отменяет ресурсоемкость и сложность в настройке.
Немного полезной информации:
Инструкция по установке и настройке (eng).
Остановились на Graylog
Это open source решение.
Бесплатная версия имеет все необходимое.
Функционал небольшой, что удобно, ничего лишнего (для наших задач).
“Из коробки” решение уже работает, нужны минимальные настройки.
По сравнению с ELK ресурсоемкость значительно ниже.
Далее, мы предлагаем лонгрид по настройке и установке Graylog.
Установка и базовые настройки Graylog
В примере используем CentOS 8.
Prerequisites
Обновления обязательны, также установим пакеты для удобства работы, top-ы, etc.
смотрим где лежат сертификаты (пока самоподписанные)
кладём crt и key файлы в /etc/cockpit/ws-certs.d/
Firewall
(настройки будут индивидуальными для вашей сети, все команды даны для примера)
Кокпит должен быть доступен только админам, снаружи ему делать нечего. Создадим зону для интранета и добавим нужные адреса подсетей:
После добавления/удаления перезагрузим сервис:
Проконтролируем, что все правила верные:
SELinux
(настраиваем, а не отключаем его. )
Устанавливаем пакеты, если ещё не установлены, разрешаем апачу подключения:
Проверяем порты 9000, 9200, 27017:
Elastic Search
Импортируем ключ репозитория, добавляем конфигурационный файл репозитория, устанавливаем (вместо vim можно использовать nano, mcedit или любой другой редактор по вашему выбору):
Чтобы Elasticsearch работал с Graylog, необходимо установим имя кластера “graylog”:
Запускается довольно долго, в зависимости от конфигурации сервера или виртуальной машины. Проверяем:
Файлы Elasticsearch расположены здесь:
MongoDB
Добавляем конфигурационный файл репозитория:
Файлы MongoDB расположены здесь:
Graylog
Ссылки на оригинальную документацию:
Graylog не запускается самостоятельно (об этом есть сообщение в процессе установки).
Сначала настраиваем, потом пробуем запускать.
Генерируем хеш пароля:
Параметры эластика только для первого запуска, дальше конфигурация будет производиться уже из веб-интерфейса грейлога:
Также полезно будет настроить Email transport:
Download files → В секции GeoLite2 City → Get Permalinks (1, 2)
В Services → Manage License Keys (3)
Нажимаем «Generate new license key» создастся новый License Key. На email придёт уведомление о создании ключа.
Лицензия активируется в течение 5 минут.
Подставляем в ссылки, полученные на первом шаге ключ, полученный на втором шаге, загружаем файл с базой и файл контрольной суммы:
Проверяем целостность архива:
Установка GeoLite2 Database выполнена.
Немного ждём, затем смотрим логи запуска:
Возникают из-за того что установлена версия Enterprise, но нет соответствующей лицензии.
Заходим браузером, проверяем что веб-интерфейс доступен, можем залогиниться в веб-интерфейс:
Нас встречает мини-учебник по настройке:
NGINX
Создаём конфиг nginx, размещаем файлы сертификатов в /etc/nginx/ssl (у нас будут в одном файле сертификат + ключ):
Если получили ошибку:
То это из-за SELinux. Исправляем:
Немного реконфигурим Graylog:
Теперь Graylog слушает только на локалхосте, если открывали порт 9000, то необходимости в нём больше нет:
Размер БД
Установим размер индекса, так как виртуальный сервер имеет ограниченный объём диска.
System → Indices → Default index set → Edit
В Index Rotation Configuration:
В Index Retention Configuration:
Итого общий размер индексов будет не более 32GiB
Подведем итоги
Если вы дочитали и все еще с нами, то на этом закончим первую часть, где мы разобрали чем нам приглянулся Graylog и как можно его установить / настроить.
Надеемся, что наш опыт будет вам полезен.
Вопросы в комментариях приветствуются 🙂
Во второй части мы расскажем, как используя Graylog можно собирать системные логи и логи веб-сервера.
Дата-центр ITSOFT — размещение и аренда серверов и стоек в двух дата-центрах в Москве. За последние годы UPTIME 100%. Размещение GPU-ферм и ASIC-майнеров, аренда GPU-серверов, лицензии связи, SSL-сертификаты, администрирование серверов и поддержка сайтов.
Собираем, парсим и отдаём логи с помощью Logstash
Так уж сложилось, что по долгу работы мне приходится много времени уделять логам. Это и участие в выработке правил и политик сбора/хранения/использования логов, это и разбор разных инцидентов и обнаружение аномалий. За сутки наши программы, сервисы и серверы генерируют ОЧЕНЬ большое количество логов. И потребность копания в логах растёт постоянно.
Мне довелось поработать с коммерческими лог-менеджмент продуктами типа ArcSight, RSA Envision, Q1 Labs. У этих продуктов есть как плюсы, так и минусы. Но в статье речь пойдёт не о них.
Речь будет о Logstash.
Что же такое Logstash? Зачем он нужен? Что он умеет?
Logstash — это орудие для сбора, фильтрации и нормализации логов. Оно является бесплатным и open source приложением. Тип лицензии Apache 2.0.
Первой моё знакомство с LS (Logstash) произошло более года назад, и с того времени я очень плотно на него подсел. Мне нравится его идея и возможности. Для меня Logstash — это подобие мясорубки. Неважно что заходит в неё, но после не сложных манипуляций, на выходе всегда красиво и понятно оформленная информация.
Формат конфигурационного файла Logstash’а прост и понятен. Он состоит из трёх частей:
Входных, фильтрующих и выходных (или выходящих?) блоков может быть любое количество. Всё зависит от ваших потребностей и возможностей железа.
Пустые строки и строки начинающиеся с # — Logstash игнорирует. Так что комментирование конфигурационных файлов не вызовет никаких проблем.
1. INPUT
Пример конфигурации, для работы с локальными лог-файлами:
Построчное описание настроек:
тип/описание лога. При использовании нескольких входных блоков, удобно их разделять для последующих действий в filter или output.
указывается путь к лог-файлам, которые подлежат обработке. Путь должен быть абсолютным (/path/to/logs/), а не относительным (../../some/other/path/).
исключает из обработки файлы с соответствующими расширениями.
ждёт появления новых сообщений в конце файла. При обработки уже имеющихся логов, можно выставить «beginning», тогда обработка логов будет происходить построчно с начала файлов.
как часто (в секундах) проверять файлы на изменения. При больших значения, уменьшится частота системных вызовов, но так же увеличится время чтения новых строк.
время (в секундах) через которое будет обновлён список обрабатываемых файлов указанных в path.
Пример конфигурации, для работы с логами удалённых сервисов:
Построчное описание настроек:
тип/описание лога.
время (в секундах), по истечении которого не активное tcp соединение будет закрыто. Значение -1 — соединение всегда будет открыто.
в этом случае Logstash становится сервером, и начинает слушать на 192.168.3.12:3337. При установке mode => «client» Logstash будет присоединятся к удалённому ip:port для забора логов.
2. FILTER
В данном блоке настраиваются основные манипуляции с логами. Это может быть и разбивка по key=value, и удаление ненужных параметров, и замена имеющихся значений, и использование geoip или DNS запросов для ип-адресов или названий хостов.
На первый взгляд применение фильтров может показаться сложным и нелогичным, но это не совсем так.
Пример конфигурационного файла для основной нормализации логов:
Построчное описание настроек:
тип/описание лога. Здесь надо указать тот тип (type), который прописан в блоке input для которого будет происходить обработка.
путь к каталогу, содержащим шаблоны обработки логов. Все файлы находящиеся в указанной папке будут загружены Logstash, так что лишние файлы там не желательны.
указывается шаблон разборки логов. Шаблон можно использовать либо в конфигурационном файле, либо из файла шаблонов. Что бы не путаться, я для каждого формата логов создаю отдельный шаблонный файл.
С помощью grok фильтра можно структурировать большую часть логов — syslog, apache, nginx, mysql итд, записанных в определённом формате.
Logstash имеет более 120 шаблонов готовых регулярных выражений (regex). Так что написание фильтров для обработки большинства логов не должно вызвать особого страха или недопонимания.
Формат шаблонов относительно простой — NAME PATTERN, то есть построчно указывается имя шаблона и ему соответствующее регулярное выражение. Пример:
Можно использовать любой ранее созданный шаблон:
Шаблоны можно так же и комбинировать:
Допустим формат логов у нас следующий:
55.3.244.1 GET /index.html 15824 0.043
Среди готовых шаблонов, к счастью уже имеются некоторые регулярные выражения и не надо придумывать колёсное транспортное средство, приводимое в движение мускульной силой человека через ножные педали или через ручные рычаги (это я про велосипед если что).
С данным примером лога достаточно pattern записать в виде «%
После обработки наша строка будет выглядеть следующим образом:
client: 55.3.244.1
method: GET
request: /index.html
bytes: 15824
duration: 0.043
Со списком готовых grok-шаблонов можно познакомиться здесь.
Пример конфигурационного файла для изменения/удаления записей из логов:
Построчное описание настроек:
тип/описание лога. Указывается тип (type) логов с которыми будет происходить обработка.
удаление всех данных имеющих название поля client. Возможно указание нескольких названий полей.
переименование название поля HOSTORIP в client_ip.
замена всех «/» на «_» в поле messages.
добавление нового поля «sample1» со значением «from %
Пример конфигурационого файла:
Построчное описание настроек:
тип/описание лога. Указывается тип (type) логов с которыми будет происходить обработка.
временная метка события. Важная настройка для дальнейшей возможности сортировки или выборки логов. Если в логах время указано в unix timestamp (squid), то следует использовать match => [ «timestamp», «UNIX» ]
Пример конфигурационного файла для обработки логов в формате key=value:
Построчное описание настроек:
тип/описание лога. Указывается тип (type) логов с которыми будет происходить обработка.
использовать символы «=» и «:» для разделения ключа-значения.
название поля в котором искать ‘ключ=значение’. По умолчанию разбивка будет происходить для всей строки лога.
использовать символы «\t?&» для разделения ключей. \t — знак табулятора
Пример конфигурационного файла для «склеивания» многострочных логов (например Java stack trace):
Построчное описание настроек:
тип/описание лога. Указывается тип (type) логов с которыми будет происходить обработка.
при соответствии шаблону «pattern» строка принадлежит предыдущей (previous) строке.
3. OUTPUT
Пример конфигурационного файла для вывода логов в standard output:
указывается формат исходящего сообщения. Допустимо использование переменных после grok-фильтрации.
Пример конфигурационого файла для записи логов в файл:
интервал записи исходящих сообщений. Значение 0 будет записывать каждое сообщение.
файл исходящих сообщений будет сжат Gzip.
путь и название файла куда будут сохраняться исходящие сообщения. Можно использовать переменные. В данном примере, для каждого уникального IP адреса будет создана своя папка и сообщения будут записываться в файл соответствующий переменной %
формат исходящего сообщения.
Пример конфигурационного файла для записи логов в базу Elasticsearch:
название кластера указанного в cluster.name в настроечном файле Elasticsearch.
указывает какую базу Elasticsearch использовать внутреннюю или стороннюю.
транспортный port Elasticsearch.
IP адрес Elasticsearch
название индекса куда будут записываться логи.
Данный плагин можно использовать для алертов. Минус в том, что любые изменения уведомлений (в принципе как и любых других настроек) требуют перезапуск logstash программы, но разработчик говорит, что возможно в будущем этого не придётся делать.
Пример конфигурационого файла:
если у вас хватило сил дочитать до этих строк, значит вы можете сами определить смысл этих 3х настроек 🙂
тема письма уведомления. Можно использовать переменные. Например %
способ отсылки письма. Возможен один вариант из двух — smtp или sendmail.
стандартные настройки почтовых параметров.
«response errors» — название алерта (записывается в переменную %
4. Итого
Создаём файл habr.conf:
В новом терминальном окне пишем:
echo «Logs are cool!» | nc localhost 11111
Смотрим результат в окне где запущен Logstash. Если там появилось секретное послание, значит всё работает.
Как мы работаем с логами (сбор логов с сервера, возможность визуализации данных при помощи Graylog)
Привет! Это вторая часть статьи, в которой мы будем разбирать практическое применение платформы Graylog.
В первой части мы разобрали как платформу установить и произвести ее базовую настройку, а сегодня рассмотрим пару примеров применения ее возможностей на практике.
В частности, разберем настройку сбора логов с веб-сервера и возможность визуализировать полученные данные.
Настраиваем сбор логов с сервера
Работаем в web-интерфейсе:
Начнем со сбора syslog
Создаём UDP Input для системных логов:
System/Overview → Inputs
Выбираем тип Input-а:
Select input → Syslog UDP
Нажимаем кнопку Launch new input.
Внимание!
Остальные значения можно оставить по умолчанию:
Сохраняем конфигурацию, получаем работающий Input:
Для проверки работы Input выполним со своей рабочей станции или с любого другого хоста с linux/mac:
Переходим в веб-интерфейсе Show received messages, видим полученное сообщение.
Настройки для сервера с которого собираем логи:
Уменьшаем количество логов
В CentOS 7 в /var/log/messages, как правило видим много спама, примерно такого:
Данные сообщения не несут для нас полезной информации, можем их отключить:
Передаём логи в Graylog:
Если передаём данные по UDP, как сейчас настроено в инпуте Graylog-а:
Но если нужно по TCP, добавляем ещё одну “@”:
После редактирования делаем рестарт сервиса:
Проверяем наличие данных от хоста в Graylog-е.
На этом настройку сбора syslog считаем завершённой. На случай чрезвычайных ситуаций, или просто для информации, полезны будут оповещения о событиях (ошибках дисков, нехватке памяти, логинах, etc).
Настраиваем оповещения
Alerts → Alerts & Events → Get Started!
Шаг 1: “Event Details”:
Title: oom-killer invoked
Description (Optional): oom-killer was invoked on server or virtual machine
Шаг 2: “Filter & Aggregation”:
Condition Type: Filter & Aggregation
Search Query: «oom-killer»
(Тут правила построения запроса)
Streams (Optional): All messages
Search within the last: 10 minutes
Execute search every: 10 minutes
Устанавливаем чекбокс Enable
Create Events for Definition if… Filter has results
Если в логах уже есть такое событие, можно будет наблюдать его в Filter preview.
Шаг 4: «Notifications» → Add Notification:
Choose Notification: Create New Notification.
Title: Slack notification
Notification Type: Slack Notification
Configuration Color: можно выбрать цвет
Channel: #monit (в какой канал будут приходить данные уведомления).
Custom Message (optional): можно выбрать какие поля оставляем в сообщении.
Остальные настройки можно оставить по умолчанию.
В Notification Settings ничего изменять не будем:
Шаг 5: «Summary»: Ещё раз удостоверимся что настройки верны.
Нажимаем Done.
Тестируем оповещение. На хосте, с которого собираем syslog пишем маленькую программку на С:
Компилируем и запускаем. Скрипт занимает всю доступную память, после чего приходит oom-killer и его убивает:
В /var/log/messages можем наблюдать данный процесс:
В Slack видим оповещение о событии (здесь сообщение стандартное, по умолчанию, но его можно кастомизировать под ваши требования):
Graylog Sidecar
Graylog может собирать также логи сервисов, и вообще практически любые логи.
Будем использовать Graylog Sidecar для управления конфигурацией и бэкенд Filebeat, который собирает события и отправляет на Graylog-сервер. Схема работы для данного кейса:
Мы будем работать с access-логами веб-сервера nginx, работающего под CentOS linux.
Готовые контент-паки для различных сервисов (apache, nginx, …) различной степени свежести есть тут.
Но, чтобы разобраться как всё работает мы пойдём своим путём.
Получаем токен
System → Sidecars:
Нажимаем на ссылку:
Do you need an API token for a sidecar? Create or reuse a token for the graylog-sidecar user
Ранее созданные токены также можно найти по этой ссылке.
Token Name: myToken
Нажимаем кнопку Create Token
Там же можно скопировать его в буфер обмена, если нужно кнопкой Copy to clipboard, предварительно убрав чекбокс Hide Tokens.
System → Inputs:
Выбираем тип инпута Beats, жмём Launch New Input
Настройка в данном случае практически не отличается от той, что делали для syslog
Устанавливаем чекбокс Global:
Остальное оставляем по умолчанию (разумеется, в продакшн-среде, особенно при передаче сенситивных данных нужно будет добавить SSL-сертификаты, но пока обойдемся без них).
Нажимаем кнопку Save.
Не забываем добавить правило для 5044/tcp в Firewall.
Также нужен будет 443-й порт, но он у нас уже должен быть открыт:
System → Sidecars → Configuration
В секции Configuration нажимаем кнопку Create Configuration:
Configuration color: можно выбрать желаемый цвет
collector: filebeat on linux
Configuration редактируем следующим образом
Нажимаем кнопку Create:
Далее необходимо установить менеджер конфигурации и коллектор на хосте, с которого будет производиться сбор логов:
Sidecar
Обязательно, вносим в файл конфигурации строки:
filebeat
Не забываем про правило firewall с соответствующим портом, если это необходимо:
Теперь Sidecar должен быть виден в System → Sidecars → Overview
Назначим созданную конфигурацию на этот Sidecar.
Нажимаем кнопку Administration:
filebeat → Configure → выбираем нужную конфигурацию:
В открывшемся поп-апе подтверждаем, что всё верно → Confirm:
Идём в System → Inputs, на инпуте graylog-sidecar нажимаем Show received messages,
наблюдаем логи nginx:
Extractor
System → Inputs → Manage extractors
Выбираем нужный Sidecar, затем нажимаем кнопку Load Message
Recent message выбирает последнее пришедшее сообщение, но удобнее выбрать нужное сообщение по message_id и index.
Парсить будем само сообщение:
На поле message нажимаем Select extractor type → Grok pattern
Лог nginx по умолчанию имеет формат (можем найти его в nginx.conf):
Grok pattern будет выглядеть так:
Нажимаем Try against example и в Extractor preview проверяем правильность паттерна:
Остальные параметры можно оставить по умолчанию, только имя нужно будет указать:
Condition: Always try to extract
Extraction strategy: Copy
Extractor title: nginx combined
Нажимаем Create extractor
Переходим в меню System → Inputs → Show received messages, в инпуте graylog-sidecar.
Теперь все новые логи будут содержать отдельные поля message:
Поиск по логам стал намного проще, например:
При составлении запроса Graylog подсказывает параметры, что довольно удобно:
Также будет полезно создать Stream (поток).
Он нам нужен будет в дальнейшем:
Streams → Create stream
Description: Nginx access logs
Index Set: Default index set
Сохраняем кнопкой Save
Stream создан, но пока неактивен.
Добавляем правило для этого потока (кнопка Manage Rules):
Выбираем нужный Input, создаём правило (кнопка Add stream rule).
В поп-апе New Stream Rule:
Требуется все сообщения из Sidecar-а поместить в этот поток, поэтому:
Сохраняем кнопкой Save.
Правило добавлено, сохраняем кнопкой I’m done!:
Запускаем поток: Start stream.
Нажав на имя потока Sidecars можем также просматривать сообщения в нём и производить поиск по этим сообщениям.
Немного бесполезного, но красивого
На этапе установки, в первой части статьи мы прикрутили к graylog-у базу geoip.
Теперь посмотрим, как её использовать, а также выведем карту мира, визуально демонстрирующую, откуда к нам на сайт приходят посетители.
Создаём data adapter
System → Lookup Tables → кнопка Data Adapters → Create data adapter:
Description: GeoIP Lookup Table
File Path: /etc/graylog/server/GeoLite2-City.mmdb
Database type: City database
Остальное по умолчанию.
Для завершения нажимаем кнопку Create adapter.
Создаём Caches:
System → Lookup Tables → кнопка Caches → кнопка Create cache
Cache Type: Node-local, in-memory cache
Description: GeoIP Cache
Остальное можно оставить по умолчанию.
Нажимаем кнопку Create Cache:
Создаём Lookup table:
System → Lookup Tables → Lookup Tables (активна по умолчанию) → Create Lookup Table
Description: GeoIP Lookup
Data Adapter: GeoIP (geoip)
Нажимаем кнопку Create Lookup Table:
Создаём Pipeline (пайплайны позволяют обрабатывать сообщения из потоков):
System → Pipelines → кнопка Manage rules → кнопка Create Rule
Description: Incoming connections
Нажимаем кнопку Save&Close.
Теперь пайплайн:
System → Pipelines → кнопка Manage pipelines → кнопка Add new pipeline
Description: Incoming connections
Наблюдаем сообщение, что только что созданный пайплайн не подключен ни к одному потоку:
Нажимаем кнопку Edit connections, подключаем:
А также в Stage 0 нажимаем Edit и добавляем к нему правило:
Идём в Streams → Sidecars, смотрим новые сообщения.
Проблема возникает из-за порядка обработки правил.
Идём в System → Configurations
1 AWS Instance Name Lookup
3 Pipeline Processor
4 Message Filter Chain
1 AWS Instance Name Lookup
3 Message Filter Chain
4 Pipeline Processor
Нажимаем кнопку Update, перетаскиванием располагаем правила в правильном порядке:
Снова идём в Streams → Sidecars, смотрим новые сообщения и видим в них искомые геоданные:
Теперь будем смотреть красивую карту:
В Streams → Sidecars добавляем Aggregation:
Нажимаем Edit:
Visualization type: World Map
Сохраняем: Save
Теперь можно визуально оценить откуда к нам на сайт приходят посетители:
На этом всё, надеемся, что данная информация будет вам полезна.
Данная статья изначально появилась в виде заметки / howto для внутреннего использования, поэтому может местами быть немного запутанной. Ждем ваши вопросы, предложения и замечания в комментариях!
Дата-центр ITSOFT — размещение и аренда серверов и стоек в двух дата-центрах в Москве. За последние годы UPTIME 100%. Размещение GPU-ферм и ASIC-майнеров, аренда GPU-серверов, лицензии связи, SSL-сертификаты, администрирование серверов и поддержка сайтов.
