# Junos System Monitoring and Maintenance

> Chapter 5 of the Courseiva JUNIPER-JNCIA-JUNOS curriculum — https://courseiva.com/learn/juniper-jncia-junos/junos-system-monitoring-and-maintenance

**Official objective:** 2.3 — Monitor system health, view logs, and perform system maintenance tasks.

## Introduction

Without system monitoring and maintenance, a Junos router will silently degrade until it crashes, taking down an entire company's internet access, email, and file servers — and you will not know why until angry users start calling. System monitoring and maintenance is the set of tools and routines that let you see the health of a Junos device in real time, investigate problems after they happen, and perform regular care to prevent issues. For the JNCIA-JUNOS exam, this topic ensures you know how to read the router's vital signs, search through its logs, and keep it clean and reliable.

## The House Alarm System Analogy

Your house, fully wired with sensors on every door and window, a smoke detector in the kitchen, and a panel in the hall that shows all the data. You are on holiday, and your neighbour texts you: "Your alarm panel is flashing a red light — is everything okay?"

You pull up the alarm's app on your phone. The app shows a timeline: at 2:17 AM, the smoke detector in the kitchen went off for three seconds, then stopped. At 5:43 AM, the front door sensor detected an open-and-close event but the security camera didn't capture movement. You check the logs. The kitchen smoke detector triggered because the fridge's defrost cycle created a tiny puff of steam. The front door sensor had a loose wire — a known issue you ignored last month.

The alarm system didn't just scream; it gave you a history of events, details about what happened, and a chance to fix the loose wire before it causes a false alarm that makes the police show up for nothing.

This is system monitoring: your router (the house) constantly collects events (logs) and health checks. An IT pro (you, from a distance) reviews these logs and performs maintenance (tightening the loose wire) to keep everything running smoothly. If you don't monitor, your network (the house) might suffer a real break-in (a cyberattack) or a fire (a system crash) that you could have prevented.

## Core explanation

Junos OS is the operating system that runs on Juniper network devices like routers, switches, and firewalls. To keep these devices working correctly, you must be able to check their health, look at what they have been doing, and fix small problems before they become big ones. This chapter covers three main activities: monitoring system health, viewing and analysing logs, and performing routine maintenance.

**Monitoring System Health**

System health means checking that the device's physical and software components are all working properly. Key health indicators include:
- **CPU usage** — how much of the processor's capacity is being used. High CPU can slow down routing decisions.
- **Memory usage** — how much RAM is occupied. Running out of memory can cause processes to crash.
- **Temperature** — the internal temperature of the device. Overheating can damage hardware.
- **Power supply status** — whether the device's power supplies are functioning and providing enough power.
- **Fan status** — whether cooling fans are spinning at the correct speed.
- **Storage space** — how much free disk space is available for logs, configurations, and software upgrades.

You use the command `show system health` to get a quick summary of all these metrics on some platforms. A more detailed command is `show chassis environment` which displays temperature, fan speed, and power supply status. For CPU and memory, you use `show system processes extensive` to see what processes are consuming resources.

**Viewing Logs**

Logs are chronological records of events that happen on the device. Junos logs everything from a user logging in to a routing protocol failing to a link going down. These logs are stored in files called **log files**, typically located in the `/var/log/` directory.

The most important log is `messages`, which contains general system messages. You view it with the command `show log messages`. The `show log` command reads a log file and displays its contents.

Logs are essential for troubleshooting because they tell you exactly what happened and when. For example, if a network interface goes down, a log entry will show the interface name, the time of the event, and often a reason code such as "link down" or "carrier loss".

Junos uses a system called **syslog** to generate and manage logs. Syslog assigns each message a severity level from 0 (emergency — system is unusable) to 7 (debug — detailed troubleshooting information). You can configure which events get logged and at which severity.

**Performing System Maintenance**

