Skip to main content

Dashboard Usage

The dashboard is like the "cockpit" of KIWI. Just as a pilot checks all the instrument panels in the cockpit, you can check the status of all your services at a glance from the dashboard.

Why check the dashboard regularly?

Checking the dashboard regularly helps you catch problems early. Ignoring small warning signs can lead to major incidents later, so it's good to get in the habit of checking the dashboard a few times a day.

Accessing the Dashboard​

Path: [Dashboard] page (/dashboard)

This is the first screen you see after logging in. You can check the status of all services at a glance.

Tab Layout​

The dashboard consists of 4 tabs. Each tab shows service information from a different perspective.

Overview Tab​

This is the default tab you'll use most often. It provides a service status summary and quick action buttons.

Understanding Service Status​

Each service is displayed in a different color based on its current status. You can quickly understand the status just by looking at the colors.

  • Running (Green): Service is running normally. No action needed, leave it as is.

  • Building (Blue): Build is in progress. Please wait for completion.

  • Deploying (Blue): Deployment is in progress. Please wait for completion.

  • Build Failed (Red): Build failed. Check the log to identify the cause and fix the issue.

  • Deploy Failed (Red): Deployment failed. Check the settings or resource status.

  • Stopped (Gray): Service is stopped. Restart if needed.

  • Registered (Gray): Only registered, not yet built or deployed. Run build/deploy to start the service.

When you see red

If you see a red status (Build Failed, Deploy Failed), immediate attention is needed. Click on that service to check the logs, fix the issue, then run a rebuild or redeploy.

Quick Actions​

Click the buttons next to each service in the service list to run actions immediately.

  • Build: Build a Docker image from the latest source code.

    • Use this when you want to create a new version after modifying code.

  • Deploy: Deploy the built image to the selected environment.

    • Use this when you want to apply a new version to actual servers.

  • Restart: Restart the container/Pod of the running service.

    • This can help quickly recover from temporary issues.

Pipeline Tab​

This tab visually shows how a service flows from code to actual operation.

Source → Build → Deploy → Operate
What is a pipeline?

A pipeline refers to the series of steps code goes through from being written to becoming an actual service. Just like water flows through pipes, code passes through multiple stages to become a final service.

Let's look at what information you can see at each stage.

  • Source: Connected Git repository, branch, and latest commit information.

    • Check "what code is being used"

  • Build: Current build status and generated image tag

    • Check "if the Docker image was created successfully"

  • Deploy: Target deployment environment and deployment progress.

    • Check "where it's being deployed"

  • Operate: Status of running Pods or containers.

    • Check "if it's actually running well"

Quality Tab​

This tab shows the health of your code. The metrics displayed here indicate the maintainability of your code.

  • Test coverage: Shows what percentage of code is verified by unit tests.

    • Higher is better. 80% or above is recommended.

  • Code duplication: The ratio of similar code repeated in multiple places.

    • Lower is better. High duplication makes maintenance difficult

  • Technical debt: The amount of code that needs refactoring.

    • If technical debt accumulates, development speed slows down later.
To improve quality metrics

If test coverage is low, add unit tests. If code duplication is high, consider refactoring to extract common functions or components.

Security Tab​

This tab summarizes security analysis results from SAST, SCA, DAST, etc.

Types of security scans
  • SAST: Analyzes source code to find security vulnerabilities.
  • SCA: Checks for known vulnerabilities in the libraries you're using.
  • DAST: Finds vulnerabilities by attacking the running application.

  • Vulnerability status: Number of vulnerabilities by severity: Critical, High, Medium, Low

    • Critical and High should be addressed first

  • Distribution by service: See which services have the most vulnerabilities.

    • Focus attention on services with many vulnerabilities.

  • Recent scans: Most recent security scan history.

    • See when the last scan was performed.

  • Trend: Graph showing how vulnerability counts have changed over time

    • A decreasing trend is a good sign

Service List Table​

The heart of the dashboard is the service list table. Here you can see and manage the status of all services at a glance.

Column Descriptions​

  • Service name: Name of the registered service. Click to navigate to the detail page.

  • Status: Current status displayed as a badge. Quickly identify status by the color indicator.

  • Vulnerabilities: Number of vulnerabilities by severity. Click to navigate to the Security tab for details.

  • Last build: When the most recent build was run. Consider a new build if it has been a while.

  • Last deploy: When the most recent deployment was run. Use this to check deployment frequency.

  • Actions: Build/Deploy/Restart buttons. Click to run actions immediately.

Filtering​

When you have many services, it can be hard to find the one you want. Use the filter feature.

  • Status filter: Shows only services in specific states such as Running, Failed, and Stopped.

    • Example: Select Failed to show only services with issues.

  • Search: Search by service name to find services quickly.

    • You can search with just part of the service name
Efficient filter usage

During your morning check, apply the Failed filter first to check services with issues. It's much more efficient than checking every service one by one.

Metrics Panel​

On the right side of the dashboard, you'll find metrics panels showing your team's DevOps performance.

