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.
Jump to a section
A simple way to picture Junos System Monitoring and Maintenance
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
These come up on the exam all the time. Here's how to tell them apart.
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)
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)
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
Mistake
If you run `show system health`, you will see detailed per-process CPU usage.
Correct
`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.
Mistake
The `messages` log file is the only important log, so you do not need to look at other logs.
Correct
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.
Mistake
A reboot is always the same — it just turns the device off and on.
Correct
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.
Mistake
Log files are automatically cleaned up and never cause problems.
Correct
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.
Mistake
`show system processes extensive` and `show system health` show the same information.
Correct
`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.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
`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.
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`.
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.
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.
`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.
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.
You've finished Junos System Monitoring and Maintenance. Continue through the JNCIA-JUNOS study guide to build a complete picture of the exam.
Done with this chapter?