View Services

The Services section in SigNoz gives you an overview of all your instrumented applications in one place. It surfaces the RED metrics — Rate, Errors, and Duration — for every service, so you can quickly spot which services are degraded, slow, or erroring without drilling into individual traces.

SigNoz UI showing the Services section — *Services Section*

Prerequisites

This section assumes that your application is already instrumented. For details about how you can instrument your application, see the Instrument Your Application section.

What Are Application Metrics?

Application metrics represent a characteristic of your application as a value at a specific point in time. For example, an application metric is the number of requests per second your application serves. SigNoz collects information as a sequence of data points every minute and then represents the data through time in a graphical form. The X-axis is time, and the Y-axis is the value.

The Services section relies on the rate, errors, and duration ("RED") method to help you predict the experience of your users and includes the following key metrics:

P99 Latency: the amount of time your application spends processing each of the fastest 99% of requests. For example, if the value of the P99 latency is 760 ms, 99% percent of requests have responses that are equal to or faster than 760 ms.
Error Rate: the percentage of failing requests i.e ratio of error requests to the total requests.
Requests per Second: the number of requests your application processes per second.
Key Operations: It lists the key APIs and operations which the particular application is serving.
Apdex: It is a score between 0 and 1 that helps you measure the user satisfaction.

Sort the List of Applications

You can switch the sorting order of the values in a column by clicking its heading: first click for ascending order, second click for descending order, and a third click to cancel the sorting.

SigNoz UI showing how to sort the applications in the Services Section — *Sort Applications*

Filter the List of Applications

You can add attributes to applications and filter based on these attributes.

SigNoz UI showing how to filter your application using attributes — *Attributes based filtering*

You can add attributes with OTEL_RESOURCE_ATTRIBUTES flag when starting the application. The below example shows how to set values for service.namespace and deployment.environment

OTEL_RESOURCE_ATTRIBUTES="service.name=flaskApp,service.namespace=sampleapps,deployment.environment=play" OTEL_EXPORTER_OTLP_ENDPOINT="http://3.11.144.34:4317"
OTEL_EXPORTER_OTLP_PROTOCOL=grpc opentelemetry-instrument python3 app.py

By default, you can filter based on service.namespace and deployment.environment dimensions.

To add custom filter dimensions in Services, update the dimensions section in the SigNoz OpenTelemetry Collector config and redeploy/restart the collector. See otel-collector-config.yaml for the full YAML example.

Global Time

Use the time range selector at the top right of the Services page to set the time frame for all metric columns. Options range from the last 5 minutes to the past week, with a custom date range picker.

SigNoz Services page showing the time range selector at the top right — *Global Time — select the time range for all service metrics*

Refresh Interval

Click the refresh dropdown next to the time range selector to control how often the Services page updates. You can enable Auto Refresh and choose an interval — from every 5 seconds up to once per day.

Click Share in the top-right corner to copy a shareable link to the current Services page — including the active time range and filters — so you can send it to a teammate and have them land on exactly the same view.

Share panel showing Enable absolute time toggle and Copy page link button — *Share — copy the current page link to share with your team*

How Services and RED Metrics Are Determined

We rely on the semantic conventions provided by OpenTelemetry. Every unique service.name configured and received is part of the service list.

A trace Request in SigNoz UI — *A typical trace request*

The following logic is used for the RED metrics generation of each service. In a distributed trace, a request goes through several entities performing various kinds of work. There is an entry point span for each service that took part in the trace journey. This can be thought of as a sub-root span for the service. This sub-root span can have many child spans which could be doing work in parallel or sequential or a combination of both. From an outside perspective this sub-root span work is an operation done by the service and how much time it took to complete this operation is the duration metric. For a web server, this is an API endpoint returning some data and request time is the duration metric. For a messaging consumer service, this is a consume trigger, and till it is done with the message received. For a mobile client application, this could be a button click to submit a form and the time taken to fulfill the request.

Operations/s - Number of sub-root spans seen for a service
PXX - Quantile of the duration of the sub-root spans
Error rate - Number of sub-root spans with status error / Total number of sub-root spans

Next Steps

Application Details — Explore latency percentiles, error rates, Apdex scores, and key operations for a specific service.
Database Calls — Monitor database call rate and latency for your services.
External Calls — Track outbound HTTP and gRPC call metrics.

Get Help

If you need help with the steps in this topic, please reach out to us on SigNoz Community Slack.

If you are a SigNoz Cloud user, please use in product chat support located at the bottom right corner of your SigNoz instance or contact us at cloud-support@signoz.io.