Comments 4
Подскажите, пожалуйста, а как вы бы порекомендовали организовать настройку Splunk для следующего сценария:
- Есть один Splunk на несколько команд
- У каждой команды — один или несколько индексов
- Иногда одной из команд необходимо сделать изменения в настройках (т.е. inputs.config и пр.), однако прямой доступ к конфигурации выдавать опасно.
Т.е. с одной стороны команды должны иметь возможность настраивать то, какие логи собираются. С другой стороны, прямой доступ к конфигурации давать опасно. И с третьей стороны — для упрощения процесса, в идеале сделать так, чтобы команда таки сама настраивала маски к собственным файлам для сбора.
[Я к Splunk никакого отношения не имею]
А не используйте файлы вообще — коннектитесь к Splunk напрямую. Откройте несколько портов, каждому назначьте свой индекс и дуйте туда напрямую. Мы так log4cxx и log4net настроили (правда с кастомным TCP appender'ом, поскольку только UDP из коробки у них).
А не используйте файлы вообще — коннектитесь к Splunk напрямую. Откройте несколько портов, каждому назначьте свой индекс и дуйте туда напрямую. Мы так log4cxx и log4net настроили (правда с кастомным TCP appender'ом, поскольку только UDP из коробки у них).
1. Если используете форвардеры без Deployment Server или с ним:
На форвардерах в каталоге local приложений команды смогут сохранять свои конфиги inputs.conf. Эти конфиги имеют приоритет над системными.
2. Можно использовать HttpEventCollector для сбора логов, тогда вы выдадите командам токены, которые они будут использовать.
3. Можно забирать у команд фильтры для inputs.conf из заранее огороворенного места (github, bitbucket), где будет храниться не только нужная информация, но и вся история изменений.
На форвардерах в каталоге local приложений команды смогут сохранять свои конфиги inputs.conf. Эти конфиги имеют приоритет над системными.
2. Можно использовать HttpEventCollector для сбора логов, тогда вы выдадите командам токены, которые они будут использовать.
3. Можно забирать у команд фильтры для inputs.conf из заранее огороворенного места (github, bitbucket), где будет храниться не только нужная информация, но и вся история изменений.
Правильный ответ: доверяйте своим коллегам (позволяйте им ошибаться) И проектируйте систему так, чтобы можно было откатиться быстро в случае человеческой (или любой другой) ошибки
Sign up to leave a comment.
Splunk 7.0. Что нового?