Traces
What is FuseScope?
FuseScope shows you what your software is doing while it runs. It collects data from your applications and servers, stores it, and lets you search it, chart it and get alerted when something goes wrong.
Read this page when you are new to observability, or new to FuseScope, and want the big picture before you open the app.
Why you need it
Section titled “Why you need it”When a user says “checkout is slow”, you need answers fast:
- Which part is slow: the web server, the payment service or the database?
- Is it slow for everyone, or only for some requests?
- When did it start, and did anything else break at the same time?
Reading code and guessing does not scale once a request passes through several programs. FuseScope answers these questions from data your applications already send. This practice is called observability.
The three signals
Section titled “The three signals”FuseScope works with three kinds of data, often called signals. Each answers a different question.
Logs
What exactly happened? A log is a
line of text a program writes, such as payment declined: card expired.
Metrics
How much, how often? A metric is a number measured over time, such as requests per second or memory in use.
An example: following a parcel
Section titled “An example: following a parcel”Think of a parcel sent across the country.
- You get a tracking number when you send it. Every depot that handles the parcel scans that number.
- Each scan records the depot, when the parcel arrived and when it left.
- Each depot also keeps a log book: “truck 12 late, parcel moved to truck 14”.
- Head office watches counters: parcels per hour, parcels delayed today.
A web request works the same way. Say a user books a ride in a small demo app made of
the services frontend, customer, driver and route:
| Parcel | Web request | In FuseScope |
|---|---|---|
| Tracking number | Trace ID, passed from service to service | Trace |
| One depot scan | The work one service did, with its duration | Span |
| The depot’s log book | Lines the service printed while it worked | Logs |
| Head office counters | Requests per second, error count, CPU | Metrics |
When the booking takes three seconds, the trace shows that frontend waited two of
those seconds on driver. The logs of that span say redis timeout. A metric
shows the timeouts started at 10:05. Three signals, one answer.
What FuseScope gives you
Section titled “What FuseScope gives you”- Services: latency, error rate and throughput for every service, with no extra setup. See Services.
- Explorers to search traces, logs and metrics.
- Dashboards to put the charts you care about on one page.
- Alerts that notify Slack, email, PagerDuty and others when a number crosses a line.
How data gets in
Section titled “How data gets in”Your applications send data using OpenTelemetry, an open standard supported by most languages and frameworks. They send it to the FuseScope collector, which writes it to a ClickHouse database. The FuseScope app reads from there. You don’t need any FuseScope-specific library. See Architecture for the details.
Next steps
Section titled “Next steps”Core conceptsThe words you will see everywhere: span, service, attribute, P99 and more.
Tour of the interfaceA map of the app: what each part of the screen does.