{"id":44754452,"url":"https://github.com/gbataille/logs_for_humans","last_synced_at":"2026-02-15T23:35:53.560Z","repository":{"id":57661685,"uuid":"471904121","full_name":"gbataille/logs_for_humans","owner":"gbataille","description":"log stream formatting for human consumption","archived":false,"fork":false,"pushed_at":"2022-04-10T06:26:54.000Z","size":261,"stargazers_count":4,"open_issues_count":0,"forks_count":1,"subscribers_count":3,"default_branch":"main","last_synced_at":"2024-06-20T16:42:23.192Z","etag":null,"topics":["logging","logs"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/gbataille.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2022-03-20T07:02:25.000Z","updated_at":"2023-07-07T14:58:47.000Z","dependencies_parsed_at":"2022-09-06T01:31:20.693Z","dependency_job_id":null,"html_url":"https://github.com/gbataille/logs_for_humans","commit_stats":null,"previous_names":["gbataille/zap_log_prettier"],"tags_count":6,"template":false,"template_full_name":null,"purl":"pkg:github/gbataille/logs_for_humans","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gbataille%2Flogs_for_humans","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gbataille%2Flogs_for_humans/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gbataille%2Flogs_for_humans/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gbataille%2Flogs_for_humans/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/gbataille","download_url":"https://codeload.github.com/gbataille/logs_for_humans/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gbataille%2Flogs_for_humans/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29492793,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-15T23:34:01.544Z","status":"ssl_error","status_checked_at":"2026-02-15T23:33:27.984Z","response_time":118,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["logging","logs"],"created_at":"2026-02-15T23:35:51.149Z","updated_at":"2026-02-15T23:35:53.552Z","avatar_url":"https://github.com/gbataille.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Logs for Humans\n\nModern applications tend to log in a verbose manner and in a structured manner (JSON) for ingestion\nin log browsing tools like the ELK stack.\n\nThis is all well and good, but there are 2 use cases where it's not practical\n1. When developing the application. You want to be able to run it locally and, as a human, read the\n   logs.\n1. When you receive a log file (from a client for example) and have to make sense out of it.\n\nA JSON log is not easy to parse, especially when it starts to get verbose\n\n# Why another tool?\n\nThere are a few low tech solutions to think about before adding yet another tool to your setup:\n\n## Configure the logger\n\nYour application logger can certainly be configured to log as text rather than JSON. But then\n- either you print only the log `msg` field and miss all the metadata, hoping that the `msg` field\n  is enough and contain everything needed\n- or you log all the fields, just not in JSON, which improves the situation but not by much\n- and it does not help pinpoint the important information out of verbose logs\n- and it does nothing for log files that you might want to read post facts.\n\n## Use grep\n\nThis really only works on pre-existing log files and not on logs being printed live. Plus you have\nto know what you are looking for and search something simple or be a master at regex which is\ncumbersome\n\n## Use jq\n\nThat was actually my first attempt, with expressions that would extract the important parts like the\ntimestamp, the level and the message. But realizing the message was not enough, I tried to get also\nall the rest. I ended up with such an expression\n```shell\njq -R -r \". as \\$line | try (fromjson | \\\"[\\\" + .ts + \\\"][\\\" + (.level | ascii_upcase) + \\\"] \\\" + (if has(\\\"error\\\") then (.error + \\\" - \\\") else \\\"\\\" end)  + .msg + \\\" \\\" + (.block_number? | tostring) + \\\" (\\\" + .caller + \\\")\\\" + \\\"\\\\n\\\\t\\\" + (\\$line|fromjson|del(.msg)|del(.ts)|del(.caller)|del(.level)|del(.block_number)|tostring)) catch \\$line\"\n```\n\nThis is hard to maintain and this actually did not do the work I wanted (i.e. it still was not readable\nenough for me)\n\n# Design requirements\n\nSo I wanted a tool that would\n- **Process STDIN:** This would allow to both stream running application logs through it with a\n  shell pipeline, or dump an existing log file into it with `cat` and a pipeline.\n- **Highlight log level:** to spot instantly the most important things (ERROR) and tune down the\n  lesser lines (DEBUG)\n- **Highlight the main information:** make sure that the log message is not lost in the middle of\n  all the log details\n- **Align log lines:** logs typically all have a level, a timestamp and a message. Be sure those are\n  aligned to increase log readability\n- **Be rugged:** since it's meant to be used in a shell pipeline, it should not crash on unexpected\n  input and be able to handle anything going through it.\n\n# Solution\n\nThe solution relies heavily on the excellent [pterm](github.com/pterm/pterm) library.\n- Each log level uses a different color\n- Log level and timestamp start the line\n- Log message follows and uses the same color which makes it pop-out with respect to the rest\n- Then comes the log \"sender\" (typically the file location sending the log line) in a whithish color\n- And finally all the other log fields, in a \"backgroundish\" color so that they are less prominent.\n\n**BEFORE**\n![before](./doc/images/before.png)\n\n**AFTER**\n![after](./doc/images/after.png)\n\n\n# Installation\n\n```bash\ngo install github.com/gbataille/logs_for_humans@latest\n```\n\n# Usage\n\n```bash\n./my_application | logs_for_humans\n```\n\nor\n\n```bash\ncat ./my_log_file | logs_for_humans | less\n```\n\n# Limitations\n\nThis tool is very much a work in progress, so a lot of things are a bit raw.\n\nIn particular, it's at the moment not configurable, meaning it only properly recognized logs that\nhave\n- a `level` key, with values in `\"error\", \"fatal\", \"warn\", \"warning\", \"info\", \"debug\"` (case\n  insensitive)\n- a `ts` key with a unix timestamp in seconds\n- a `msg` key with the main log message\n- preferably a `caller` key with the message source\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgbataille%2Flogs_for_humans","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fgbataille%2Flogs_for_humans","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgbataille%2Flogs_for_humans/lists"}