There are a lot of big players in the observability platform world. DataDog comes to mind, and they are EXPENSIVE. I've seen DataDog bills that cost more than the infrastructure they are monitoring! There are some other vendors in the space to, such as Dynatrace, Elastic APM, etc..
They all share a few things in common: They are essentially either silo'ed stores locked behind some vendor system with ever increasing bills, or they require a lot of resources to operate yourself
However, for your average small SaaS business not receiving millions of hits a day, that's all overkill. You just want something to view your logs, some distributed traces connected to those logs, and important system metrics. And you don't want to pay a lot of money to do it either, and even better if you can just run it on the infrastructure you already have and pay for.
That's where PeachTrace comes in. It's an OpenTelemetry-native observability stack that is designed to be self-hosted. There's only a handful of components that need to be installed and set up: You need Windows or some sort of modern Linux, SQL Server 2025+ (the free Express Edition is fine, though there's data storage limits), and you need to set up 3 components: the collector that implements the OTel API that your code talks to, the API layer that the UI and your AI tools can talk to (there's an MCP connector in development as well), and a static HTML/JavaScript dashboard (built in Angular) that talks to the API.
We are starting a limited beta program to work out the kinks in mass distribution of the software. Some known pain points we plan on addresing is building official Docker images, including an "all-in-one" image. We'd also love ideas to improve the software in other ways to make it a more useful product over all.
We dogfood it ourselves already, deployed to a Fedora 44 server (no Docker), with Apache proxying the collector and API, and directly serving the dashboard UI, and a SQL Server Express database instance directly on Fedora. Claude is already a master of using it to investigate and fix bugs in our other applications and client applications we manage!
There are a lot of big players in the observability platform world. DataDog comes to mind, and they are EXPENSIVE. I've seen DataDog bills that cost more than the infrastructure they are monitoring! There are some other vendors in the space to, such as Dynatrace, Elastic APM, etc..
They all share a few things in common: They are essentially either silo'ed stores locked behind some vendor system with ever increasing bills, or they require a lot of resources to operate yourself
However, for your average small SaaS business not receiving millions of hits a day, that's all overkill. You just want something to view your logs, some distributed traces connected to those logs, and important system metrics. And you don't want to pay a lot of money to do it either, and even better if you can just run it on the infrastructure you already have and pay for.
That's where PeachTrace comes in. It's an OpenTelemetry-native observability stack that is designed to be self-hosted. There's only a handful of components that need to be installed and set up: You need Windows or some sort of modern Linux, SQL Server 2025+ (the free Express Edition is fine, though there's data storage limits), and you need to set up 3 components: the collector that implements the OTel API that your code talks to, the API layer that the UI and your AI tools can talk to (there's an MCP connector in development as well), and a static HTML/JavaScript dashboard (built in Angular) that talks to the API.
We are starting a limited beta program to work out the kinks in mass distribution of the software. Some known pain points we plan on addresing is building official Docker images, including an "all-in-one" image. We'd also love ideas to improve the software in other ways to make it a more useful product over all.
We dogfood it ourselves already, deployed to a Fedora 44 server (no Docker), with Apache proxying the collector and API, and directly serving the dashboard UI, and a SQL Server Express database instance directly on Fedora. Claude is already a master of using it to investigate and fix bugs in our other applications and client applications we manage!