DEV Community: Akash Goyal

Why I Built PaperFlakes (And How Zerops Saved the Stack)

Akash Goyal — Sun, 09 Aug 2026 18:22:38 +0000

Late one night while preparing slides for an upcoming talk, I ran three dense research papers through a standard OCR tool.

The OCR worked, but left me with 40 pages of raw, unformatted text. The real problem wasn't extracting the text; it was finding the insight buried inside it.

I wanted something that could turn dense PDFs into small, visual insights - bite-sized cards ready for slides, developer notes, or Twitter.

That was the spark for PaperFlakes.

PaperFlakes takes PDFs - pick from a curated list of classic ML papers or upload your own - OCRs them, and turns the extracted text into shareable "sticky note" insight cards across four categories, which you can filter, download as images, or share straight to X /Twitter.

Features for Users

I set out to build a platform that turns dense academic reading into a fast, visual experience:

Batch Processing: Drop up to 25 multi-page PDFs.
Real-Time Progress: Watch live updates as the engine parses document queues, tracking statuses, page counts, and extracted word tallies.
"Did You Know?" Fact Cards: Color-coded visual cards highlighting key facts, formulas, and takeaways.
Instant Export & Sharing: Download cards or share them straight to social media.

How to use it

Open the live app.
Check one or more papers under "Try it on papers" and click Process batch.
Watch the Processing status table update as each document is OCR'd.
Insight cards appear in the Insights panel as soon as each category finishes — no need to wait for the whole batch.
Use the category chips and paper dropdown above the panel to filter what's shown.
On any card: Save downloads it as a PNG
On any card: 𝕏 Share opens a pre-filled tweet.
Download all (top right) exports every currently-visible card as one combined image.

The UI view:

The social media share view: Link to generated tweet

Product Walkthrough :

The application follows a simple three-stage flow:

Upload & Queue (left) - Users select multiple PDFs or upload their own documents and start a batch.
Process & Track (center) - Each document is processed asynchronously, with its status, page count, and processing details visible in real time.
Generate Insights (right) - As soon as a document finishes processing, AI-generated facts and insights appear as shareable sticky-note cards.

The Engineering & Zerops ZCP

Behind the UI, the backend handles the pipeline:
PDF ingestion → metadata storage → chunking & OCR → AI-powered insight extraction → result storage → fact-card generation.

This keeps the user experience simple while the heavy document processing happens asynchronously in the backend.

The zerops.yaml is shared here .

When a user submits a batch, the Express API registers the job inside PostgreSQL with a queued status and returns an instant job token to the React UI. As workers process pages through Gemma (Together AI) asynchronously, the database updates in real time, and the UI streams progress smoothly without dropping connections.

This whole project is heavily reliant on Zerops infra & built using the ZCP.

Runtime service
Managed PostgreSQL
Public HTTPS — zerops.app subdomain after deployment.
Secrets — TOGETHER_API_KEY is stored as a Zerops service secret.
Health checks
Git-based deployment — deploys the latest commit to Zerops using zcli.
ZCP with Claude Code

Running your own copy

The repository is self-contained: zerops.yaml defines the deployment configuration, while migrate.py initializes the database schema idempotently on each deploy.

Create a Zerops project with a Python runtime service and a PostgreSQL service named db.
Create a Together AI API key and add it as the TOGETHER_API_KEY secret on the runtime service.
Configure ZEROPS_TOKEN and ZEROPS_SERVICE_ID as GitHub repository secrets.
Push to main. The included GitHub Actions workflow builds and deploys the application automatically.

You can also deploy manually using zcli push or the Zerops MCP tools.

You can see the zerops-services in action & associated cost with them (left-bottom)

By offloading setup headaches to Zerops, I was able to go from an initial draft idea to a production-ready, multi-service application in a single hackathon build window.

Demo Video : https://youtu.be/5ra5lgwRpeQ
Github : https://github.com/akashgoyal/paperflakes-zerops
Live App : https://app-2c11-8000.prg1.zerops.app/
Built For : https://www.wemakedevs.org/hackathons/zerops

Written by : Akash Goyal

Sentinel MCP Signoz (Agents of Signoz)

Akash Goyal — Sun, 26 Jul 2026 17:40:36 +0000

I participated in 'Agents of Signoz' hacakthon with Ashish Agrawal.
We built an impactful project using the Signoz ecosystem.