Maintenance keeps the device running reliably. Common maintenance tasks include:
- **Upgrading software** — installing a new version of Junos OS to get features and security fixes.
- **Rebooting the device** — restarting the system after a software upgrade or to fix an issue.
- **Cleaning log files** — deleting old logs to free up disk space. You can do this manually with `clear log <filename>` or configure automatic rotation.
- **Backing up the configuration** — saving the current settings so you can restore them if something goes wrong. The command `show configuration` outputs the config, and you can copy it to an external server using `scp` or `ftp`.
- **Checking file system health** — using commands like `show system storage` to see disk usage and `request system storage cleanup` to remove temporary files.

A critical maintenance command is `request system reboot`. This calmly shuts down all processes and restarts the device. A forced reboot (`request system reboot force`) is used if the system is unresponsive.

**Why It Matters**

Before network automation, engineers had to physically visit each device to check its health and read logs by plugging into a console port. Now, Junos provides remote monitoring through SSH, SNMP, and the command line. Proper monitoring means you can spot a failing power supply before it fails completely, or detect unusual log activity that indicates a security breach. Maintenance prevents problems — upgrading software closes known vulnerabilities, and cleaning logs prevents the disk from filling up, which would stop new logs from being written and might crash the system.

## Real-world context

You are the sole IT administrator for a mid-sized retail company with 50 stores across the country. Each store has a Juniper SRX firewall connecting back to the headquarters. One Tuesday morning, you get a call from Store #23 — the manager says the internet has been intermittent for two hours.

You start your investigation by opening an SSH session to the SRX at Store #23. Your first step is to check the system health. You run `show system health` and notice the CPU is at 95%. That is a red flag. You then run `show system processes extensive` and see that the process `flowd` (the firewall's packet processing daemon) is consuming 80% of the CPU. Something is causing the firewall to work too hard.

Next, you check the logs. You run `show log messages | match error` to find any error messages. The output shows hundreds of entries like:
```
Mar 15 09:23:01 srx-23 flowd[1234]: FLOW_CPUHIGH: Flow processing CPU usage exceeded 90%
```
This confirms the issue. You look further back in the log and see entries for a new software update that was pushed automatically at 3 AM — `junos-20.4R2` was installed. The update introduced a bug that causes high CPU when specific traffic patterns occur.

Now you perform maintenance. You need to downgrade the software to the previous version. Steps:
1. **Back up the current configuration** by running `show configuration | save /var/tmp/backup-config.txt`
2. **Download the old software image** to the device using FTP from the vendor's site: `file copy ftp://old-junos-image /var/tmp/`
3. **Request a reboot into the previous version** (which is stored in the alternate boot partition) using `request system software rollback`.
4. **Wait for the device to reboot** — you watch the process through the console or SSH.
5. **After reboot, verify health** by running `show system health` again. CPU is now 20% — normal.
6. **Check logs** — run `show log messages | match error` — no new CPU errors.

If you had not been monitoring health proactively, you might not have noticed the high CPU until the firewall crashed completely, causing hours of downtime. By checking logs, you identified the root cause (bad software update) and performed maintenance (rollback) quickly. This prevented a full outage and kept Store #23 operational.

## Exam focus

The JNCIA-JUNOS exam tests your knowledge of specific commands and their purposes, not rote memorisation of every option. Expect 5-8 questions on this objective. Here is what they look for:

**Commands to memorise by name and purpose:**
- `show system health` — quick check of CPU, memory, temperature, and power.
- `show chassis environment` — detailed hardware health (temperature, fan, power).
- `show system processes extensive` — detailed CPU and memory per process.
- `show log messages` — view the main system log.
- `show log <filename>` — view any log file under /var/log.
- `request system reboot` — graceful reboot.
- `request system software add` — install or upgrade software.
- `request system software rollback` — revert to a previous version.
- `request system storage cleanup` — free up disk space.

**Trap patterns they love:**
- They will ask which command shows CPU temperature. The trap is that `show system processes extensive` shows CPU usage per process, not temperature. The correct answer is `show chassis environment`. Many beginners confuse system health with chassis environment.
- They might ask about log severity levels. The trap is that they list all 8 levels and ask which one indicates a critical error. The correct answers for exam-critical levels are: `emergency` (0), `alert` (1), `critical` (2), `error` (3). Levels like `debug` (7) are for troubleshooting, not critical issues.
- They love to ask about the difference between a graceful reboot and a forced reboot. The correct pattern: `request system reboot` gracefully shuts down processes; `request system reboot force` is used when the system does not respond to a normal reboot.
- A common question: "Which log file contains general system messages?" The answer is `messages` (in /var/log/messages). Beginners might guess `syslog` (the protocol, not a file) or `logfile` (which does not exist by default).

