A single microservice for collecting / storing all logs, is that right?

Question

Node.js

Good afternoon.
I have a microservice architecture.
Reached the moment of logging, which option is better for you?
Option 1: All logs are sent to one microservice.
Option 2: Each microservice writes its own logs in its storage.

Answer 1

Option 1: All logs are sent to one microservice.

All logs are sent to the log aggregator, not the microservice. Writing a microservice for working with logs for yourself is an extra job, since now there are ready-made tools.
But how to do it - there are already different options.
Your application can write to stdout, and if you use something like kubernetes / openshift, then it is convenient to catch it centrally immediately on the cluster, tag it by the name of the application / pod and send it further.
Your application can directly write logs to some logstash, which parses everything and sends it further
Your application can write logs to the message broker, from which the logs are already sent to the aggregator. It is useful if there are very large peaks of logs and there is a possibility that the aggregator may not be able to cope at some point and part will be lost - then some kafka/rabbitmq thread will just be an intermediate buffer that is guaranteed to receive all the logs, no matter how many there are and will pass them on at a rate that your log aggregator is comfortable with (scaling a broker is easier than an aggregator)
Your application can write logs directly to the database. Even in sql base, or directly in elastic.
Your application can simply write to log files, and then these log files are collected, parsed, sent to the log aggregator.
In general, for every taste and color. Decide on the volume of logs, peak times, what you want to do and make a common standard for all your components.

Option 2: Each microservice writes its own logs in its storage.

Well, maybe so.