[HN Gopher] Pydantic Logfire
___________________________________________________________________
Pydantic Logfire
Author : ellieh
Score : 89 points
Date : 2024-04-30 15:56 UTC (7 hours ago)
(HTM) web link (pydantic.dev)
(TXT) w3m dump (pydantic.dev)
| serjester wrote:
| I love pydantic but I really have to wonder why they chose this
| route. There's already a ton of companies that do this really
| well and I'm trying to figure out how their solution is any
| different.
|
| The llm integration seems promising but if you care about LLM
| observability you probably also care about evals, guardrails and
| a million other things that are very specific to LLM's. Is it
| possible to build all this under one platform?
|
| I do hope I'm wrong for the sake of pydantic-core.
| thenipper wrote:
| Agreed. I use pydantic daily and I'm in the position to try
| this out... but why? It really seems to be a weird divergence
| from their core product.
| Yenrabbit wrote:
| They also have a UI framework (fastui). They have funding and
| devs looking to be useful, I think it's fine that they get to
| try out new things that work well with their core product.
| wferrell wrote:
| Who do you like who does this well?
|
| I think Pydantic is great software and so I am inclined to see
| if this too will be great software.
| clintonb wrote:
| My last company used Splunk and SignalFx. They were fine, but
| I wasn't necessarily in the weeds with configuration and
| usage. The Observability Team made it easy to use.
|
| My current company, a much small startup, primarily uses
| Datadog and we are starting to better integrage Honeycomb. We
| mostly abandoned Google Cloud Monitoring because the UI/UX
| are not that great. Honeycomb is a paradigm, so took some
| time for us/me to understand. It's growing on us.
|
| Despite the ability to completely blow up our bill (which is
| now better controlled), Datadog is a good product that lets
| us quickly answer questions when things go wrong. It's not
| perfect, but it's the best we have right now. The UI is
| intuitive, and facilitates more discovery (esp. for metrics
| and their attributes).
| cipherself wrote:
| I am kinda confused by your comment, OP is about tracing as
| far as I understood, but you're referencing Google Cloud
| Monitoring (whereas the comparable thing would be Google
| Cloud Trace) and then again (esp. for
| metrics and their attributes).
|
| but OP isn't about metrics at all rather traces.
| gazpacho wrote:
| Hi, I'm one of the developers of Logfire. We do support
| metrics! Our vision is a single pane of glass
| observability where you can easily go from metrics <->
| traces both via correlation and by creating
| metrics/dashboards from traces.
|
| We also support logging as an integrated concept into
| tracing (you can emit events without a duration that are
| just like a log but carry context of where they were
| emitted from relative to a trace).
| emmanueloga_ wrote:
| Looks like "Pydantic Logfire" is another entry on the
| category of "APM"s? [1]
|
| Gotta echo the sentiment that Logfire doesn't seem to be too
| closely related to Pydantic... Also, afaict it looks like the
| frontend is not open source, unless I'm missing something
| [2]. So, not a tool that one could self-host?
|
| --
|
| 1: https://github.com/topics/apm
|
| 2: https://github.com/pydantic/logfire/
| scolvin wrote:
| Pydantic creator here.
|
| I understand why this might be your reaction, but let me just
| share my thoughts:
|
| Can we build all the LLM things people want? Yes I think so,
| early feedback is that Logfire is already much more
| comprehensive than LLM specific solutions.
|
| How is our solution any different? AFAIK:
|
| * no one else offers opinionated wrapper for OTel to make it
| nicer to use, but with all the advantages
|
| * no one else does auto-tracing (basically profiling) using
| import hooks the way we do
|
| * no one else has dedicated instrumentation for OpenAI or
| Pydantic
|
| * no one else provides metadata about python objects the way we
| do so we can render a semi-faithful repr of complex objects
| (Pydantic models, dataclasses, dataframes etc.) in the web UI
|
| * no one else (except Sentry, who are doing something
| different) makes it really easy to start using it
|
| * no one else lets you query observability data with SQL
|
| In my mind, the obvious alternative would be to do the thing
| most OSS companies do, and build "Pydantic Cloud", then start
| adding features to that instead of the open source package. I
| didn't want to do that, and I don't think our users would like
| that either.
|
| In the end I decided to build Logfire for two reasons:
|
| 1. I wanted it, and have wanted it for years
|
| 2. I think building a commercial product like this, then using
| OSS to spread the word and drive adoption is a really exciting
| way to incentivize us to make the open source as good as
| possible -- good as-in permissive and good as-in well
| maintained. And it means that our commercial success is not in
| tension with the adoption of our open source, which has been a
| recurring issue for companies trying to capitalize on their
| open source brand.
| hakanderyal wrote:
| Useful product, great marketing site. This is obviously a
| labor of love. Keep it up!
|
| Sadly I've moved on from Python world.
|
| Funny anecdote, using Pydantic everywhere to improve
| maintainability made me realize I'm fighting an uphill battle
| with Python and I should move to a statically typed language,
| so I switched to C#.
|
| Thanks for your work.
| serjester wrote:
| Thanks for the response, massive kudos - I look forward to
| trying it out!
| btown wrote:
| This is very cool. Could someone use Logfire alongside
| Honeycomb or another OTel platform? Honeycomb's strengths in
| drilling into an interactive chart vs. Logfire's strengths in
| drilling into a stream of text logs (and SQL support!) seem
| very complementary.
|
| Certainly seems like the Logfire initializer could coexist
| with code like in https://docs.honeycomb.io/send-
| data/logs/opentelemetry/sdk/p... - is this a reasonable
| assumption? We're looking into modernizing our Honeycomb
| integration from their older direct integration to their OTel
| SDK, and would be very curious if Logfire can exist alongside
| this. Do you do any patching of OTel internals that would
| make this impossible?
| scolvin wrote:
| You can send data from any OTLP endpoint, so yes.
|
| I don't think we currently expose an easy way for you to
| send data to two (e.g. honeycomb and logfire), it it should
| be entirely doable, and if people want that, we can make it
| easy.
| zbentley wrote:
| This smells a bit like someone is using the brand of a famous
| open-source tool they built to promote their startup. If so,
| that's lame; if the new business is unrelated to your open source
| project, branding it as _Pydantic_ Logfire seems a bit
| disingenuous.
|
| I think there's a less-misleading way to use open-source
| reputation for business credibility, though: "so-and-so business,
| by the creators of so-and-so project". Knowing that respected and
| skilled folks are working on a business is great! It's a fine
| distinction, but I think it matters.
| scolvin wrote:
| If anyone is mislead about whether Pydantic is Logfire or visa-
| versa, I'll eat my hat.
|
| Other than that, see my answer to the other comment.
| nsteel wrote:
| For the record, I don't agree with the grandparent comment at
| all. None of this is "lame". It's a path to sustainable OSS
| and it's more obvious than ever that we need these pathways.
|
| But to be fair, the branding here is a little weird. If you
| were living under a rock and hadn't heard of pydantic then
| the website reads like pydantic is the company and logfire is
| a product of said company. That's fine. But then you've also
| got a product called pydantic. Or is it now called pydantic
| pydantic? I realise it's kind of an extension to pydantic but
| the AI focus doesn't make it feel that way and so I think
| that's where the GP is coming from. Sorry to nitpick, I hope
| it does well.
| esafak wrote:
| This is just how you brand when you have one product. If he
| made up a new brand to subsume both products nobody would
| recognize it, so he wisely decided to recycle the existing
| brand; familiar, and liked.
|
| Google was originally just the search engine, without any
| qualifier. Now it's Google Search. In the same way,
| pydantic can become "Pydantic Validate" or something.
| scolvin wrote:
| I think that's fair. It's a hard problem.
|
| We could have called the company a completely new name and
| everyone would have been confused, or just called us
| "pydantic".
|
| I think Pydantic being the company name, and a standalone
| entity, and there being other products is fairly common. I
| think if Logfire is successful, it will end up just being
| known as "Logfire".
| esafak wrote:
| It is related, though: the creator is the same, so you can
| expect the same DX.
| robrenaud wrote:
| Finding ways to reward people for building great open source
| software is something that we need more of. It's not lame at
| all.
| barapa wrote:
| From the website:
|
| _From the team behind Pydantic, Logfire is a new type of
| observability platform built on the same belief as our open
| source library -- that the most powerful tools can be easy to
| use._
| MapleWalnut wrote:
| It'll be hard to position this against Sentry. Sentry's a joy to
| use and their performance product is so helpful in debugging
| performance issues
| Lucasoato wrote:
| One of the Sentry inconvenience is self-hosting: it relies on
| so many services it can be very complicated to maintain.
| esafak wrote:
| Does the self-hosted version have all the features?
| easton wrote:
| yes, every feature (but billing, iirc) is in self hosted.
| which means you need all of their backend dependencies
| (kafka, zookeeper, other things that are probably easier to
| manage than those two)
| mdaniel wrote:
| I draw ones attention to the _actual_ Open Source glitchtip
| which has a much more sane deployment, akin to the good old
| days of Sentry before they got Big Data-itis:
| https://gitlab.com/glitchtip/glitchtip-
| backend/-/blob/v4.0.8... (or its helm version, similarly not
| JFC https://gitlab.com/glitchtip/glitchtip-helm-
| chart/-/tree/61c... )
| drchaim wrote:
| The ideal business model (from a user's point of view) for
| successful libraries like Pydantic, Ruff, etc., is like a
| foundation or sponsoring. But (almost) nobody pays for them (me
| included), so their creators have raised VC money, citing: 'We
| have xxM users and yyyyyM downloads per month.' Not to blame
| library authors here, they are trying their thing, which is
| indeed admirable. It's just that open source is difficult to
| sustain. Wishing them all the best
| jmduke wrote:
| OP: as someone who runs a Python business and is a happy user of
| Pydantic (via Django-ninja) -- something I would want this splash
| page to convey, at least implicitly, is "why use this over
| Sentry?" As far as I can tell, the answer is: an OpenAI binding
| and stronger Otel support.
|
| (That being said, I am a sucker for all new tooling in this genre
| and am excited to play around with it!)
| jmduke wrote:
| Responding to my own post: this comment
| (https://news.ycombinator.com/item?id=40214695) I think is a
| very compelling answer. I love the design language of the
| splash page, but I think the copy could be improved by a little
| less "here is why performance insights are useful" (which I
| think most people are kind of already on board with) and more
| "here is why our performance insights are _particularly_ more
| useful than the competition".
| megaman821 wrote:
| Does this do logging or just traces? More to the point, is it
| economically to store tens of millions of log lines a month?
| cipherself wrote:
| From the screenshots, it seems very much to be about tracing.
| dmontagu wrote:
| I'm one of the Pydantic/Logfire devs -- we are actually aiming
| to unify the ideas of logging and tracing a bit more than seems
| common in most such tools -- our logfire SDK actually emits
| spans for all of the traditional logging statements rather than
| relying on OTel logging infrastructure (which seems to be kind
| of a legacy-oriented afterthought relative to the tracing
| APIs/infrastructure). So, yes, I would say we do support
| logging (certainly on a conceptual level), though the point is
| to try to move toward a world where as much as possible is done
| with spans, if only as an implementation detail.
|
| We also have explicit integrations with popular logging
| packages (see the bottom of https://docs.pydantic.dev/logfire/i
| ntegrations/#opentelemetr...), so if you use the standard
| library `logging` module, `structlog`, or `loguru`, you should
| be able to set up your logs to ship to Logfire with minimal
| modifications to your existing code.
|
| While we have not announced our pricing yet, I am confident
| that tens of millions of log lines a month will absolutely be
| economical to store.
|
| (Also, I'll just add that we also support metrics, though our
| metrics support is not as well-integrated yet as tracing. But
| soon!)
| laborcontract wrote:
| I was just looking for a logging service. Really enjoy
| Pydantic so this looks like it may be a delight.
|
| Try not to surprise us on pricing, though.
| barapa wrote:
| I'm already using it and I think it's great. Well done Samuel and
| team!
| logfire_q wrote:
| can i self host logfire? based on the "logfire auth" in the docs
| i'm thinking no?
| mariocesar wrote:
| It is a great tool! Congratulations on launching it!
|
| Could you clarify if it's possible to self-host the service?
| scolvin wrote:
| We'll offer self hosting for enterprise.
|
| I want the entry level for "enterprise" to be much lower than
| some other companies in this space.
| mulmboy wrote:
| Is self hosting possible? Can't see any mention in the docs
| ryanisnan wrote:
| It looks like it's on the roadmap, but my interpretation of the
| project would be that this is would be behind a licensed
| paywall. https://docs.pydantic.dev/logfire/roadmap/#on-premise-
| deploy...
___________________________________________________________________
(page generated 2024-04-30 23:00 UTC)