Lots of log messages in production

[eduhenke]

Sometimes it happens that I receive an ES indexing error in production. When that happens I get bombarded with a ton of error messages about the indexing error, coming from this line: https://github.com/vanthome/winston-elasticsearch/blob/9111f401b95288233c0908423fb68efb5e6291d0/bulk_writer.js#L141

I don't understand why that's necessary, we have the debug line above it, if I'm interested in checking out why some messages are not being indexed, I can simply pass an environment variable.

But right now, I don't think I have a way of turning this error message off, right?

[vanthome]

No, you cannot turn this off, as it's a kind of last resort logging. What kind of indexing error do you get? Is that error even expected in your case?

[eduhenke]

It was about a "dynamic mapping error", in which a field I was logging, was already mapped in that index but with a different type, and If I recall correctly there was another class of errors.

But nonetheless, all my logging is done via winston, in which I can control which log levels and to where I want my log to go.

When it's simply being done via console, I can not control that, and the error logs are not on the place I expect them to be, plus I can not rate limit them, which is something I do on the winston logger.

I simply wouldn't like to someday see my Google Cloud billing report, and see that I've logged millions and millions of entries(the indexing errors happen proportionally to the number of requests my server handles) about not correctly naming a log field(also correct me if I'm wrong, but that part of the code has a fixed number of retry attempts, which is 400? which kind of multiplies those log entries by 400).

I think a better solution would be to make the library user choose what to do when an error happens, if they would like them to be logged, and how. What do you think?

[vanthome]

I know this kind of error and I would consider this a severe issue as you are effectively losing log data. We can't however log internal errors to ES as this is out of band data. So the last resort is to log it on the console.

I agree, I will introduce an option whether last resort logging should be conducted or not.

[eduhenke]

Maybe not disabling the last resort logging, but rather passing a callback to handle that error?

I may for example choose to call Elastic APM to capture that error.

[vanthome]

Created a new release with the new option internalLogger. Please test it and reopen the issue if it does not work.

[Adizbek]

@vanthome Still ~ 400 message

[vanthome]

This bug is not about a lot of messages, this bug is about being able to override the last resort logger. So open a new issue and explain it.

[eduhenke]

@vanthome forgot to reply, but it worked nicely! thanks. only the typing for the internalLogger was not set, I had to do a //@ts-ignore