Игра EVE Online использует нетрадиционный подход к распределённому мониторингу из-за особенностей своей устаревшей архитектуры и масштабов временной симуляции. Вместо отправки всех сегментов с последующим решением о сохранении в конце трассировки платформа использует семплирование с начала трассировки, сочетая детерминированные и динамически изменяемые выборки, чтобы сохранять пригодное для анализа представление системы, не замедляя симуляцию и не увеличивая счёт за данные мониторинга.
Nicholas Herring из CCP Games представил этот опыт в материале, опубликованном через InfoQ, пояснив, что EVE Online работает в одной общей вселенной, включающей всех игроков, а не на отдельных региональных серверах. Её устаревшая система и более новая среда, известная как Quasar, обмениваются примерно 30 тысячами сообщений в секунду. Платформа также включает миллионы строк кода на C, C++, Python и SQL, поэтому внедрение нового централизованного слоя мониторинга само по себе представляет операционную проблему.
Почему платформа не использовала отложенное семплирование?
Решение было связано с производительностью и ограничениями существующей системы. Часть EVE Online работает на Stackless Python 2.7 на одном логическом процессоре, поэтому команда сочла, что полное извлечение сегментов с последующей отправкой в централизованную точку для обработки может навредить самой симуляции. Кроме того, отложенное семплирование требует собирать сегменты в одном месте, что при сбое пути сбора или соединения может скрыть значительные части системы.
Напротив, семплирование с начала трассировки позволяет каждому компоненту принимать решение локально. Когда отдельные части деградируют, команда может определить место проблемы по различиям в способности этих частей отправлять свои данные, вместо того чтобы потерять видимость всей системы.
Сочетание детерминированного подхода и EMA
Более старые системы используют детерминированное семплирование, чтобы снизить стоимость и влияние на производительность. Более новые компоненты Quasar используют алгоритм экспоненциального скользящего среднего, или EMA, который отслеживает такие ключи, как тип сообщения protobuf и частота его появления. Чем чаще сообщение повторяется, тем ниже становится частота его семплирования; редкие сообщения получают больше шансов попасть в выборку.
Этот подход помогает снизить шум от повторяющихся событий, таких как запуск огромного количества боеприпасов или изменения внешнего вида кораблей. Однако команда не полагается на него единолично, поскольку некоторые важные события исходят из устаревших систем или требуют гарантии появления хотя бы один раз. Распределение EMA между несколькими экземплярами приводит к тому, что в презентации называется «высокой водяной отметкой»: практическому минимальному объёму данных, который невозможно легко уменьшить после увеличения числа экземпляров, пространства ключей или частоты сообщений.
Что меняется на практике?
Этот опыт показывает, что настройка мониторинга начинается не с выбора инструмента трассировки, а с понимания характера событий, которые команда хочет измерять. CCP Games использует флаги функций, чтобы временно усилить мониторинг определённой области, корабля или персонажа либо ослабить мониторинг менее важных областей. Также применяются инструменты, отображающие частоту семплирования и оценивающие фактический размер событий, вместо того чтобы читать исходные числа так, словно они представляют всю вселенную.
В одной из конфигураций Quasar платформа использовала около 60 миллионов событий в день, стремясь задействовать примерно 90% доступной квоты. Это позволяет при необходимости запускать интенсивный мониторинг, снижая риск превышения стоимости. Однако такая гибкость требует операционной дисциплины: в презентации упоминались случаи, когда флаги мониторинга забывали отключить, что приводило к предупреждениям о росте расходов.
Ограничения, которые следует учитывать
Этот подход не предоставляет всех преимуществ отложенного семплирования. Команда не может впоследствии управлять соотношением успешных и неуспешных операций тем же способом, поэтому показатели уровня обслуживания могут стать чрезмерно чувствительными, когда событие крайне редко. Опыт также показал, что принятие решений о семплировании внутри настольных клиентов может скрывать важные взаимодействия; поэтому команда рассматривает возможность переноса принятия решения в доверенную сеть внутри серверной инфраструктуры.
Практический вывод заключается не в том, что семплирование с начала трассировки всегда превосходит другие подходы, а в том, что реальные ограничения могут сделать сочетание детерминированного подхода, EMA и временной активации более подходящим, чем дорогостоящая централизованная архитектура. Ценность этого метода по-прежнему зависит от способности команды определить, что заслуживает мониторинга, понять водяную отметку стоимости и сохранять хотя бы одну выборку каждого важного типа событий.