/images/avatar.png

LLM Observability: Practical Methods for Monitoring Prompt and Response

Langfuse is for this scene: the LLM service is live and users are complaining about output quality. Open the monitoring dashboard — CPU normal, memory normal, P99 latency within SLA. From an infrastructure perspective, the service looks perfectly healthy. This is the LLM observability gap: traditional APM tools can tell if the system is healthy, but not if the AI is.

PostgreSQL Performance Optimization

Slow SQL shows up in the plan first, not in postgresql.conf. Follow PostgreSQL: run EXPLAIN (ANALYZE, BUFFERS), see Seq Scan versus Index Scan, then choose an index, a rewrite, or a knob.

Missing indexes, a function wrapped around a column, stale statistics, autovacuum falling behind, cost constants left on the spinning-disk default — any of those send the same query through a full table. Read the plan before editing config.

Prometheus + Grafana Monitoring: Making LLM Services Visible

An LLM process that “looks fine” on CPU is often already serving a worse model, a slower first token, or a truncated completion. Prometheus + Grafana will show requests; a default node dashboard will not show tokens, TTFT, or a model label exploding cardinality.

The path is scrape → query → rules → panels. Every llm_* name below is an example metric name, not a standard export from Prometheus or from any particular gateway. Match /metrics before copying queries.