DORA Metrics Panel​

What are DORA Metrics?

DORA (DevOps Research and Assessment) metrics are DevOps performance indicators defined by Google Cloud's research team. They're based on research from thousands of teams worldwide, making objective comparisons possible.

These are the four key indicators for measuring DevOps performance.

  • Deployment Frequency: How often deployments are made. Recommended target is at least once per day.

  • Lead Time for Changes: Time from commit to deployment. Recommended target is within 1 hour.

  • Change Failure Rate: Percentage of deployments causing issues. Recommended target is 15% or less.

  • Time to Restore: Time to recover from incidents. Recommended target is within 1 hour.

For more details, refer to the DORA Metrics guide.

Deployment Metrics Panel​

This panel shows deployment activity at a glance.

  • Today's deployments: Number of deployments executed today
  • This week's deployments: Total number of deployments this week
  • Success rate: The ratio of successful deployments out of all deployments.
  • Average time: Average time from deployment start to completion.
If success rate is low

If your deployment success rate is below 90%, there may be issues with your deployment process. Analyze the logs of failed deployments to find common causes.

Real-World Usage Scenarios​

Let's see how to use the dashboard effectively in different scenarios.

Scenario 1: Morning Status Check​

The first thing you should do every morning when you arrive at work. Check if any issues occurred overnight.

Why is morning check important?

Builds may have failed or services may have had issues overnight. The earlier you discover them in the morning, the less impact on users.

Check sequence:

  1. Access the [Dashboard] page
  2. Scan the Status column in the service list
    • If you see red (Failed), there's an issue
  3. If there's a service in Failed state, click on it
  4. Check the build or deployment log to identify the cause.
  5. Fix the issue and run a rebuild or redeploy

Scenario 2: Security Posture Review​

Security vulnerabilities can be attack targets, so they should be reviewed periodically.

Review sequence:

  1. Click the Security tab in [Dashboard]
  2. First check if there are any Critical or High vulnerabilities.
    • These require immediate attention.
  3. Review the vulnerability distribution by service.
    • Focus attention on services with many vulnerabilities.
  4. Address vulnerabilities starting with the highest priority.
  5. After fixing, run a rescan to confirm resolution.
Critical vulnerabilities need immediate attention

Critical vulnerabilities are highly likely to be used in actual attacks. Immediately update the affected library or fix the vulnerable code.

Scenario 3: Deployment Performance Analysis​

Use this to analyze your team's DevOps performance in weekly meetings or monthly reviews.

Analysis sequence:

  1. Check the DORA Metrics panel in [Dashboard]
  2. Check which grade each indicator is at: Elite, High, Medium, or Low
  3. If any indicator is at Medium or Low, improvement is needed.
  4. Determine action items to improve those metrics.
Grade colors
  • Purple (Elite): Highest level, maintain current state.
  • Blue (High): Good level, room for some improvement.
  • Yellow (Medium): Improvement needed.
  • Red (Low): Immediate improvement needed.

Incident Management​

What is an Incident?​

What is an incident?

An incident refers to an unexpected event or problem situation. In IT, unexpected issues that affect services are called incidents. In KIWI, build failures, deployment failures, etc. are automatically recorded as incidents.

When a build or deployment fails, KIWI automatically creates an incident. This allows you to systematically track and manage issues.

Information included in an incident:

  • Title: Brief summary of the problem that occurred.

  • Service: Name of the service where the issue occurred.

  • Status: Open (unresolved) or Resolved (resolved).

  • Occurrence time: Time the incident was created.

  • Resolution time: Time resolved (displayed only if the incident has been resolved).

How to Handle an Incident​

Here's the sequence for handling an incident when you discover one.

  1. Check for Open status items in the incident list
  2. Click the incident to view detailed information.
    • You can see error logs, related deployment information, etc.
  3. Analyze the log to identify the root cause.
  4. Resolve the cause (code fix, configuration change, etc.)
  5. Once resolved, change the incident status to Resolved
What to do after resolving an incident

After resolving an incident, share with your team why the problem occurred and how it was resolved. This helps prevent the same issue from recurring.

Best Practices​

Here are recommended routines for effective service management.

Daily Routine​

Check three times a day

Morning, midday, and end of day. Just these three checks are enough to quickly discover most problems.

  • Morning: Check overall service status. This helps quickly discover any issues that occurred overnight.

  • Midday: Check security alerts. Review if any new vulnerabilities were discovered.

  • End of day: Check deployment activity and unresolved incidents. Ensure no issues arise before tomorrow.

Weekly Routine​

Weekly checks for team-level improvement.

  • Monday: Review DORA metrics to analyze last week's DevOps performance.

    • If metrics have worsened, identify the cause.

  • Friday: Reflect on incidents that occurred during the week

    • Discuss and document recurrence prevention measures.
Good habits produce good results

It may feel cumbersome at first, but once these routines become habit, you'll be able to discover problems early and respond quickly. Keep practicing consistently.