Okapi yet Another Observability Thing

Hi, I just wanted to share Okapi with the community here. Its my stab at the observability problem - how to debug when something breaks in prod. Okapi focusses on two modalities of observability's big three (metrics, logs, traces). Okapi is all about metrics and traces. The idea here is that metrics and traces usually have the most signal and also that analyzing logs is so fragmented that one might just spend ages doing just logs stuff.

Features: - Otel everywhere, its Okapi's preferred and only ingestion mechanism :) Currently Okapi supports ingestion via protobuf-over-HTTP. Here's a sample config (https://github.com/okapi-core/okapi?tab=readme-ov-file#examp...)

- Dashboards both via clicks and code: Okapi UI has a dashboard designer hopefully with autocomplete everywhere so users don't have to guess metric paths. However, if you're not a fan of clicks and/or love GitOps all Okapi dashboards can be expressed as YAML templates.

- Out-of-box Service health: For an application instrumented as per Otel conventions, Okapi has REDs as a first-class concept. Service health pages have RED breakdowns for the service, its sub-operations and dependent paths. The calculations are subject to applications being instrumented, but hopefully following a convention makes things easy.

- And of course AI : Okapi has a limited capability AI SRE agent affectionately called Oscar (supposed to be an okapi but no mascot yet). Calling it a full blown SRE is a stretch since its tough job. You can ask Oscar questions in natural language as you would any chatbot and it will try its best to answer. Atleast on integration tests, Oscar can fetch metrics, find traces given criteria and do a multiple step debugging that links query latencies with high CPU usage on hosts.

I am curious to hear feedback from the community so check it out.

TLDR: https://github.com/okapi-core/okapi?tab=readme-ov-file#quick...