**Key definitions to memorise:**
- Syslog — the protocol and service that generates and collects log messages.
- Log severity — a number from 0 (emergency) to 7 (debug) indicating the urgency of a message.
- Chassis — the physical hardware enclosure of the device.
- CoS (Class of Service) — not directly tested here, but do not confuse it with system health.

**Question types:**
- Multiple-choice single answer (most common).
- Multiple-choice multiple answer (select two or three correct commands).
- Drag-and-drop (match command to description).

Focus on knowing what each command does, not syntax details. The exam tests understanding, not memorisation of every flag.

## Step by step

1. **Check System Health** — Run `show system health` to get a quick overview of CPU, memory, temperature, and power status. This tells you if anything is obviously wrong — like 95% CPU or a critical temperature warning.
2. **Inspect Detailed Hardware Status** — Run `show chassis environment` to see each component's temperature, fan speed, and power supply status individually. This helps you pinpoint exactly which hardware part is failing.
3. **Review Logs for Errors** — Run `show log messages | match error` to filter the main log for error entries. This quickly highlights problems such as interface flaps, authentication failures, or process crashes.
4. **Analyse Process Resource Usage** — If high CPU or memory is detected, run `show system processes extensive` to see which specific process is consuming resources. For example, `flowd` consuming 80% CPU points to a firewall processing issue.
5. **Perform Corrective Maintenance** — Based on findings, take action: reboot gracefully with `request system reboot`, upgrade or rollback software with `request system software add` or `request system software rollback`, or clean disk space with `request system storage cleanup`. Always back up the configuration first.
6. **Verify After Maintenance** — After any maintenance action, re-run `show system health` and check logs again to confirm the issue is resolved. Document the steps and results for future reference.

## Comparisons

### show system health vs show chassis environment

**show system health:**
- Provides high-level summary of CPU, memory, temperature, and power
- May not show per-component temperatures
- Best for a quick health overview

**show chassis environment:**
- Shows detailed per-component readings (temperature, fan speed, power)
- Lists individual hardware modules like FPCs, fans, power supplies
- Best for diagnosing specific hardware failures

### syslog (protocol) vs log file (/var/log/messages)

**syslog (protocol):**
- A protocol for sending and receiving log messages across the network
- Can send logs to an external server (e.g., Splunk)
- Not a storage file itself

**log file (/var/log/messages):**
- A specific file that stores log entries on the local device
- Visible with `show log messages`
- Can be rotated and cleared locally

### Graceful reboot (request system reboot) vs Forced reboot (request system reboot force)

**Graceful reboot (request system reboot):**
- Shuts down processes in an orderly manner
- Waits for processes to finish cleanly
- Can fail if the system is unresponsive

**Forced reboot (request system reboot force):**
- Immediately halts all processes
- Bypasses clean shutdown procedures
- Used only when the device does not respond to a normal reboot

## Diagram

_A flowchart showing the three branches of Junos system monitoring and maintenance: health check, log review, and maintenance actions._

```mermaid
flowchart TD
    A[System Monitoring] --> B[Health Check]
    A --> C[Log Review]
    A --> D[Maintenance]
    B --> E[Show system health]
    B --> F[Show chassis environment]
    B --> G[Show system processes extensive]
    C --> H[Show log messages]
    C --> I[Show log <filename>]
    D --> J[Request system reboot]
    D --> K[Request system software rollback]
    D --> L[Clear log <filename>]
```

## Common misconceptions

