Наша изначальная проблема
В прошлом году у нас возникла проблема: вредоносное программное обеспечение на одном сервере засоряло наш центральный сервер Graylog таким количеством сообщений, что это вызывало проблемы в работе других приложений.
Основная проблема заключалась в том, что старые полезные сообщения из других приложений удалялись раньше обычного, а индекс заполнялся бесполезными сообщениями из вредоносного приложения.
Я предложил исправить это так: дать каждому приложению свой собственный индекс, чтобы ни одно приложение не могло лишить другое приложение места для хранения журналов. Это не потребовало бы никаких изменений в самих приложениях, а потребовало бы только изменений внутри Graylog. Однако ничего не было сделано, поскольку планировалось новое решение Graylog на основе Kubernetes.
Решение, которое нам предложили
Перенесемся в настоящее время: мы как раз находимся в процессе ввода в эксплуатацию нашей новой системы Graylog.
Изначально нам сказали, что каждое приложение будет иметь свой собственный независимый сервер Graylog (балансировщик нагрузки, конечные точки GELF, узлы Graylog, кластер поиска Elastic) и веб-сайт Graylog.
Проблема в том, что между различными приложениями существуют сложные отношения, и необходимость обращаться к разным веб-серверам Graylog для получения журналов из разных приложений (graylog-application1.site для журналов из application1 и graylog-application2.site для журналов из application2, а не просто обращаться к graylog.site) значительно усложняла поиск между приложениями.
Пересмотренное решение
После того, как это было отмечено, было предложено решение сгруппировать приложения по тому, насколько вероятно, что их нужно будет искать вместе, поэтому теперь мы ожидаем, что у нас будут отдельные серверы Graylog для каждой группы (application-group-a.site для приложений 1 и 3 и application-group-b.site для приложений 2, 4 и 5 и т. д.).
Но мне интересно, необходимо ли это или достаточно.
Это будет означать, что многие вероятные поиски между приложениями будут выполняться легко, но некоторые из самых сложных для решения проблем поддержки — это те, которые выходят за границы приложений и которые менее очевидны, и эти поиски больше не будут такими простыми (и фактически могут стать невозможными, если вы не знаете, какое приложение задействовано).
Люди утверждают, что просто наличие отдельных индексов на одном центральном сервере graylog не обеспечивает достаточной изоляции между группами приложений. Они хотят быть уверены, что входящие сообщения из одного приложения никогда не будут мешать входящим сообщениям из других приложений, поэтому они хотят полной изоляции между группами.
Моя проблема в том, что это не поможет при использовании приложения в группе, которое становится неконтролируемым и спамит на сервере Graylog группы. Если мы сможем найти решение, которое предотвращает отказ в обслуживании в группе, у нас также будет решение для единой централизованной службы Graylog.
Я бы сказал, что горизонтальное масштабирование единой центральной службы с большим количеством узлов Graylog с балансировкой нагрузки, большим количеством узлов гибкого поиска, большим количеством конечных точек GELF и т. д. было бы лучшим решением, чем наличие десятков серверов Graylog.
Вопросы
Могут ли отдельные серверы Graylog на самом деле обеспечить тот уровень изоляции (снижение риска отказа в обслуживании), который, по-видимому, нужен людям, если все они размещены в одном кластере Kubernetes?
Можем ли мы обеспечить аналогичный или лучший уровень изоляции с помощью одного центрального сервера Graylog, чем с помощью отдельных групповых серверов Graylog?
Используют ли другие организации Graylog таким же образом, с множеством веб-сайтов клиентской части, или следует ожидать наличия единого центрального веб-сайта для доступа ко всем журналам?
По сути, я пытаюсь либо убедить себя, что я ни о чем не беспокоюсь, и что это решение является общепринятым, либо найти аргументы, которые убедят людей в том, что то, что мы рассматриваем, противоречит передовой практике, и нам действительно не следует этого делать.
Мне бы очень хотелось найти решение, которое устроило бы всех, но на данный момент мне кажется, что, предлагая нынешнее решение, мы скорее выплескиваем вместе с водой и ребенка.
решение1
Ваши опасения и вопросы об архитектуре вашей установки Graylog вполне обоснованы. Важно найти решение, которое сбалансирует потребность в изоляции и управлении ресурсами с простотой использования и управляемостью. Давайте разберем это, как Крис Кросс!
1. Будут ли отдельные серверы Graylog на самом деле обеспечивать необходимый людям уровень изоляции (снижение риска отказа в обслуживании), если все они размещены в одном кластере Kubernetes?
Отдельные серверы Graylog, работающие в одном кластере Kubernetes, могут обеспечить определенный уровень изоляции, но важно понимать, что они по-прежнему совместно используют ресурсы на уровне кластера, включая пропускную способность сети, хранилище и, возможно, ЦП и память. Если одно приложение в группе становится неконтролируемым и начинает рассылать спам-сообщения, это может потенциально повлиять на производительность других серверов Graylog в том же кластере из-за конкуренции за ресурсы. Хотя Kubernetes предлагает возможности управления ресурсами, это не панацея от проблем, связанных с ресурсами.
2. Можем ли мы обеспечить аналогичный или лучший уровень изоляции с помощью одного центрального сервера Graylog, чем с помощью отдельных групповых серверов Graylog?
Один центральный сервер Graylog может обеспечить изоляцию между приложениями с помощью отдельных индексов, но, как вы упомянули, он может не предотвратить перегрузку сервера вредоносным приложением и возникновение проблем для других приложений. Чтобы смягчить это, вы можете рассмотреть возможность внедрения более строгих политик ограничения скорости и регулирования для входов или источников, генерирующих сообщения журнала. Кроме того, вы можете масштабировать центральный сервер Graylog горизонтально для обработки возросшей нагрузки, что может быть более экономически эффективным, чем управление несколькими отдельными серверами.
3. Используют ли Graylog другие организации таким же образом, с множеством интерфейсных веб-сайтов, или ожидается наличие одного центрального веб-сайта для доступа ко всем журналам?
Выбор между несколькими веб-сайтами front-end для разных экземпляров Graylog или одним центральным веб-сайтом зависит от конкретных потребностей и предпочтений организации. Оба подхода являются допустимыми и имеют свои преимущества и компромиссы.
Несколько веб-сайтов Front-end: этот подход подходит, когда разным командам или приложениям требуются отдельные экземпляры Graylog для лучшей изоляции, контроля и организации. Он может упростить контроль доступа и обеспечить автономию для разных команд. Однако он может потребовать от пользователей переключения между разными интерфейсами для поиска между приложениями.
Единый центральный веб-сайт: единый центральный веб-сайт для доступа ко всем журналам обеспечивает унифицированный вид всей инфраструктуры журналов, что упрощает поиск между приложениями. Такой подход упрощает доступ пользователей, но может потребовать более надежного контроля доступа и управления разрешениями для обеспечения разделения данных между различными командами или приложениями.
В конечном итоге выбор между этими подходами зависит от приоритетов вашей организации в отношении изоляции, простоты использования, управления ресурсами, а также конкретных требований ваших приложений и групп.
Чтобы найти сбалансированное решение, которое подойдет всем, примите во внимание следующее:
- Реализуйте строгие политики ограничения скорости и регулирования в каждом экземпляре Graylog, чтобы предотвратить перегрузку системы вредоносными приложениями.
- Отслеживайте и оповещайте об использовании ресурсов и производительности во всех экземплярах Graylog для заблаговременного обнаружения и устранения проблем.
- Документируйте и доносите до всех команд передовой опыт управления и использования журналов.
- Продолжаем изучать возможность создания централизованного решения Graylog с надлежащим масштабированием ресурсов и механизмами контроля доступа.
В целом, наилучший подход может включать комбинацию. Вы можете обнаружить, что используете отдельные экземпляры Graylog для логических групп приложений, внедряя надежные методы управления ресурсами и мониторинга для обеспечения общей стабильности вашей инфраструктуры управления журналами. Также важно вовлекать заинтересованные стороны из разных команд в процесс принятия решений, чтобы гарантировать, что выбранное решение соответствует их потребностям и ожиданиям, просто предложение, чтобы предотвратить проблемы wiggity wiggity wiggity wack, понимаете? ;)
решение2
Большим преимуществом Graylog (и аналогичного продукта) является не изолированное хранение журналов, акорреляция между различными источниками журналов и зарегистрированными событиями.При использовании нескольких отдельных серверов Graylog, каждый из которых собирает данные из разных источников, корреляция между несколькими источниками становится намного сложнее.
Я бы предложил использовать один сервер Graylog (или кластерную многоузловую установку, если одного узла недостаточно) и несколько определенных индексов с разными (и подходящими) политиками ротации. Вы можете направлять трафик на эти индексы через соответствующиеПравила трансляции(и выбрав «Удалить совпадения из потока по умолчанию»).