Database Monitoring Guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

A signal is a number with a person

Monitoring is a short list of numbers you will look at, and one of them that may wake someone. The health-check generator drafts a script. The KPI selector drafts a list. You delete what you will not read. A page at 3 a.m. for a number nobody understands is a page you have not finished.

Useful signals for a database you run include: is it accepting connections, is disk growing as the capacity note said, is replication lag inside the number the availability guide chose, and is the backup younger than the age you promised. You do not need twenty charts to know those.

The script runs on a host you administer, against the database you administer. It does not get a superuser if a narrower account can read the status. The security guide is that account. The script does not print passwords.

A green dashboard you have never compared to a real event is a picture. Cause one lab condition you understand, such as a stopped lab copy, and see the signal move. Then put it back.

Four signals, one of them allowed to page

Write four signals and the normal range for each, from the capacity, availability, and backup notes. Pick one that pages. The others are looked at in the morning. A backup older than the promise is a fair page. A chart that twitched is not.

Draft the check. Read it. Run it on the lab. Record the four numbers. Stop the lab condition you chose and see the matching number change. Start it again and see the number return.

Name the person who is paged and what they do first. The first action is a look, not a restart and not a failover, unless the availability guide already rehearsed that failover.

Keep the script where the next person can find it. A script only you can run is not monitoring.

A change you can finish

Production monitoring gains these four checks after the lab has shown a change and a return. You do not import a vendor dashboard of a hundred graphs in this window.

Rollback is disabling the new page, which you do once, so a noisy check can be silenced without deleting the history.

List four signals with normal ranges.
Choose the one that may page.
Read the drafted script. Narrow the account.
Run it on the lab and save the numbers.
Cause one lab change and watch the number.
Name the person and the first look they take.
Leave every other chart out.

Mistakes that outlive the command

database monitoring fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

A page with no owner.
Twenty signals and no ranges.
A superuser used only to read status.
A script that prints a password.
Paging on a lab test you forgot to undo.
A dashboard nobody caused a change on.
Restart as the first action.
Monitoring a database you do not administer.
The backup age missing from the list.
A check you cannot disable.

Decisions to write down before the window

One decision for database monitoring: Four signals have ranges. One may page. The others wait until morning. The account is as narrow as the status read allows. The lab showed a move and a return. The person paged is named. Their first step is a look. The script does not print secrets. Disable was practised. Backup age is one of the four, or its absence is a gap. Capacity and lag numbers match those guides. Production pages are not on until the lab pair worked. And one database is monitored in this window.

The hour you stop

Write the database name, the host, and the clock time before you change anything for database monitoring. If this database is serving people and you do not have a copy, this hour is a plan. A plan you can read tomorrow is a success. A change you cannot undo is not.

Use a lab or a restored copy. The rows you read are rows you are allowed to hold. You do not point a client at a database, a cluster, or an account you do not administer. The tools on this site run in the browser. They do not log in, and they do not scan.

prompt-for-this is a reminder that a secret is missing. It is not a password, a token, or a key you save. The real secret stays in the password store. If a connection string, a log, or a ticket still contains a live secret, stop and rotate it. Then delete the copy.

One change. A config line, an index, a grant, and a restore do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous file or the backup you already tested.

A second person reads the scope aloud: which host, which database, which account. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.

The lab listens on localhost. 127.0.0.1 is the address you bind until a firewall story exists. example.com is not your host. A generated file that listens on every address is a file you edit before it runs.

Do not run a statement you cannot undo. A delete or a drop without a backup and a where-clause you have read is the mistake this page is here to prevent. Read the statement. Count the rows it will touch. Then decide.

Keep the previous config and the previous dump. A generator draft is not the previous file. The previous file is what you put back if the new one is wrong. You practised the reload with a second session open when the change can lock you out.

If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied config produces a database nobody can explain. Rebuild the lab from the copy you kept.

When the checks pass, the next database waits until someone else can repeat the proof from the notes. database monitoring is done for this window when the proof is written, not when the client printed a prompt.

This page is a planning guide. It is not a vendor manual, not an official standard, and not legal advice. If an auditor must see the decision, they see the ticket and the evidence, not this paragraph.

Hand the finished note to the neighbouring guide that owns the next step, and leave this database alone until that guide has its own window.

Monitoring checks before a page can wake someone

Confirm this before you call the change done: The four ranges are written. The paging signal is one. The lab number moved and returned. The owner is named. The first action is a look. The script was read. No password appears in the output. The account is not a superuser unless you wrote why. Disable works. A second person saw the move. Backup age is included or filed as a gap. No extra charts were turned on. The hostname in the prompt matches the hostname in the ticket for database monitoring. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for database monitoring happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.