- **Misconception:** If you run `show system health`, you will see detailed per-process CPU usage. **Reality:** `show system health` shows overall CPU usage percentage, not per-process. Use `show system processes extensive` for per-process data. (Beginners expect a health command to show everything, but Junos splits health metrics across multiple commands.)
- **Misconception:** The `messages` log file is the only important log, so you do not need to look at other logs. **Reality:** There are many log files like `interactive-commands` (who logged in and what they typed), `chassisd` (hardware events), and `auth.log` (authentication attempts). All can be useful. (Exam candidates often fixate on one file and miss that other logs contain more specific data.)
- **Misconception:** A reboot is always the same — it just turns the device off and on. **Reality:** Junos has a two-part boot with two software partitions. `request system reboot` uses a graceful shutdown. `request system software rollback` switches partitions. The behaviour differs depending on the command. (General experience with home routers creates a simplistic view of rebooting, but Junos has deliberate failure recovery mechanisms.)
- **Misconception:** Log files are automatically cleaned up and never cause problems. **Reality:** Log files can fill up the disk, causing new logs to be dropped. You must monitor disk usage with `show system storage` and manually clean logs with `clear log` or `request system storage cleanup`. (Beginners assume log rotation is always configured, but on new devices it often is not, leading to disk-full issues.)
- **Misconception:** `show system processes extensive` and `show system health` show the same information. **Reality:** `show system health` shows global health (CPU, memory, temperature, fan). `show system processes extensive` shows every running process with its own CPU and memory usage. (Both contain the word 'system' so novices think they are redundant, but they serve different monitoring purposes.)

## Key takeaways

- System monitoring checks CPU, memory, temperature, power supplies, and fans to prevent hardware failure.
- Logs are stored in /var/log/; the most important default log is `messages` which records general system events.
- Use `show chassis environment` to view detailed hardware health — temperature, fan speed, and power supply status.
- The `request system reboot` command gracefully shuts down processes; `force` is only for unresponsive systems.
- Syslog severity levels range from 0 (emergency) to 7 (debug); levels 0–3 indicate serious issues.
- Regular maintenance includes backing up configurations, cleaning log files, and checking disk space with `show system storage`.
- A `show log messages | match error` command quickly filters logs to find errors without reading every line.
- Software rollback (`request system software rollback`) reverts to the previous Junos version and is critical when an upgrade causes problems.

## FAQ

**What command shows CPU temperature on a Juniper router?**

`show chassis environment` shows the temperature of the chassis components. `show system health` may show temperature on some platforms, but `show chassis environment` is the most reliable command.

**How do I view log files on Junos?**

Use `show log <filename>`. For example, `show log messages` shows the main system log. To search for specific text, add `| match <pattern>`: `show log messages | match error`.

**What does syslog severity level 0 mean?**

Level 0 is 'emergency' — the system is unusable. It is the most critical severity level. Levels 0–3 are considered serious and should be investigated immediately.

**Can I reboot a Juniper device without losing the configuration?**

Yes. A normal reboot (`request system reboot`) restarts the device and loads the saved configuration from the active partition. Configuration is stored in flash memory and persists across reboots.

**What is the difference between 'show system health' and 'show chassis environment'?**

`show system health` gives a high-level summary of CPU, memory, temperature, and power. `show chassis environment` gives detailed per-component readings for temperature, fan speed, and power supplies.

**How do I clear log files to free up disk space?**

Use `clear log <filename>` to remove the content of a specific log file. For example, `clear log messages` empties the messages log. You can also run `request system storage cleanup` to delete temporary files.

## Check your understanding

1. **Which command do you use to view the CPU temperature of individual hardware components on a Juniper device?**

   Answer: `show chassis environment` — it displays detailed temperature readings per component.

2. **What severity level does syslog assign to a message indicating the system is unusable?**

   Answer: Level 0, which is called 'emergency'.

3. **You want to see all error messages in the main system log. What command do you run?**

   Answer: `show log messages | match error` — this filters the messages log to show only lines containing the word 'error'.

4. **After a software upgrade causes problems, how do you revert to the previous Junos version?**

   Answer: Use `request system software rollback` — this reboots the device into the alternate Junos partition.

5. **What is the purpose of the `request system storage cleanup` command?**

   Answer: It removes temporary files and unused data to free up disk space on the device.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/juniper-jncia-junos/junos-system-monitoring-and-maintenance