Signoz Alert based - Agentic system - with Unified Observability Dashboard

Project features :

Agentic application with SRE Agent, Data Quality Agent.
SREAgent would trigger on Alert (from log/trace/metric) via webhook.
Data Quality Agent would run at certain durations once the Data ingestion is complete.
Each Agents make use MCP tools from signoz-mcp-server & tools
Signoz Dashboard customized for unified experience - for Agent, App, mcp-tools & APM metrics - using Query Builder

Hackathon : https://www.wemakedevs.org/hackathons/signoz
Github : https://github.com/akashgoyal/sentinel-mcp-signoz
Hackathon Project PPT : LINK
Youtube Video : Demo Link

This blog will hand hold you through the project - in understanding it's whereabout, reasoning behind features, and finally practicals.
Kepe reading to know below :

About the Project
Tech Stack & architecture
How to setup on your local & run demo
Learning & Growth

Create User application - which will use OTel

Langgraph based application with [Ingestion → Analyser → Extractor → Refiner] Nodes. All using qwen2.5-coder:1.5b model from ollama.
Application Flow chart :

Create SRE Agent & Data Quality Agent - using signoz-mcp-server

SRE Agent :

SRE Agent (powered by gemini-3.6-flash) takes over without human intervention. Features :

Performs RCA on application & setup errors
Triggered on Signoz-Alert for RCA.
Analyzes the application traces, logs, metrics
Identify the Root Cause of the problem

Design Diagram :

Data Quality Agent :

Data Quality Agent (powered by openai-4o) takes over without human intervention. Features :

Triggered on Signoz-Alert when ingestion process completes.
Analyzes the application traces and logs - from Signoz Storage.
Generates an analysis focused on Compliance Governance.

Design Diagram :

Setup Signoz Dashboard :

Unified Observability Dashboard

Single monitoring panel for all project components. Features :

Metrics related to >10 signoz-mcp-server tool calls .
Langgraph based user app metrics (custom metrics)
SRE Agent related metrics
APM Metrics

Tools Used :

Default Signoz Dashboard Templates.
Query Builder - Drag & Drop, query builder.

PRACTICALS

Setup on your machine locally :

Refer the github repo shared in first section of this blog.

Infra Setup

Setup Signoz via foundry. Enable MCP. Follow this guide.
Create user-account in Docker
Create a service-account
Create Signoz-API-Key in service account

User + Agents Application Setup

An agentic app using instrumented packages which could generate telemetry data
Enable Traces, Logs, metrics in app
Exporters configured to Signoz OTel Collector
Scripts to generate data - for both Success, Failure scenarios

Signoz Viewers

Check Trace Viewers
Check Log Viewers
Check Metric Viewers
Create Metric dashboard and use Signoz Query Builder to adjust metric widgets queries, with service-name, metric name or trace-field name
Setup a webhook notification channel
Configure Alerts (using query builder)

Execution Outputs :

User Application Run
Errors generated in Signoz
Alert triggered in Signoz
Webhook server start & request received
SRE Agent in Action - MCP tool call (fetch logs)
SRE Agent in Action - MCP tool call (fetch traces) & OUTPUT
Unified Observability Dashboard for - APM + User App + Agent App + MCP Tools metrics

Impact of Project

Built an AI-powered observability solution leveraging the Signoz ecosystem.
Minutes instead of hours for initial incident triage using AI agents.
Single-click investigation across Signoz Logs, Metrics, Traces, and Query Builder.
Automated root cause analysis and data quality validation using Signoz MCP Tools.
Showcased the potential to significantly reduce manual debugging effort.
Dashboard view in one place has customer - Easy visuals for Business stakeholders

Learning & Growth

Gained hands-on experience with Signoz, OpenTelemetry, and Signoz MCP.
Learned to integrate Logs, Metrics, Traces, Query Builder, Dashboards, and Alerts into AI workflows.
Strengthened skills in AI agents, observability, and event-driven system design.
Improved rapid prototyping and solution building in a hackathon environment.
MCP tools eased the Agentic Development

References

Github Repo : https://github.com/akashgoyal/sentinel-mcp-signoz

User Application
MCP based Agents
Programmatic Webhook Server

Disclaimer :

AI-tools were used in :

Writing Code
Debugging issues
Refining system design diagrams
Getting clarity on doubtful concepts AI Tools - Gemini, CoPilot, AntiGravity

Presenting with Thanks

