I like the idea that for each log event fblog displays a main line and optional additional lines per field. However, succinctness is also a virtue. Three lines to display message + logger name + thread name is a significant waste of vertical space. Thus, I had like to be able to cram more info into the main line.

jaslog, a similar project, includes logger and thread name, https://github.com/jbruggem/jaslog/blob/master/src/line_formats.rs#L76. It seems a reasonable decision, but I imagine that essential fields are context dependent and every user has its personal opinion about what to display in the main line.

Would it make sense to:

1. Add more fields to the main line
2. Provide a configuration mechanism to decide what, and perhaps how, to display in the main line

Sorry to bother you again. This happens when you pipe to less and then quit, like so (bash):

> fblog -d huge-log.json | less -r
# now press `:q` to quit less
thread 'main' panicked at 'Expect to be able to write to out stream.: Os { code: 32, kind: BrokenPipe, message: "Broken pipe" }', src/log.rs:100:7
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

I don't think that it's a problem, but it doesn't look nice.

Hey, this was useful for me so I opened this PR.

-x (eXclude values) enabled --dump-all and remove specified values.

I tested it locally and it works fine for me. Attaching a picture of the help.

Hi, thank you for the useful tool! I have an issue with using the flag "--additional-value".

I'm using fblog v3.0.2 built by myself using Cargo and source code.

The output of execute $ fblog --help:

fblog 3.0.2
Brocode inc <[email protected]>
json log viewer

USAGE:
    fblog [FLAGS] [OPTIONS] [--] [INPUT]

...

The problem is that the output does not contain the field I specified using the flag -a.

I have the log message:

{"time": "2021-11-08T13:55:45.924593+00:00", "level": "INFO", "caller": "/app/service/runner.py:58", "message": "Some message here", "process": "1", "thread": "MainThread", "function": "run", "line_no": "58", "module": "runner", "logger": "service.runner", "extra": {"a": 1}}

I want to see a value of the key "extra", so i'm using fblog -a extra and it doesn't work. At the same time, if I use the command fblog -a module, the value of the key module is displayed correctly.

Please help me figure out what I'm doing wrong, or confirm that this is a bug.

Whe I use fblog - https://github.com/brocode/fblog/releases/download/v2.1.0/fblog.deb deb packaged version, It works greatly.

But if I install with cargo install fblog, fblog print HTML escaped message.

What's the difference?

I have a json file that I have to pre-process via jq after that run I end up in pretty printed (multiline) json. Feeding this into fblog causes some strange errors, example below:

the json fed into fblog looks like (excerpt):

{
  "@message": "[object Object]\nResponse Headers have already been sent",
  "@timestamp": "2021-05-05T11:00:42.627Z",
  "@fields": {
    "level": "error"
  }
}
{
  "@message": "[object Object]\nResponse Headers have already been sent",
  "@timestamp": "2021-05-05T11:01:13.650Z",
  "@fields": {
    "level": "error"
  }
}

This very json ends up like this:

$ cat *json* | grep -v 'info' | grep -v 'debug' | jq '.log | fromjson ' | fblog

??? > {
??? >   "@message": "[object Object]\nResponse Headers have already been sent",
??? >   "@timestamp": "2021-05-05T11:00:42.627Z",
??? >   "@fields": {
??? >     "level": "error"
??? >   }
??? > }
??? > {
??? >   "@message": "[object Object]\nResponse Headers have already been sent",
??? >   "@timestamp": "2021-05-05T11:01:13.650Z",
??? >   "@fields": {
??? >     "level": "error"
??? >   }
??? > }

besides the json keys not fitting the default of fblog (that can be fixed via -l | -m | -t) the whole multiline json topic seems to be the root cause.

Does fblog expect single line json?

fblog -f 'method=="POST" and header.X-Customer-Id[1]=="123456"' -a body -a res_body req.log

{
  "header":{
      "X-Tenant-Id": ["123456"]
  }
}

Sometime fblog does not parse number values(but sometime do).

$ cat > x.json
{"timestamp":"2020-09-17 07:11:54.936","@version":"1","message":"Done Good!. exitCode: 0","thread":"main","level":"INFO","caller_file_name":"MyApplication.java","caller_line_number":12345}

$ cat x.json | .cargo/bin/fblog --main-line-format "{{fblog_timestamp}} {{level_style fblog_level}} [{{thread}}] ({{caller_file_name}}#{{caller_line_number}}) {{fblog_message}}"

# there is no number 12345
2020-09-17 07:11:54.936 INFO [main] (MyApplication.java#) Done Good!. exitCode: 0

# the result I expected
2020-09-17 07:11:54.936 INFO [main] (MyApplication.java#12345) Done Good!. exitCode: 0

First of all, thanks for this tool! I had an idea to make this for myself and was pleasantly surprised to find this already existed. :smile:

I was wondering if it would be possible to add support to pull default configuration from a config file somewhere like ~/.config/fblog/fblog.toml, or somewhere similar, and maybe the ability to provide a config path on the command line? Our logs have a few fields that don't make sense to add as auto-detected fields but are still helpful to show when they come up. Including those by default from a config file would allow me to set up some defaults without needing to remember (or type) them every time.

Thanks again!

Would you consider implementing no-color?

I could create a PR if you did.

I ran into this while trying to pipe fblog output through less and getting something not as friendly

ESC[1m2020-03-02T22:45:22ESC[0m ESC[1;31mERROR:ESC[0m Failed to send sms
ESC[1;38;2;150;150;150m                     body:ESC[0m ID: 19169 Status: 1
ESC[1;38;2;150;150;150m                     file:ESC[0m my/path/file.go:194
ESC[1;38;2;150;150;150m                     func:ESC[0m other/path.monitorMsgID
ESC[1;38;2;150;150;150m                    level:ESC[0m error
ESC[1;38;2;150;150;150m                      msg:ESC[0m Failed to send sms
ESC[1;38;2;150;150;150m                  request:ESC[0m http://localhost/query
ESC[1;38;2;150;150;150m                     time:ESC[0m 2020-03-02T22:45:22Z
ESC[1m2020-03-02T22:45:22ESC[0m ESC[1;31mERROR:ESC[0m Failed to send sms
ESC[1;38;2;150;150;150m                    error:ESC[0m [{other/path/file.go:103: } {other/path/file.go:190: Failed to send sms}]
ESC[1;38;2;150;150;150m                     file:ESC[0m my/path/file.go:106
ESC[1;38;2;150;150;150m                     func:ESC[0m other/path.(*smsClient).Send
ESC[1;38;2;150;150;150m                    level:ESC[0m error
ESC[1;38;2;150;150;150m                      msg:ESC[0m Failed to send sms```

Last year elastic introduced elastic common schema. Basically, it is a syntactic and semantic convention for structured logging.

This patch add support of ECS time (@timestamp) and level (logger.level) fields. Message is already fine.

Other alternative fields were untested so I didn't add an unit test.

$ cat /tmp/test4
{"@timestamp":"2020-02-24T11:34:38.483Z", "log.level": "INFO", "message":"My message", "process.thread.name":"main","log.logger":"com.greencomnetworks.poc.Removeme","container.id":"thinkpad","service.type":"test","service.version":"N/A"}
$ cargo run /tmp/test4 
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/fblog /tmp/test4`
2020-02-24T11:34:38  INFO: My message

Bumps clap from 4.0.29 to 4.0.32.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.