Introduction to UI

The SkyWalking official UI provides the default and powerful visualization capabilities for SkyWalking to observe distributed clusters.

The right top has the setup zone. User could set time range, time zone, auto refresh and language from there.


The dashboard provides metrics of services, service instances, and endpoints. Here’s a quick terminology guide on metrics:

  • Throughput CPM: Represents calls per minute.
  • Apdex score: See Apdex on Wiki.
  • Response Time Percentile: Includes p99, p95, p90, p75, and p50. See percentile on Wiki.
  • SLA: Represents the success rate. For HTTP, the response status code is default to 200.

The UI would check the local dashboard settings with the OAP backend in every 3 days, once inconsistent detected, a notification box would pop up asking for reload.

Custom Dashboard

Users may customize their dashboards. The default dashboards are provided in the default templates located in the /ui-initialized-templates folders.

The template file must end with .yml or .yaml. It follows this format:

  - name: template name # The unique name
    # DASHBOARD type templates could have multiple definitions, by using different names.
    # TOPOLOGY_INSTANCE, TOPOLOGY_ENDPOINT type templates should be defined once, 
    # as they are used in the topology page only.
    type: "DASHBOARD" 
    # Custom the dashboard or create a new one on the UI, set the metrics as you like in the edit mode.
    # Then, you could export this configuration through the page and add it here.
    configuration: |-
          "name":"Spring Sleuth",
              "children": [{
                "width": "3",
                "title": "HTTP Request",
                "height": "200",
                "entityType": "ServiceInstance",
                "independentSelector": false,
                "metricType": "REGULAR_VALUE",
                "metricName": "meter_http_server_requests_count",
                "queryMetricType": "readMetricsValues",
                "chartType": "ChartLine",
                "unit": "Count"
    # Activated means this templates added into the UI page automatically.
    # False means providing a basic template, user needs to add it manually on the page.
    activated: false
    # True means wouldn't show up on the dashboard. Only keeps the definition in the storage.
    disabled: false

NOTE: UI initialized templates would only be initialized if no template in the storage has the same name. Check the entity named ui_template in your storage.


A topology map shows the relationship between services and instances with metrics.

Global topology is shown by default, which means that all services are included.

  • Service Selector provides two-level selectors, service group lists, and service name lists. The group name is separated from the service name if it follows the <group name>::<logic name> format. Topology maps are available for single group, single service, or global (where all services are included).
  • Custom Group allows you to create sub-topologies for a service group.
  • Service Deep Dive opens when you click on any service. The honeycomb could carry out metrics, trace, and alarm query of the selected service.
  • Service Relationship Metrics provides the metrics of service RPC interactions and the instances of these two services.

Trace Query

Since SkyWalking provides distributed agents, trace query is a key feature.

  • Trace Segment List is not the same as a trace list. Every trace has several segments belonging to different services. If you start a query by all services or by trace IDs, different segments with the same trace ID may be listed there.
  • Span can be clicked. The details of each span will pop up on the left.
  • Trace Views provides three typical and different usage views to visualize the trace.


Profile is an interactive feature. It provides method-level performance diagnoses.

Make sure you have read the blog Apache SkyWalking: Use Profiling to Fix the Blind Spot of Distributed Tracing first. If you are using Python agent, the blog Python Agent Supports Profiling should be read too.

To start profile analysis, you need to create a profile task:

  1. Select the specific service.
  2. Set the Endpoint Name. This endpoint name is typically the operation name of the first span. Find this on the trace segment list view.
  3. Monitor Time could start right now or from any given future time.
  4. Monitor Duration defines the observation time window to find the suitable request to conduct performance analysis. Even though the profile has a very limited performance impact on the target system, it still amounts to an additional load. Setting this duration allows you to control the impact.
  5. Min Duration Threshold provides a filter mechanism. If a request of the given endpoint responds quickly, it will not be profiled. This ensures that the profiled data is the expected one.
  6. Max Sampling Count gives the maximum dataset to be collected by the agent. It helps reduce memory and network load.
  7. An implicit condition is that at any moment, SkyWalking only accepts one profile task for each service.
  8. Individual agents may have different settings to control or limit this feature. Read document setup for more details.
  9. Not all SkyWalking ecosystem agents support this feature. Java agent from version 7.0.0 supports this by default.

Once the profile is done, the profiled trace segments would show up, and you could request to analyze any span. Typically, we analyze spans with long self duration. If a span and its children both have long duration, you could set the analysis boundaries by choosing to Include Children or Exclude Children.

Choose the appropriate span, and click Analyze. You will see the stack-based analysis results. The slowest methods are highlighted.

Advanced features

  1. Since version 7.1.0, the profiled trace automatically collects the HTTP request parameters for Tomcat and SpringMVC Controller.


Since version 8.3.0, SkyWalking has provided log query for browser monitoring. Use Apache SkyWalking Client JS agent to collect metrics and error logs.

Since version 8.5.0, SkyWalking supports collecting logs through its native agents and third party agents (such as Fluentd and Filebeat). See Log Analyzer Document for more details.


The alarm page lists all triggered alarms. See backend setup documentation to learn how to set up alarm rules or integrate with third party systems.