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
[deleted]
Show HN: A Better Log Service
101–109 of 109 posts
Re: Show HN: A Better Log Service
#102Earlier quoted context omitted.
What you're talking about is generally not considered production-ready. While you can use these tools you will almost certainly run into problems. I know this because as an active PHP developer for over a decade I'm very much paying attention to that field of PHP. What we see here is a classic case of benchmarks saying one thing when the reality of production code says something else. Also, I used go as a generic exa…
Nobody is suggesting PHP beats compiled. We’re arguing with you about your utter lack of expertise in the language, knowledge of the ecosystem and “production-ready” status of the many options, and your overall coding ability when it comes to PHP.
> Nobody is suggesting PHP beats compiled.
Actually, there seems to be people arguing that.
> We’re arguing with you about your utter lack of expertise in the language, knowledge of the ecosystem and “production-ready” status of the many options, and your overall coding ability when it comes to PHP.
If you're doing that with benchmarks you're doing a shitty job. My numbers came from experience in production environments with production workloads.
Not to mention that you're talking experimental tooling as examples. I've literally seen multiple companies try to use FrankenPHP. Not one even made it to QA aka it broke because during the dev testing.
Re: Show HN: A Better Log Service
#103This 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 tho…
PHP trivially scales up to multiple nodes behind an LB. You're really only limited by your backend storage connection count and throughput. Go and friends may make for more efficient resource utilization, but it will be marginal in the grand scheme of things unless there are plans to do massively different things. As it is this code is very simple. I haven't used PHP in 15 years and I was able to trace through this f…
You can but that costs more money...
> Keep it up, OP.
Live in the real world. No one wants to have a fleet of servers for their logging infra when there are options to run it on a single server.
Re: Show HN: A Better Log Service
#104Re: Show HN: A Better Log Service
#105Earlier quoted context omitted.
Nobody is suggesting PHP beats compiled. We’re arguing with you about your utter lack of expertise in the language, knowledge of the ecosystem and “production-ready” status of the many options, and your overall coding ability when it comes to PHP.
> Nobody is suggesting PHP beats compiled. Actually, there seems to be people arguing that. > We’re arguing with you about your utter lack of expertise in the language, knowledge of the ecosystem and “production-ready” status of the many options, and your overall coding ability when it comes to PHP. If you're doing that with benchmarks you're doing a shitty job. My numbers came from experience in production environme…
Again, you don't have the slightest clue what you're talking about. There are numerous production-ready choices that myself and others have mentioned.
Re: Show HN: A Better Log Service
#106Earlier quoted context omitted.
What you're talking about is generally not considered production-ready. While you can use these tools you will almost certainly run into problems. I know this because as an active PHP developer for over a decade I'm very much paying attention to that field of PHP. What we see here is a classic case of benchmarks saying one thing when the reality of production code says something else. Also, I used go as a generic exa…
> ... you can have Go doing thousands of requests per second vs PHP doing hundreds of requests per second. > I know this because as an active PHP developer for over a decade I'm very much paying attention to that field of PHP. As an active PHP developer as well it sounds like you have no idea what you're talking about. > While you can use these tools you will almost certainly run into problems. Which tools are "gener…
Having read your post:
* Vanilla PHP can't read anywhere near the same RPS as the others
* Using those results in removing the ability to use a large amount of the ecosystem. While if you used the correct language you would be able to use it's entire ecosystem.
* In my opinion, if you're using workerman or Swoole you've already realised the limitations of PHP and should be using another language.
This seems like a classic case of "if all you have is a hammer everything looks like nail"
> Might not be as fast as go, but to say these libraries or tech isn't production-ready is rather naive.
This strawman argument. Firstly, you admit my original point. Secondly, those aren't the tech in question and I notice you left off the tech in question. Roadrunner, FrankenPHP, etc. All the tooling that can make your average PHP app go faster.
Re: Show HN: A Better Log Service
#107This 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 Pytho…
Try VictoriaLogs [1]. It supports wide events with hundreds of fields (aka canonical logs).
Re: Show HN: A Better Log Service
#108We need glorified (rip)grep instead of ELKS and friends, which have huge learning curve. I welcome this effort.
If you like grep, you'll like https://docs.victoriametrics.com/victorialogs/querying/#comm...
Re: Show HN: A Better Log Service
#109I've heard good things about Axiom[0], especially for high scale needs. 0: https://axiom.co/
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!