DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Telemetry Pipelines Workshop: Installing Fluent Bit From Source
  • Embracing the Future With Hybrid and Cloud-Native Observability: An In-Depth Exploration of Observability With Architectural Examples and Best Practices
  • Three Habits of Highly Effective Observability Teams
  • Simplifying Multi-Cloud Observability With Open Source

Trending

  • Throughput vs Goodput: The Performance Metric You Are Probably Ignoring in LLM Testing
  • Why Your QA Engineer Should Be the Most Stubborn Person on the Team
  • How AI Is Rewriting Full-Stack Java Systems: Practical Patterns with Spring Boot, Kafka and WebSockets
  • The Cost of Knowing: When Observability Becomes the Outage
  1. DZone
  2. Software Design and Architecture
  3. Cloud Architecture
  4. O11y Guide: Building an Advanced Dashboard

O11y Guide: Building an Advanced Dashboard

Get started using a basic template for a minimal dashboard from the previous lab and design components for your very first dashboard.

By 
Eric D.  Schabell user avatar
Eric D. Schabell
DZone Core CORE ·
Feb. 26, 23 · Tutorial
Likes (3)
Comment
Save
Tweet
Share
3.9K Views

Join the DZone community and get the full member experience.

Join For Free

The ongoing series covering my journey into the world of cloud-native observability continues in this article, where I'm continuing to explore an open-source dashboard and visualization project. If you missed any of the previous articles, head on back to the introduction for a quick update.

After laying out the groundwork for this series in the initial article, I spent some time in the second article sharing who the observability players are. I also discussed the teams that these players are on in this world of cloud-native o11y. For the third article, I looked at the ongoing discussion around monitoring pillars versus phases. In the fourth article, I talked about keeping your options open with open-source standards. In the fifth article in this series, I talked about bringing monolithic applications into the cloud-native o11y world. In my sixth article, I provided you with an introduction to a new open-source dashboard and visualization project and shared how to install the project on your local developer machine. In the seventh article, I explored the API and tooling provided by the Perses project. Then I spent time in the next article covering the open dashboard specification that you need to follow to start creating your first dashboard. Finally, in the previous article, you built your very first dashboard.

In this article, you'll flush out that first dashboard completing two rows of charts, gauges, and other components visualizing the performance of the target instance.

Being a developer from my early days in IT, it's been very interesting to explore the complexities of cloud-native o11y. Monitoring applications goes way beyond just writing and deploying code, especially in the cloud-native world. One thing remains the same: maintaining your organization's architecture always requires both a vigilant outlook and an understanding of available open standards.

This article is part of my ongoing effort to get practical hands-on experience in the cloud native o11y world. I'm going to get you started using a basic template for a minimal dashboard from the previous lab and start designing components for your very first dashboard. This is one lab in the more extensive free online workshop. Feel free to start from the very beginning of this workshop here if you missed anything previously:

Workshop: Getting started with Perses, intro slide

Now let's dive into designing your first dashboard. Note this article is only a short summary, so please see the complete lab found online as lab 4.6 to work through creating an advanced dashboard yourself:

Perses: Lab 4.6 slide

The following is a short overview of what is in this specific lab of the workshop.

Advancing the Dashboard

Each lab starts with a goal. In this case, it is fairly simple:

To build out your first basic dashboard, extend it with more components until you have an advanced dashboard with extensive metrics examples.

The lab kicks off with a view of what your server should be showing you after completing the previous lab. It's a dashboard with the first Memory Usage stat chart in the first role and nothing else. This lab jumps right in where you left off and you start adding a new Total Memory stat chart:

JSON
 
"statTotalMemory": {
  "kind": "Panel",
  "spec": {
    "display": {
      "name": "Total Memory",
      "description": "This is my second stat chart!"
    },
    "plugin": {
      "kind": "StatChart",
      "spec": {
        "query": {
          "kind": "TimeSeriesQuery",
          "spec": {
            "plugin": {
              "kind": "PrometheusTimeSeriesQuery",
              "spec": {
                "query": "node_memory_MemTotal_bytes{job='$job',instance=~'$instance'}"
              }
            }
          }
        },
        "calculation": "LastNumber",
        "unit": { "kind": "Percent" }
      }
    }
  }
}


Again, this is followed by an additional section added to the layouts section, which we will let the reader pursue in the lab online.

Note that in the workshop lab, you are given these code snippets as helpers; but I've also attempted to share proper testing and validation as you work towards a final dashboard using the provided CLI tooling:

$ ./bin/percli lint -f [PATH_TO_RESOURCE]/myfirstdashboard.json

your resources look good

$ ./bin/percli apply -f [PATH_TO_RESOURCE]/myfirstdashboard.json

object "Dashboard" "MyFirstDashboard" has been applied in the project "WorkshopProject"


Then verify that they were applied on your dashboard:

Perses WorkshopProject/MyFirstDashboard

You can see that your memory usage and total memory components are placed in the first row of your dashboard and report on the current values for the server instance selected.

You then continue on and add two gauges, used to visualize the same two metrics as the stat charts. Once you complete those sections your first row of this dashboard is looking pretty solid:

Perses dashbord two gauges to visualize the same two metrics as the stat charts

Next up, you create a new row and rename this first row while moving it to the second on your dashboard using the following adjustments to your layouts section:

JSON
 
"layouts": [
  {
    "kind": "Grid",
    "spec": {
      "display": { "title": "Line Chart Row", "collapse": { "open": true } },
      "items": []
    }
  },
  {
    "kind": "Grid",
    "spec": {
      "display": { "title": "Stat Chart Row", "collapse": { "open": true } },
      "items": []
    }
  }
]


Now you're ready to start adding some new metrics in line chart components:

Perses dashboard: adding some new metrics in line chart components

You add two new line chart components. The first is going to visualize memory totals from the target instance. The second visualizes the load on the instance and includes thresholds for indicating when values pass through the levels that require an alert. The reader is referred to the lab content to work through both of these line chart components and the final results should be as follows:

Perses dashboard: final results of this lab

This is where you finish up the lab and are ready to move on to the final part of the workshop. It's all been a good learning experience, and if you sit back, you'll be a little surprised at how far you've come in a short amount of time.

Open source Cloud native computing Observability

Published at DZone with permission of Eric D. Schabell. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Telemetry Pipelines Workshop: Installing Fluent Bit From Source
  • Embracing the Future With Hybrid and Cloud-Native Observability: An In-Depth Exploration of Observability With Architectural Examples and Best Practices
  • Three Habits of Highly Effective Observability Teams
  • Simplifying Multi-Cloud Observability With Open Source

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook