I'm not sure the log message v structured message comparison makes sense - most log and trace events are batched and compressed before being transported, and so the size difference isn't really an issue. On the receiving side most services have some kind of column store as their main datastore and so there's no issue there either. The benefits of structured logging are worth it.
Regarding pricing - there is an option for every kind of usage out there, it's mostly a solved problem that comes with choosing two of large scale, low cost, low latency. For instance we serve large scale and low cost.
(co-founder here) Try axiom.co - we support splunk-like query syntax, dashboards, monitors, unlimited sources/hosts/etc, and you get 500GB/mo ingest + 30 days retention on the free plan.
And that resulting in compromises such as high amounts of sampling, ignoring a facet of data altogether because "we won't need it if something goes wrong...", and/or using some kind of log stream processor to divert large amounts of data in S3 instead of allowing it be queried whenever you want.
In the case of Axiom & Vercel, you'll only be paying for ingest (if you need over 2GB/day) and no bandwidth costs. I believe the latter is the case with all of Vercel's observability partners (and with most services providing a log-drains service).
It's a fair point, though...at some point, and with enough TBs of traffic, it could get expensive to provide the log drain support. One thing we've been working on (and more on this in the coming weeks), is putting together a benchmark of log-drain mechanisms to try and work out what would be the most efficient combo of compression/cpu/mem to use for log-drain providers.
Our hope is we can work on making it efficient enough that we can encourage more services to provide log-drains (and therefore allow us to make great experiences around those logs!).
> The solution goes - Splunk is too expensive, let's ditch logs altogether and hope we capture some metrics and plot them in nice dashboards. Instead of dumping the logs highly compressed into cheap s3 and running some Snowflake or Spark on it later.
I don't usually promote on HN but this is exactly why we built https://axiom.co! We've been working on this problem for some time, essentially allowing schema-less/index-free ingest, S3-based storage in a highly-efficient format, and then querying with a Splunk-like (specifically Kusto-inspired) language via serverless functions.
We built it because we also realised we would avoid or think too much about logging (cost, scaling, retention, etc) which led to compromises either in our monitoring or later when we wanted to dive in and try and draw some insights/analytics from that kind of data.
I was responsible for writing a lot of the Unity shell for Ubuntu with my team, taking it from Ubuntu Netbook Remix -> Unity (Mutter) -> Unity (Compiz).
During that period I feel like my team and I wrote a lot of important code, but the fact that Unity survived for so long and was used by so many people makes it stand out.
I'd say a close second was Avant Window Navigator (AWN - a Linux dock), because it got me enough attention to be offered a job working on Open Source full time!
Fwiw, there seems to be a push from VCs to bring you in talking about a 'normal' seed round (a smallish figure, debt-financing or simple equity-financing), but then try and talk up doing a large Series A immediately (with all the complexity that brings).
The idea being that you then have enough money to go and do whatever you want, at any cost, and work your way to a Series B. In the mean time, the VC(s) get their share and have some/all board control.
It helped me get my first job at OpenedHand, working on free and open source software full time. I didn't have any previous experience nor a degree in CS.
I've been using this recently for a pretty complex SPA and it's been great.
It's clear what's happening, without a tons of boilerplate code, and it has some nice dev tools as well (trace element updates & events, great for debugging). It also has very useful error messages in development mode (which is a godsend).
On top of that, I think the docs are pretty good, they seem to be quite active on GitHub and, from every piece of the puzzle that comes together to make a 2016 web frontend (react, web pack, babel, flow, ui kit, etc, etc), it's given the least trouble for me so far.
I've raved about Echo before on HN, but I'll do it again because it's is one of those frameworks that are just lovely to use. Very easy to keep API mapped in your head, code is simple and straight-forward, performance is great, and it plays nicely with standard handlers.
Agreed - those two points, and the general simplicity of the Echo codebase, were why I ended up using it over the (many) other options for Go. Honestly haven't had the desire to check anything else out since, it's just always worked very well.
Have been using this for quite some time - it has a nice API and is solid in production. I love the simplicity and it's small enough a codebase to quickly read and start hacking around.
We're really excited to be working on solving real-world problems we've come across with Skizze, hopefully others will find it useful too as it matures!
Regarding pricing - there is an option for every kind of usage out there, it's mostly a solved problem that comes with choosing two of large scale, low cost, low latency. For instance we serve large scale and low cost.