Installing Apache SkyWalking: The ‘All-Seeing Eye’ for Microservices Monitoring from A-Z

Monitoring tutorial - IT technology blog
Monitoring tutorial - IT technology blog

Up and running in 5 minutes with Docker

If you want to quickly test SkyWalking without worrying about environment configuration, Docker Compose is the top choice. With just one configuration file, you’ll have the OAP Server (the processing brain) and the UI (monitoring interface) ready to go.

# Create docker-compose.yml file
version: '3.8'
services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.0
    container_name: elasticsearch
    environment:
      - discovery.type=single-node
      - ES_JAVA_OPTS=-Xms512m -Xmx512m
    ports:
      - "9200:9200"

  oap:
    image: apache/skywalking-oap-server:9.2.0
    container_name: oap
    depends_on:
      - elasticsearch
    links:
      - elasticsearch
    environment:
      SW_STORAGE: elasticsearch
      SW_STORAGE_ES_CLUSTER_NODES: elasticsearch:9200
    ports:
      - "11800:11800"
      - "12800:12800"

  ui:
    image: apache/skywalking-ui:9.2.0
    container_name: ui
    depends_on:
      - oap
    links:
      - oap
    environment:
      SW_OAP_ADDRESS: http://oap:12800
    ports:
      - "8080:8080"

Run the command docker-compose up -d and wait for about 60 seconds. Access http://localhost:8080; if the dashboard appears, you’re ready to rock.

What exactly is SkyWalking and why is it so ‘hot’?

As systems grow into dozens of microservices, debugging becomes a nightmare. A request passes through 20 services—where is the error? Why is the database responding slowly?

Previously, I often used the duo of Prometheus and Grafana. However, they are only strong in metrics like CPU or RAM. To see through the journey of each request (flow), we need Distributed Tracing. SkyWalking handles this gracefully with three main components:

  • SkyWalking Agent: “Embedded” in the application to collect data without you having to change a single line of code.
  • OAP Server: Receives data from the Agent, performs analysis, and pushes it into the database.
  • SkyWalking UI: Where visual charts and request traces are displayed.

The biggest plus is its support for multiple languages, from Java, Go, and .NET to Python. It even plays well with Service Meshes like Istio.

Installing SkyWalking on Linux (Production Ready)

For production use, I always prioritize installing directly on Linux to optimize resources. Here is the standard process I usually apply.

Step 1: Prepare the environment

OAP runs on the JVM, so you need JDK 11 or 17. Don’t forget to prepare Elasticsearch. Avoid using the default H2 if you don’t want the system to freeze up as data starts to grow.

# Check Java version
java -version

# Download the appropriate SkyWalking version (e.g., version 9.2.0)
wget https://archive.apache.org/dist/skywalking/9.2.0/apache-skywalking-apm-9.2.0.tar.gz
tar -xvzf apache-skywalking-apm-9.2.0.tar.gz
cd apache-skywalking-apm-bin

Step 2: Connect to Elasticsearch

Open the config/application.yml file. Find the storage section and point it to your Elasticsearch cluster:

storage:
  selector: ${SW_STORAGE:elasticsearch}
  elasticsearch:
    nameSpace: ${SW_NAMESPACE:""}
    clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:localhost:9200}
    user: ${SW_ES_USER:""}
    password: ${SW_ES_PASSWORD:""}

Step 3: Startup

SkyWalking comes with scripts to activate both OAP and UI simultaneously. Very convenient!

bin/startup.sh

# Monitor logs to ensure everything is running smoothly
tail -f logs/skywalking-oap-server.log

Note: The UI runs on port 8080, while the Agent pushes data to port 11800 (gRPC).

Attaching the Agent to Spring Boot: No code changes required

This is the most “magical” part. You just need to add JVM parameters when running the jar file. Data will automatically flow to the dashboard.

java -javaagent:/opt/skywalking/agent/skywalking-agent.jar \
     -Dskywalking.agent.service_name=order-service \
     -Dskywalking.collector.backend_service=10.0.0.5:11800 \
     -jar order-app.jar

In this command, service_name is the name displayed on the UI, and backend_service is the IP of the machine where OAP is installed.

Real-world experience: Don’t let Alert Fatigue overwhelm you

When I first set it up, I made the mistake of enabling Telegram alerts for everything. The result was a phone that buzzed constantly, causing me to ignore actual incidents. This is called Alert Fatigue.

My advice:

  1. Configure smart thresholds: Instead of using defaults, monitor the system for a week. If the average latency is 200ms, set the alert at 400ms (double the average).
  2. Prioritize alerts: If 5xx errors spike, alert immediately; if latency increases slightly, just aggregate it into a daily report.
  3. Optimize the alarm-settings.yml file: Leverage this file to filter out noise and avoid unnecessary junk alerts.

Storage optimization: Don’t let Elasticsearch ‘eat’ your entire hard drive

Tracing data is extremely storage-intensive. A mid-sized system can generate several GBs of logs per day. You need to configure TTL (Time To Live) in the application.yml file:

core:
  default:
    # Keep traces for 3 days, metrics for 7 days
    recordDataTTL: ${SW_CORE_RECORD_DATA_TTL:3}
    metricsDataTTL: ${SW_CORE_METRICS_DATA_TTL:7}

This keeps Elasticsearch lightweight, preventing you from having to stay up until 2 AM cleaning up the hard drive.

Conclusion

Despite being completely free, SkyWalking provides immense value for DevOps and Backend engineers. It gives us more confidence when deploying code. Just by looking at the Topology Map, you’ll immediately know where a request is bottlenecked. Good luck with your installation and mastering this ‘all-seeing eye’!

Share: