Replies: 1 comment
-
@amosshi, thanks so much for sharing this feedback.
Would you mind sharing a little bit more detail about your deployment setup, please? I presume you don't have a log ingestion system, e.g., ELK, in this particular case, but plain files storing JSON one-liners. Do you have file compression enabled, and yet still observe significant improvement after switching to single-character setup? Have you considered using custom layouts (e.g., SMILE-encoding) or compression-enabled solutions (e.g., YScope's CLP Appender)? If yes, where do they fall short? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
In the document it reads:
In our current settings, we do use pattern for the log
level
, which generates only 1 character to save disk space, and somewhat readable, likeI
for INFOW
for WARNE
for ERRORIn today's JSON Template Layout, we do have another option of
severity / code
, which will generate a number for level based on Syslog severity, like6
for INFO4
for WARN3
for ERRORWell it is clear the
severity code
(4, 5, 6) is NOT reader friendly and we need a mapping to make it readable.The Request
single character level
Beta Was this translation helpful? Give feedback.
All reactions