слать напрямую в ElasticSearch аудит логи. Какие могут быть риски ? Вообще я чувствую, мне хотелось бы заюзать как то nginx тут и просто проксировать траффик на еластиксерч, возможно на уровне нжинкс можно сделать какой то редирект трафика в бэкграунд режиме ? А сервера, которые за апи отвечают хотелось бы освободить от такой работы
а почему они могут не попасть в эластик ?
мне предложили тут в другом чате - слать на некий сервер с rsyslogом, и уже рсислог будет слать логи - степ бай степ на эластиксерч
В таком случае всё преимущество слания логов прямо в эластик пропадает. Какой смысл изобретать велосипед, когда есть стандартная архитектура логирования? Пусть отдают логи в stdout, а оттуда их заберёт ваш дистрибьютор (fluentbit, promtail или что там у вас)
это специальные логи, аудит-логи работы приложения, это не типа - пришел запрос, ушел запрос, это как раз уходит в stdout
потому что их то как раз и надо записывать в elastic search, все остальное хранится на cloudwatch через амазоновские тулзы. а именно аудит логи - нужно писать в ES
Такое обычно настраивается на стороне системы логирования. Всякие promtail'ы собирают все логи приложения и отправляют их в какой-нибудь дистрибьютор типа vector или fluentbit, где есть такая стадия как Transform. Там уже можно и кастомные лейблы навешивать и выбирать, какие логи куда будут отправляться. Там же можете разделить, чтобы аудит логи шли в эластик, а сервисные в амазон
чтобы что? Какова цель и почему нельзя просто бит положить?
Обсуждают сегодня