Show HN: A Better Log Service

Show HN: A Better Log Service(txtlog.net)

153 points by williebeek 1 year ago | 91 comments

Hello everyone, there are many log services available and this is my attempt at a better one.

Most online logging tools feature convoluted UIs, arbitrary mandatory fields, questionable AI/insights, complex pricing, etc. I hope my application fixes most of these issues. It also has some nice features, such as automatic Geo IP checks and public dashboards.

Although I've created lots of software, this is my first open source application (MIT license), the tutorial for selfhosting is hopefully sufficient! Most of my development career has been with C#, NodeJS and PHP. For this project I've used PHP (8.3) which is an absolute joy to work with. The architecture is very scalable, but I've only tested up to a few billion logs. The current version is used in production for a few months now. Hope you enjoy/fork it as you see fit!

hk1337 1 year ago |

It's a minor thing but I would remove the jQuery dependency. You're not doing much with that plain javascript couldn't do just as well if not better. Plain JS has come a long way since jQuery first came out.

piterrro 1 year ago |

> there are many log services available and this is my attempt at a better one.

Out of curiosity, can you describe how your service is better than others?

>I hope my application fixes most of these issues

Do you care to elaborate on the "how"?

adriand 1 year ago |

I’m curious about the open source nature of this and how you / people in general manage a project where you are hosting it and need to maintain its security, but are also presumably merging pull requests as people contribute to the project. I would be quite paranoid about this, ie concerned that someone might slip a line of code in with the intent of breaching the service that I would not catch during code review. I know this is true of any open source project but it feels especially fraught when you are also hosting it and letting people sign up and pay for it. I’m wondering if you or others have experience with this and what approaches and practices mitigate this risk.

gabeio 1 year ago | |

Just because a project is “open source” doesn’t actually mean you must accept or even merge PRs from others. After reading others pointing this out my opinion of managing open source projects have significantly changed. Of course, you can entertain PRs and see if the idea behind them is sound but not accept the raw code from others and implement the features they way you envision instead. Keep in mind it’s always possible to have a vulnerability without anyone else’s assistance. This is especially true if you use dependencies, as you don’t keep track of every line of code they add.

withinboredom 1 year ago | | |

> This is especially true if you use dependencies, as you don’t keep track of every line of code they add.

You absolutely should vendor your dependencies and review them before accepting the new version. Even though they are dependencies, you are ultimately responsible for using them. "They are just dependencies" doesn't absolve you of responsibility.

skeeter2020 1 year ago | |

For users of OS projects, a very common approach is to clone into a private repo, then only pull upstream changes within your own timeline/process, and potentially open public PRs at some point after working in private, i.e. you do your business in private, and share in the public part as & when works. For the project maintainer people can open PRs whenever they want but you are under no obligation to accept them or use any of the code; they're doing this to help others but don't need to for their own scenario.

TripleChecker 1 year ago |

It looks like that's a PHP codebase. I'm curious why one should use this solution instead of more performant Go/Rust log backends?

Also, one of the login links takes you to a 404 page: https://triplechecker.com/s/jDTmQa/txtlog.net

giraffe_lady 1 year ago | |

They said

> Most of my development career has been with C#, NodeJS and PHP

and then

> The architecture is very scalable, but I've only tested up to a few billion logs.

dobin 1 year ago |

Pretty unrelated, but i like how it displays large amount of potentially diverse JSON events. Would need some better filtering and sorting, hiding of keys etc. Products which do this well are Elastic and Splunk, but are too heavy for my taste.

szundi 1 year ago | |

I always played with the idea that the logs could be viewed as packets of some protocol and use wireshark to filter them and view related logs as a “stream” like view that wireshark provides

nesarkvechnep 1 year ago |

Some people praised Go as a better language for the use case than PHP. I’d say Elixir is even better. It can handle massive concurrency easy, can be made distributed easy, has a built-in, in-memory, key-value store (ETS), and is probably the best high-level language for anything that’s facing the network.

lukevp 1 year ago | |

I've really been interested in learning more about Elixir and how it accomplishes these things, because I constantly hear the same opinions from others. Do you have some good resources you'd recommend for getting started with Elixir for a principal engineer that wants to understand these at-scale issues and how Elixir solves them better than other languages?

nesarkvechnep 1 year ago | | |

Yes, two books. To get a feel for the language - “Elixir in Action” by Sasa Juric. To discover how Elixir and the platform it’s built on excel in scalability and fault-tolerance - “Designing for Scalability with Erlang/OTP” by Francesco Cesarini.

mdaniel 1 year ago |

What in the world does this mean? https://txtlog.net/doc#:~:text=use%20your%20local%20time%20w... That's made twice as bad by the "we throw away Z because you were just kidding by including it". That leads me to believe that any RFC 3339 that isn't automatically Z (e.g. 1996-12-19T16:39:57-08:00 <https://datatracker.ietf.org/doc/html/rfc3339#section-5.8>) is ... well, I don't know what it's going to do but it likely won't be good

It also appears that your documentation is currently a very verbose version of an OpenAPI spec, so you may save your readers some trouble by actually publishing one, with the added advantage that they come with a "Try it" button in the OpenAPI renders

That would allow you to save the natural language parts for describing things that are not API-centric (such as the "but WWWWHHHHYYY mysql AND clickhouse" that you alluded to elsewhere but wasn't mentioned at all in /doc nor /selfhost)

thomquaid 1 year ago |

the 'easy to use' / 'view' was very nice. if you could add the actual session logs in it would be amazing.

rednafi 1 year ago |

This is nice.

At work, we use Datadog for logging, and I have previously used CloudWatch, Splunk, and Honeycomb. Among these, only Honeycomb makes implementing canonical log lines [1] easier. I want arbitrarily wide, structured logs [2] without paying exorbitant costs for cardinality.

Our Datadog costs are outrageous, and it seems like no one cares at this point. Pydantic Logfire is also doing some good work in Python-specific environments. I use both Python and Go, but Logfire wasn’t as ergonomic in Go.

[1]: https://stripe.com/blog/canonical-log-lines

[2]: https://www.honeycomb.io/blog/structured-events-basis-observ...

valyala 1 year ago | |

Try VictoriaLogs [1]. It supports wide events with hundreds of fields (aka canonical logs).

[1] https://docs.victoriametrics.com/victorialogs/

reacharavindh 1 year ago |

My current log solution that is based on Clickhouse I’m tinkering with in free time in Victorialogs. https://docs.victoriametrics.com/victorialogs/

bdcravens 1 year ago |

Very nice. A lot of the complexity you described is why I've settled on using CloudWatch logs for anything I have on AWS. I don't need a fancy UI, just a powerful querying language for investigation and debugging. With that said, it would be nice to see at least some mechanism for building aggregates queries (for example, 4* results in the last 24 hours by user) but if it's ClickHouse underneath, I assume that's easy using standard ClickHouse tools.

stingraycharles 1 year ago | |

I hate how Cloudwatch itself is so fragmented, and they have three different query languages for logs.

It’s all cognitive overhead I don’t want to learn.

bdcravens 1 year ago | | |

I will say that the language isn't the most intuitive, and a project like this one with some simply querying with the (presumed) ability to drop down to SQL for power use is probably the ideal solution. (Doable with CloudWatch logs and Athena, but that's another can of complex worms)

infecto 1 year ago | | |

I would be happy to pay a premium for a better cloudwatch. For me it is always not intuitive which I am sure is driven by limited use.

majkinetor 1 year ago |

We need glorified (rip)grep instead of ELKS and friends, which have huge learning curve. I welcome this effort.

remram 1 year ago | |

I'm pretty satisfied with Loki. It just ingests the logs and offers a powerful query language to extract data at query time (e.g. parse JSON, run regexes, plot). It can store data in a local folder or S3-compatible storage. I also gave up on configuring ELK in the past...

ptman 1 year ago | | |

VictoriaLogs is similar, but a nice improvement over Loki

toabi 1 year ago | | |

I moved from an ELK stack to Loki and it's sooooo much easier/better/just-works.

leeoniya 1 year ago | | |

yep, loki is basically "distributed grep"

valyala 1 year ago | |

If you like grep, you'll like https://docs.victoriametrics.com/victorialogs/querying/#comm...

drchaim 1 year ago |

Don't tell me why, but I've developed an instinct that recognizes solutions that use Clickhouse under the hood :)

stingraycharles 1 year ago | |

Seems to be using MySQL instead?

https://github.com/WillieBeek/txtlog/blob/master/txtlog/data...

HatchedLake721 1 year ago | |

Tell us more!

williebeek 1 year ago | | |

It uses both, MySQL for the metadata and ClickHouse for the logs. The selfhost page explains a bit more about the architecture.

edit: the connection to ClickHouse uses the MySQL driver, this is actually a very nice CH feature, you can connect to CH using the regular mysql or postgresql client tools. The PHP MySQL PDO driver works seamlessly. One catch, using advanced features like CH query timeouts requires a CTE function, check the model/txtlogrowdb.php file if you're interested.

mooreds 1 year ago |

I've heard good things about Axiom[0], especially for high scale needs.

0: https://axiom.co/

mdaniel 1 year ago | |

If you like them, please submit the link on its own, and not to take away from someone's MIT "Show HN" to plug a non open source project

mooreds 1 year ago | | |

Fair enough. Thanks for the feedback.

theogravity 1 year ago | |

I added support for it just now because of this comment. Had it on my list of things to integrate with since I saw the comment. Thanks!

https://loglayer.dev/transports/axiom.html

that_guy_iain 1 year ago |

This looks very interesting!

My suggestion for the self-hosting is to create docker images and use docker-compose. The self-hosting currently is a bit of effort to setup.

I also wonder if PHP is a good language for this. For the UI, yea that's fine and makes sense. But for the log processor that's going to need to handle a high throughput which PHP just isn't good at. For the same resources, you can have Go doing thousands of requests per second vs PHP doing hundreds of requests per second.