Custom Metrics Dashboard for GenAI apps with SigNoz and OpenTelemetry

Akash Goyal — Sat, 18 Jul 2026 22:55:40 +0000

SigNoz supports lot of features and has a lot of documentations around those features. It has a full section dedicated to LLM observability across different service providers.

But, this blog is a bit different. Instead of relying on out-of-the-box vendor presets, it shows you how to create a completely custom dashboard tailored for your specific GenAI/agentic application as per your needs.

Just tracking generic infrastructure metrics like CPU and memory utilization isn't enough. To understand how your AI features are truly performing, you need specialize application-level telemetry.

All the code discussed in this post is available in the GitHub Repository.

Signoz supports both Trace Data and Metrics Data - for setting metric widget queries. This feature is really helpful in scaling the existing instrumented codebases & has uniqueness.

Part 1: Setting Up SigNoz Locally (Self-Hosted Docker)

Referred Signoz Doc Section for setting this up.

### Step 1: Install Foundry
curl -fsSL https://signoz.io/foundry.sh | bash

### Step 2: Create `casting.yaml`
vi casting.yaml  #add below
"""
apiVersion: v1alpha1
kind: Installation
metadata:
  name: signoz
spec:
  deployment:
    flavor: compose
    mode: docker
"""

### Step 3: Deploy SigNoz - spin up your local SigNoz infrastructure:
foundryctl cast -f casting.yaml

Part 2: Application Architecture & Quick Start

I designed a minimal llm-inference based workflow application, with two language models, to work on this topic.

1. Application Architecture Block

Explanation of the diagram:

Traffic Flow: The LLM Client actively invokes endpoints on the LLM Server to run inference tasks.
Telemetry Collection: Both the client and the server generate performance data during these interactions.
Data Export: The gathered telemetry is continuously pushed out via a Metrics periodic export routine utilizing OpenTelemetry standard components (OTLP Span Exporter and OTLP Metric Exporter).
Storage and Visualization: The exported data flows directly into SigNoz, where it is permanently stored in a ClickHouse DB.
Observability: Finally, developers can monitor the application using the integrated Trace Viewer and Dashboards.

2. Getting Started with App

Clone the repo from github. Then, follow these steps to initialize the environment and launch your components:

# 1. Setup local virtual environment
python -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt

# 2. Ensure metric computation logic is added.

CODE - custom metrics relevant to the application.

CODE - Setting span attrs & record metrics

# 3. Spin up the LLM Server container 
# Create your docker-compose.yaml file first, then run:
docker compose up -d llm-server

# 4. Configure local environment and run client loops sequentially
pip install httpx opentelemetry-api opentelemetry-sdk opentelemetry-exporter-otlp 
export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317"
export OTEL_RESOURCE_ATTRIBUTES="service.name=llm-client-service"
python llm_client.py

Part 3: Visualising the Traces

A look at the traces :

Success Client requests - Trace View:
If the infra capacity is limited, after some requests, time-out errors might start surfacing. (Nothing to worry, just restart the llm-server from docker app). Related traces examples below:

Requests getting Timed Out one after other. (Server was hung)

Errored Request Trace (server was not up by that time)

Part 4: Custom Metrics Dashboard in SigNoz

Creating the Custom Dashboard - Below are the steps I followed in order:

Implemented the custom metrics relevant to the application.
Added relevant attributes in spans & record metrics.
Referred one of the template dashboards in Signoz Dashboard Page. Took the Agno Dashboard as Base to build upon.
Took the code for 'Error rate' metric widget. Created new metric widgets, in sync with the metric_record.py logic.
Modified the queries of existing widgets in Base Json.

For any further edits (metric-name, widget-type, etc.), I used the SigNoz's native Query Builder.

The dashboard JSON used for this experiment is shared in the repo file.

How it appears in SigNoz:

Signoz Default Metrics Section :

Your Custom Metrics dashboard - data rendered using both span params & metrics :

Conclusion & Impact: An insight into custom dashboards with Signoz

These are my findings on how Signoz supports custom metrics dashboards, and what changes are needed or good to have while working on such requirements.

Signoz supports both Trace Data and Metrics Data - for setting metric widget queries. This feature is really helpful in scaling the existing instrumented codebases & has uniqueness.

I hope this content would help readers enhance their knowledge.

Ready to get started? Clone the experimental code from GitHub Repository and spin it up in your local developer environment!