Делаем лог-систему для Minecraft
Сегодня речь пойдет о мире, о который большинство из вас не знает, но при этом там крутятся многие отличные инженеры-разработчики и большие деньги. Да, как ни странно, речь пойдет о Minecraft.
Minecraft — игра-песочница и на мультиплеер-серверах остро стоит проблема гриферства (от англ. griefing — вредительство), когда игроки рушат чужие постройки. На серверах с этой проблемой справляются по-разному. На публичных используют плагин на ‘приват’, на остальных же все строится на доверии.
Еще один из способов предотвратить гриферство — бан всех гриферов. И для того чтобы вычислить их, приходиться логгировать установку и удаление блоков. Собственно, о процессе создания такой лог-системы и пойдет речь дальше.
Выбор базы данных
Итак, вот у нас массив данных и хорошо бы его куда-то сохранять. Умные люди давно придумали БД. Лично у меня требования к БД были такие:
Последний пункт появился из-за того, что не на всех хостингах есть возможность получить root-доступ или установить какой-либо пакет. К тому же, не хотелось усложнять процедуру установки, а остановиться на «Кинул и забыл».
Базы данных, которые удовлетворяли бы всем критериям я не нашел, поэтому решил сделать свою мини-БД на Java.
Оптимизация места на жёстком диске
Основная проблема игры, как считают многие, — все её вычисления происходят в одном потоке. Это настоящая боль держателей серверов. Распараллелить изначально однопоточную архитектуру — надо постараться.
Поэтому само логгирование пришлось вынести в отдельный поток. А чтобы система не захлебнулась от Event’ов в очереди, добавить поддержку воркеров. Количество воркеров настраеваемое.
В итоге получилось так, что само событие перехватывается в главном тике, потом отправляется в поток, который занят тем, что распределяет задачи между воркерами. Там мы получаем файл, в который надо занести наше событие и передаем уже воркеру, который прикреплен к этому файлу. И сама операция IO происходит в воркере.
Оптимизация места на жёстком диске
Большое количество событий может привести к тому, что логи будут весить больше, чем сам мир. Этого нам допустить нельзя, поэтому будем думать.
Изначально строчка в логфайле выглядела так:
[2001-07-04T12:08:56.235-0700]Player PLACE to 128,128,128
При беглом взгляде можно заметить, что 2001-07-04T12:08:56.235-0700 можно сократить до Timestamp, а PLACE или REMOVE на символ ‘+’ и ‘-‘ соответственно. Ну и уберем нафиг ‘to’:
Не сложно заметить, что в логе будет часто повторятся nickname и blockid. Соответсвенно, их можно вынести в отдельный файл, а в лог писать только id
[123454678]1 + 1 128,128,128
В итоге я пришел к тому, что в строчке лога остались только числа и один символ. Мы сэкономим много места, если уберем разделители (пробелы) и числа будем записывать как байты, а не как символы. Сообственно, это привело меня к решению использовать байтовые логи.
Сама байтовая строка теперь выглядит так:
| Name | posX | posY | posZ | typeaction | playerid | blockid | timestamp |
|---|---|---|---|---|---|---|---|
| Field Length (bytes) | 4 byte | 4 byte | 4 byte | 1 byte (‘0’ for Remove, ‘1’ for Insert) | 4 byte | 8 byte | 8 byte |
Итого мы имеем 35 байтов на строку фиксированно (1 байт для разделения строк).
Вначале был соблазн оставить 34 байта, но так как запись ведется в один файл, то в случае с фиксированной длинной, если побьется одна строка, весь файл станет нечитаемым.
Структура строки для blockname to id:
| Name | id | blockname |
|---|---|---|
| Field Length (bytes) | 8 byte | 1 byte per symbols |
21 байтов на блок
Имя файла: blockmap.bytelog
Структура строки для nickname to id:
| Name | id | nickname |
|---|---|---|
| Field Length (bytes) | 4 byte | 1 byte per symbols |
10 байтов на игрока
Имя файла: nickmap.bytelog
Оптимизация памяти
Чтобы быстро маппить blockname и nickname в id пришлось держать содержимое обоих файлов в памяти. Java не может в HashMap хранить примитивные типы, поэтому каждый Integer будет стоить нам
50 байт в памяти, что очень много.
Решить эту проблему нам поможет библиотека trove.
Но каждый символ у нас занимает примерно 2 байта. Мы можем снизить потребления памяти с помощью самописного файла ASCIString, в котором символы хранятся в byte[], а не в char[].
Тестирование
В тестировании байтовой сериализации и десериализации ничего необычного нет, а вот для тестирования компонентов, к которым требовался многопоточный доступ пришлось использовать фреймворк от гугла Thread Weaver. Обычный тест с использованием этого фреймворка выглядит так:
Фреймворк стучит из обоих потоков с разным порядком, что позволяет выловить самые противные баги в асинхронном коде.
Заключение
Пока по количеству скачиваний будет понятно стоит ли развивать дальше этот мод и идею. Из примерных планов на будущее:
Данный плагин упростит уход за вашим сервером. С его помощью, вы сможете узнать, кто и когда поставил, разрушил тот или иной блок, откатить действия игроков и многое другое. Проще говоря, он позволит просматривать логи и возвращать состояние блоков, территории, или всего вашего сервера к нужному вам промежутку времени.
Он не требует настроек, сразу же после установки его можно использовать.
Нажатие ЛКМ по верхней части блока, выведет информацию в чат, о том, кем и когда был разрушен блок, который находился над данным. Установив любой блок, вы узнаете информацию о всех блоках, находившиеся ранее на этих координатах.
П ри нажатии ПКМ на любое устройство (кнопка, рычаг, дверь и т.п.) вы узнаете ник игрока, последний использовавший его. Повторный ввод команды /co inspect заканчивает работу с данным плагином. 
Команда для отката изменения блоков: /co rollback u: t: b: e: r:
— u: ник игрока, относительно действий которого, произойдет откат
— b: блок, при указании ID откат затронет только эти блоки
— e: исключение, при указании ID, блок останется нетронутым
— r: радиус, относительно вашего положения, в котором произойдет откат
Другие команды плагина :
/co lookup u: t: b: e: r: — просмотр логов по параметрам
/co purge — очистить информацию о блоках за один или несколько месяцев.
Как мы работаем с логами (сбор логов с сервера, возможность визуализации данных при помощи 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-сертификаты, администрирование серверов и поддержка сайтов.
Логи сервера: что это, зачем нужны, как включить, посмотреть, проанализировать
Логи сервера (журнал сервера) – это файлы, где в хронологическом порядке содержатся данные о работе сервера, записаны все действия посетителей на веб-ресурсе (откуда пришли, в каком браузере сидят, какой IP-адрес, сколько времени пробыли, какие данные получали или отправляли), а также информация, с помощью которой анализируется и оценивается сайт и его посетители.
Зачем нужны логи?
Есть несколько видов логов:
Если веб-сайт работает нормально, в штатном режиме, нет необходимости просматривать лог-файлы. Но бывают случаи, когда сервер внезапно перегружается, ресурс подвергается спаму, выдает изобилие ошибок или возникают проблемы в ранжировании в поисковых системах.
В таком случае системные администраторы или seo специалисты начинают анализировать посетителей, идентифицировать доступ к файлам со стороны постороннего лица, а именно IP-адрес, откуда он был осуществлен, после чего делают соответствующие выводы.
На заметку. Для обычного пользователя такие файлы будут представлять случайный набор символов, однако для разработчиков сайтов, seo специалистов и системных администраторов логи читабельные и несут важную информацию.
Как включить журнал записей?
В большинстве случаев хостер отключает функцию записи логов на хостинге, чтобы сохранить больше места на диске. На примере админки хостинга Beget.com рассмотрим, как активировать запись логов:
Здесь же вы видите путь, где располагаются ваши логи
Если у вашего хостинга в админ панели нет функции включить запись самостоятельно, то для получения логов потребуется обратиться в техподдержку хостинга и запросить их, так как они могут быть просто отключены.
Как посмотреть логи сервера?
Включив лог-файлы на сервере, уже через час соберется довольно большое количество записей, после чего можно скачать файл в директорию сайта и открыть его через визуальный редактор для просмотра.
Логи хранятся в файле access.log в системной папке любого сервера, будь то Nginx, Apache или любой другой. Лог-файлы открываются через текстовые редакторы. Любая строчка здесь соответствует не больше, чем одному обращению.
Отыскать логи можно и через панель управления хостинга, а именно в разделах Логи или Журналы.
Анализ логов сервера
Рассмотрим строку, взятую с записи одного из логов сервера:
И рассмотрим значение всех символов, которые здесь есть:
Это один из множества логов, и чтобы прочитать их все вручную, нужно потратить невероятное количество сил и времени. Но на помощь вебмастерам приходят специальные анализаторы данных, трудно читаемых человеком. Они анализируют данные, а затем структурируют их. К часто используемым программам можно отнести:
И это далеко не все программные обеспечения, которые можно найти в сети. Они есть и в платном, и в бесплатном доступе.
На некоторых хостингах их можно установить при включении логов. Например в ранее нами рассматриваемом хостинге Beget.com когда мы включаем логи, нам предлагается установить Awstats.
Успешно анализируя лог-файлы, вы сможете отыскать слабое место на сайте, из-за которого он работает нестабильно, или же идентифицировать IP, с которого вам хотят навредить. Особенно стоит обращать внимание на запросы POST, потому что именно с их помощью мошенники взламывают ресурсы чаще всего.
Лог ошибок error.log
Это файл, где тоже протоколируются логи, но они относятся не к пользователям, а к ошибкам, возникающим на сервере. Аналогично файлу access.log, в error.log каждая отдельная строка показывает запись только одной ошибки. Благодаря этому файлу можно узнать причину возникновения ошибки и ее тип, а также IP пользователя, которому она была показана. Рассмотрим пример:
Здесь мы наблюдаем ошибку в модуле контактов, в файле default.php в строке 14.
Заключение
Журнал сервера – это эффективный инструмент, позволяющий быстро получить информацию о том, где у сайта есть лазейка, из-за которой перегружается сервер. Но просматривать логи вручную – дело хлопотное, поэтому и были созданы такие специальные сервисы-анализаторы, помогающие куда быстрее найти ошибки и указать на слабые места веб-ресурса.
Оцените эту статью. Чтобы мы могли делать лучший контент! Напишите в комментариях, что вам понравилось и не понравилось!
Рейтинг статьи: 4.6 / 5. Кол-во оценок: 14
Пока нет голосов! Будьте первым, кто оценит эту статью.