The other thing that concerns me about these systems is when some library ( #log4j for example ) has a security vulnerability. If your software is locked up inside of these containers, that means each one will need to publish an update and get you to download it when it could all be updated at once with your system updater.
Deavmi releases DLog, a logging library for #DLang. Hopefully, he's taken care not to do things the way #Log4J does. I mean, there are several log4* projects that use a similar API, but AFAIK, only the Java library is causing these problems right now. So #DLog could probably serve as the Log4D equivalent without having all the same flaws.
Believed affected: * cloud platforms
* enterprise applications ( which are often written in #Java )
* Minecraft ( which was where the #log4j flaw was discovered )
* #Android apps ( noted by @clacke )
Possibly, other "log4" libraries may have a similar flaw.
Here’s the message:
2021-06-08 17:05:50 +0800 [warn]: #0 dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error=“400 - Rejected by Elasticsearch [error type]: mapper_parsing_exception [reason]: ‘failed to parse field [message] of type [text] in document with id ‘fPHe6nkBSuYtlT3W3H56’. Preview of field’s value: ‘’’” location=nil tag=“app.was-aiahk-intranet-prod-aiab-app1-SystemOut” time=2021-06-08 17:05:14.438022000 +0800 record=
{“message”=>"[6/8/21 14:37:39:438 CST] 000000f6 SystemOut O {call bunch of nulls and some sensitive data,‘CANTONESE’)}
I can’t tell at what point it is being recognized as Cantonese. Maybe that’s a metadata field. They gave what they claim is a fluentd config, but it doesn’t mention anything about character encoding. I’m waiting for their #log4j config.
In any case, I told him the answer in my first response, he just didn't like it. I mean, #log4j may well be a better longterm solution for them, but it doesn't do exactly what they asked like my first response.