Единый микросервис для сбора/хранения всех логов, правильно ли это?
1 вариант: Все логи отправляются в один микросервис.
Все логи отправляются в лог аггрегатор, а не микросервис. Писать для себя микросервис по работе с логами - лишняя работа, так как сейчас есть готовые инструменты.

А вот как это делать - уже разные варианты есть.

Ваше приложение может писать в stdout, и если вы пользуетесь чем-то вроде kubernetes/openshift, то это удобно ловить централизировано сразу на кластере, тегировать по имени приложения/пода и отправлять дальше.

Ваше приложение может напрямую писать логи в какой-нибудь logstash, который все собирает парсит и отправляет дальше

Ваше приложение может писать логи в брокер сообщений, из которого уже логи попадают в аггрегатор. Полезно если бывают очень большие пики логов и есть вероятность, что аггрегатор может в какой-то момент не справитьcя и часть потеряется - тогда какой-нить kafka/rabbitmq как раз будет промежуточным буффером, который гарантировано примет все логи, сколько бы их ни было и передаст их дальше со скоростью, которая комфортна для вашего лог аггрегатора (масштабировать брокер проще, чем аггрегатор)

Ваше приложение может писать логи прямо в базу данных. Даже в sql базу, или прямо в elastic.

Ваше приложение может писать просто в лог файлы, а потом эти лог файлы собираются, парсятся, отправляются в лог аггрегатор.

В общем на любой вкус и цвет. Определитесь с объемом логов, с пиковыми моментами, с тем что вы хотите делать и сделайте общий стандарт для всех ваших компонентов.

2 вариант: Каждый микросервис пишет собственные логи в своем хранилище. 
Ну можно и так.
1 вариант.
log4js (type = logstash udp) и далее все логи улетают в одно хранилище.
Хорошая статья (для java, но я выше написал про js) вот тут Учимся готовить Log4j + Logstash + ElasticSearch +...