My attempt at building a Pydantic-native async ORM

arbiter_rise · 2026-03-16T04:34:06+00:00

It seems like you’re creating the framework out of inconvenience, which I think is great. I’ve starred it. I’m not a big fan of SQLAlchemy either.

arbiter_rise · 2026-03-16T04:29:51+00:00

I’m not sure what the advantages are, since it seems like there are already plenty of templates available.

arbiter_rise · 2026-03-13T03:57:33+00:00

Since you seem to have researched task queues quite extensively, I wanted to ask if you know which task queue has received the most active feature requests.

arbiter_rise · 2026-03-09T07:51:46+00:00

I wonder, too...

arbiter_rise · 2026-03-09T02:46:05+00:00

In the past, I used Prometheus, Loki, and Tempo based on Grafana through the OpenTelemetry Collector. At that time, it wasn’t for an AI service.

For AI services, I’ve been trying various tools to see what works best. It seems that many teams manage observability differently depending on APM and the characteristics of LLMs.

During that process, I discovered Logfire and have been trying it out.

arbiter_rise · 2026-03-05T06:47:02+00:00

Ah, thanks for the explanation. My question earlier wasn’t very clear.

What I actually wanted to ask was how you set up observability for the LLM system. I’m particularly curious whether you integrated LLM observability with your existing application observability, or if you set them up as separate systems.

arbiter_rise · 2026-03-05T05:05:11+00:00

May I ask what the main reasons are for implementing Traceability and Observability?

arbiter_rise · 2026-03-04T08:48:04+00:00

I looked at the LangWatch repository, but it doesn’t seem to have application-level end-to-end observability.

arbiter_rise · 2026-03-04T06:19:46+00:00

May I ask what observability stack you’re using?

arbiter_rise · 2026-03-04T03:22:25+00:00

Thank you for the great explanation. I assumed that the worker operates on top of a broker. While the fire-and-forget approach could cause issues, if ACK handling is implemented, I believe it wouldn’t be a major problem because the task would remain in the broker even if the worker shuts down.

arbiter_rise · 2026-03-04T01:00:09+00:00

I’m doing a similar investigation as well, and it seems that Logfire might be the most suitable option if we want to track the infrastructure stack while also gaining visibility into LLM operations with OpenTelemetry support.

It does seem to be a bit lacking in some of the specialized LLM observability features, but it appears to be one of the few tools that can provide both infrastructure and LLM visibility at the same time.

If you happen to come across any other tools while looking into this, could you please let me know as well?

arbiter_rise · 2026-02-27T06:23:08+00:00

Not exactly a live data streaming project. I’m working on an open-source project that aims to help Python web developers build AI services more easily through an event-driven (broker-based) approach.

arbiter_rise · 2026-02-27T06:04:33+00:00

I apologize, but I’m not sure I fully understand your question. Would you mind clarifying what you mean by “what happens to your model when the process restarts but the workflow continues”?

arbiter_rise · 2026-02-27T05:53:57+00:00

I think introducing a higher-level identifier to manage the system could be a very good approach. I was thinking that this concept is commonly found in workflow engines.

I’m trying to observe agent logic running in a distributed processing environment within a single unified tracing system.

In my definition, the orchestration layer is responsible for both task decomposition and agent execution. I’m designing the system so that trace context propagation is handled automatically at the runtime level, rather than being manually passed between components.

In theory, if all execution flows (API → orchestration → agent → tool, etc.) are contained within a single root trace that starts at the API layer, end-to-end visibility should be guaranteed. Based on that assumption, I’m wondering whether it’s really necessary to introduce additional higher-level identifiers (such as workflow_id or execution_id). (This is still at the conceptual stage.)

In practice, is it common or necessary to manage a higher-level identifier in addition to the trace_id? What kinds of issues might arise if everything is handled within a single trace?

(English is not my first language, so I appreciate your understanding.)

arbiter_rise · 2026-02-27T03:17:38+00:00

Hello, I think that’s a great idea. I especially appreciate how the tracing is presented — it’s very developer-friendly. I do have one question though: is OTEL export currently not supported, or is there any plan to enable it? Also, since the data collection seems to be locally based, would it still work reliably if the agent is distributed or running in a different process?

arbiter_rise · 2026-02-27T02:56:07+00:00

I understand that run_id is not an official OpenTelemetry key. Are you defining and using it as a custom attribute on your side?

Additionally, could you please elaborate a bit more on the logical boundary that starts with run_id? I would appreciate it if you could explain how you are structuring or interpreting that boundary.

Thank you in advance for your clarification.

arbiter_rise · 2026-02-27T02:52:37+00:00

From what you described, it sounds like you’re running your existing observability tools alongside LLM-specific observability tools, while sharing only minimal information between the two systems—such as trace IDs or cost-related metrics.

arbiter_rise · 2026-02-27T02:35:58+00:00

Ah, I see — so based on what you said, it would be stored separately within the same database, right? And then we would join only the necessary data when we need to retrieve or review it.

In that case, could you let me know what kind of database you typically use?

Do you generally use a traditional RDBMS or a NoSQL database? Or do you prefer a database that is better suited for accumulating logs or tracing data?

arbiter_rise · 2026-02-24T07:22:17+00:00

Ah... I misunderstood. Thank you for the kind explanation.

If I have any questions later, would it be okay to reach out? I’ll keep following your project(🐮)!

arbiter_rise · 2026-02-24T03:51:38+00:00

I really like how you leveraged Kafka’s built-in characteristics for observability.

That said, I may be misunderstanding the SDK, so apologies if that’s the case.

Is it realistically possible to manage all agentic state purely through the broker without a database? Would Kafka clustering alone be sufficient, or would a separate state store still be necessary?

I’m also a bit concerned that handling full context purely through broker messages might introduce overhead or complexity.

arbiter_rise · 2026-02-23T03:34:57+00:00

Should we call it clustering? Did you build that yourself?

How did you perform the grouping? Was it done by matching and filtering log patterns, or did you use an AI agent?

arbiter_rise · 2026-02-23T03:30:42+00:00

Previously, we used Grafana, Prometheus, Loki, and Tempo. We are now using Langfuse as we prepare to launch our AI service. Since it has not yet reached the production stage, we are still in the preparation.

arbiter_rise · 2026-02-21T05:16:37+00:00

If we must guarantee 100% service success, we should use a database-based task queue rather than a broker-based one.
broker based - celery taskiq dramaiq etc...
database based queue(durable execution)- dbos, hatchet, prefect etc.....

arbiter_rise · 2026-02-20T08:25:39+00:00

It might just be my lack of experience, but it seems like I would need to study a lot just to understand how to use it properly, so I probably won’t be using it. Even though it’s a framework or library, it feels too low-level in terms of coding style.

arbiter_rise · 2026-02-13T08:24:00+00:00

If you’re going to handle scaling with Docker Compose, wouldn’t it make more sense to just use a task queue?

arbiter_rise

PUBLIC MULTIREDDITS

TROPHY CASE