- Administer Ops Manager >
- Administration Overview
Administration Overview¶
On this page
Introduction¶
If you have administrative privileges for the Ops Manager deployment, click the Admin link in the top right corner of Ops Manager to access the system administration tool. This page describes the system administration interface. For configuration settings, see Ops Manager Configuration.
General Tab¶
The General tab gives access to system topology, users, messages, and other information.
Overview Page¶
This page displays the Ops Manager network topology and provides reports on system use and activity.
Ops Manager Config¶
The General tab’s Ops Manager Config page lets you update your Ops Manager settings. For information on each field, see Ops Manager Configuration.
Users Page¶
This page displays a list of user information for all people with permission to use the Ops Manager application as well as provides an interface to manage users. Use the search box on the upper right corner to find a user record. The Last Access column displays the date and time of the last access event.
To edit a user record:
Click the pencil icon at the far right of the user record.¶
Change any desired parameters in the Edit User interface.¶
| Section | Possible Values |
|---|---|
| Two Factor Authentication | Change how the user can enable two factor authentication. You can either add or change their Mobile Number. You can also indicate if the user’s Google Authenticator has been configured. |
| Profile Info | Change the user’s email address. |
| Projects and Roles | Add or remove the user from one of the roles for each group in the Ops Manager Application. |
| Actions | Disable a user’s ability to use Ops Manager. Lock Account prevents the user from logging into Ops Manager. Clear Two Factor Auth disables two factor authentication for the user. |
| Global Roles | Add or remove the user from one of the roles that apply across all groups in the Ops Manager Application. |
To save these changes, click Save.¶
To delete a user record:
Click the trash can icon at the far right of the user record.¶
Click Delete.¶
Projects Page¶
This page in the Admin interface lists groups, their creation dates, and their last pings from agents.
| Task | Procedure |
|---|---|
| To view a group’s details: | Click the group name. |
| To delete a group: | Click the group’s trash icon. |
| To edit a group’s tags: | Click the pencil icon in the Tags column. A project can have up to 10 tags. Tags follow these rules:
|
| To edit a group’s metric data retention policy: |
|
Logs Page¶
This page lists backup logs by job and class with messages grouped and counted by last hour, 6 hours, and last 2 days. Click a count number to see all messages in the group.
Version Manifest Page¶
This page lists all released MongoDB versions. Ops Manager requires this list to run in local mode. See the Configure Local Mode for Ops Manager Servers without Internet Access tutorial for more information.
Messages Page¶
This page displays messages you have added to the Ops Manager interface. You can add a message to any page of the Ops Manager interface to notify users of information and events, such as impending maintenance windows. To add messages, see Add a Message to the Interface
Audits Page¶
This page displays all events tracked by Ops Manager. This includes the group events as well as internal and system events, which are not tracked at a group level.
Backup Tab¶
The Admin interface’s Backup tab provides information on Backup resources, including jobs, daemons, and blockstores. For an overview of Backup and Backup resources, see Backup Process.
Jobs Page¶
This page lets you manage Backup jobs and Backup resources for each group. The top part of the page displays Active Jobs and the bottom part displays Stopped Jobs. The following fields on the page have a yellow background if delayed:
- Last Agent Conf, if older than 1 hour.
- Last Oplog, if older than 1 hour before the Last Agent Conf.
- Head Time, if older than 1 hour before Last Oplog.
- Last Snapshot, if older than the snapshot interval multiplied by 1.5.
Manage Backup Jobs¶
From the Jobs page, you can do the following:
| Task | Procedure |
|---|---|
| Assign a group to particular set of Backup Daemons or blockstores. | Click the group, select the daemons or blockstores, and select Save Changes. |
| View a job’s log. | Click the name of the job and then click the Logs link. Contact MongoDB Support if you need help interpreting the error message. |
| View information about a job. | Click the job. From the job’s page you can access logs, conf calls, and other information, and you can download diagnostics. |
| Move a job to a new Backup Daemon. | Click the job. On the job’s page, click the Move head link, select the new head, and click the Move Head button. |
| Filter the page to display the jobs assigned to a particular daemon or blockstore. | Click the name of the daemon or blockstore. |
| Toggle whether a job journals its head database. | Select or clear Journal Head to turn on or off journaling for your head database. Note Changing this setting at the job level overrides the deployment-wide setting. See |
Manage Backup Resources¶
From the Jobs page, you can assign backup resources to a particular group.
You can make these changes for existing backups, but only new backup jobs will follow the new rules. Making these changes does not affect existing deployments. For additional procedural information, see Move Jobs from a Lost Backup Daemon to another Backup Daemon.
| Task | Procedure |
|---|---|
| Assign a group to particular daemons, blockstores or oplog stores. | Click the group to open the group’s assignment page; make the assignments; select Save Changes. |
| Assign a group to a labelled set of daemons, blockstores, and oplog stores. | First assign the label on the Admin page for each resource. See Daemons Page, Snapshot Storage Page, and Oplog Stores Page. Then, on the Jobs page:
|
Job Timeline Page¶
This page displays a graphical representation of information found on other Admin pages, in particular the Jobs page. The Job Timeline page displays critical timestamps (head, last snapshot, next snapshot) and offers a way to assign a daemon to a given job.
Click the Auto refresh checkbox to update the list automatically every 10 seconds. Click the Refresh button to refresh data manually.
To view the backup job JSON, click the Show JSON link under the Project heading for any backup job. When the JSON displays, click the View raw runtime data link under the code to view the raw data. To hide the daemon JSON, click the Hide JSON link.
To move the job to a new Backup Daemon, click the Move head link under the Machine heading for a backup job. Select the location and click the Move head button to move the job to a new Backup Daemon. Ops Manager does not automatically move jobs between daemons.
You can bind a backup job to a head by clicking Set binding under the Machine heading for a backup job. You can bind a job to a preferred Backup Daemon during initial sync. After initial sync completes, Ops Manager automatically assigns jobs to Backup Daemons.
Logs Page¶
This page lists backup logs by job and class with messages grouped and counted by last 2 hours, last day, and last 3 days. Click a count number to see all messages in the group.
Restores Page¶
This page displays the last 100 requested restores and their progress. To show all restores ever requested, click Show All.
Resource Usage Page¶
This page provides key size and throughput statistics on a per-job basis for all groups for which Backup is enabled. The page displays the size of the data set, how active it is, and how much space is being used on the blockstore.
To export the information, click Export as CSV.
Grooms Page¶
This page lists active and recent groom jobs. Groom jobs remove unused blocks on blockstores and S3 Snapshot Stores to reclaim storage space. If no existing snapshots reference a given block, it is considered unused. Ops Manager grooms blockstores at least once a year and S3 snapshot stores at least every two weeks.
A groom job forces the backup process to:
- write all new data to a new location,
- copy all existing, needed data from the old location to the new one,
- update references, to maintain data relationships, and
- drop the old database.
During groom operations, you may notice that blockstore file size will fluctuate, sometimes dramatically.
You can manually direct Ops Manager to move blocks between blockstores through the Groom Priority Page.
You can also Configure Block Size in a Blockstore.
Groom Priority Page¶
This page displays a list of the status of all of the backup jobs and their blockstores. There are three types of jobs that run to maintain a blockstore:
- Tracking jobs
- Scheduled to run every three days unless a previously scheduled blockstore job has not finished in that time. Tracking jobs also are scheduled to run immediately after a groom job. Tracking jobs determine the current ratio of living to dead blocks in blockstores.
- Groom jobs
- Scheduled to run when the ratio of living to dead
bytes drops below
0.45. To learn more about grooming, see Groom page - Integrity Check Jobs
- Scheduled to run every seven days unless a previously scheduled blockstore job has not finished in that time. These checks make sure that the blockstore has no data integrity issues.
Each blockstore can run only one blockstore job (groom, track, or
integrity check) at a time unless you change its
Load Factor. The Load Factor sets
how many jobs that a blockstore can run at the same time. It is set to
1 by default.
To learn how to change the Load Factor, see Edit a Blockstore.
Each row in this table lists a backup job. Its background color indicates if the state of its associated blockstore is accurate and current.
| Color | Blockstore Storage Usage Status |
|---|---|
| Blue | Amount of blockstore storage usage is changing. Blockstore groom job is in progress. |
| Green | Amount of blockstore storage usage is accurate. Blockstore has run a tracking job since last groom job ran. |
| Red | Amount of blockstore storage usage is stale. Blockstore has run a groom job since its last tracking job ran. |
Manual Blockstore Maintenance¶
From this page, you can also perform three kinds of blockstore maintenance manually:
- Move Blocks to a Different Blockstore
- To move a backup’s chunks to a different blockstore, select the destination blockstore in the backup’s Blockstore List column. You might want to do this if you add a new blockstore and would like to balance data.
- Groom a Blockstore
- To initiate a groom job, click Schedule in the Groom Action column for the blockstore replica set you want to groom. You should not need to manually schedule groom jobs. Ops Manager runs the jobs automatically.
- Check Blockstore Integrity
- To initiate an integrity check, click IntegCheck in the Integrity Action column for the blockstore replica set you want to check. The Integrity Schedule Result modal appears and displays the status of the blockstore.
See also
Daemons Page¶
This page lists all active Backup Daemons and provides configuration options. Ops Manager automatically detects Backup Daemons and displays them here. You can reconfigure daemons from this page. Changes can take up to 5 minutes to take effect.
Click Pre-Configure New Daemon at the bottom of the page if
you want to add a daemon but do not want it to take new jobs. Type the
<machine>:<roothead path> in the text field above
Pre-Configure New Daemon. Click the button to configure the
new Backup Daemon.
For each daemon, the page lists the server name, configuration, head space used, head space free, the number of replica sets backed up, the percentage of time the Backup Daemon Service was busy, and job runtime counts by 1 minute, 10 minutes, 60 minutes, less than or equal to 180 minutes, and greater than 180 minutes.
The page includes the following fields and links to manage and configure daemons:
| Field | Description |
|---|---|
| Show Detailed JSON | Displays the Backup Daemon JSON. When the JSON displays, the View raw runtime data link appears under the code, allowing you to view the raw data. |
| Move all heads | Moves all the Backup Daemon jobs that live on this daemon to a new daemon location.
|
| Delete Daemon | Deletes a Backup Daemon. |
| Assignment | Allows the daemon to process more jobs. If the daemon’s disk fills, clear this so the host is not overloaded. |
| Backup Jobs | Allows the daemon to process more backup jobs. Clear this when performing maintenance on a daemon’s host. |
| Restore Jobs | Allows the daemon to process restore jobs. If you select this box and clear Backup Jobs, the daemon fulfills restore requests exclusively. Clear this when performing maintenance on a daemon’s host. |
| Resource Usage | Collects information on blockstore use (i.e., which snapshots still reference how many blocks). Ops Manager uses this information to generate the Resource Usage Page page and to prioritize garbage collection. |
| Garbage Collection | Allows the daemon to schedule groom jobs to remove unused blocks and expired snapshots. |
| Head Disk Type | Indicates whether the disk type is SSD or HDD. If you change a daemon to SSD, then only jobs with an oplog greater than 1GB/hour will go to this daemon unless no HDD daemon is available. Jobs with an oplog less than 1GB/hour can go to this daemon only if no HDD daemon is available. Warning If you run Ops Manager 2.0.3 or earlier, jobs with an oplog less than 1GB/hour cannot be bound to an to SSD-backed daemon. |
| Assignment Labels | Creates one or more labels that can be used to assign the daemon to a specific group. |
| Number of Workers | Number of concurrent backup tasks processed at a time. To query a snapshot of a sharded cluster, the
Backup Daemon requires at least one worker for the
config server, one
worker for each shard, and one worker for each
To query a snapshot of a replica set, the Backup Daemon requires at least one worker for the replica set. Example If you restore a queryable backup from a 3-shard cluster with
1 shard router (mongos), you would need this value to
be at least
When the queryable backup begins, the Backup Daemon spins up 5 or more workers to manage these components. |
Snapshot Storage Page¶
MongoDB database backups called snapshots and they are stored in containers called snapshot stores. This page lists existing snapshot stores and allows you to create or modify snapshot stores.
Ops Manager supports the following snapshot stores:
- On a File System,
- In a MongoDB database (blockstore), or
- In an S3 Bucket (S3 blockstore)
| Storage Method | Name | Description |
|---|---|---|
| File System | File System Store | Snapshots are stored in a directory on a file system. Each snapshot is found in its own sub-directory. The snapshot files are compressed individually. To create or edit a file system store, see Manage File System Snapshot Storage. |
| Database Storage | Blockstore | Snapshots are stored in a managed MongoDB database in a compressed, de-duplicated format. Depending on data usage patterns the deduplication can provide significant storage savings without the need for any specialized hardware or other software. To create or edit a blockstore, see Manage Blockstore Snapshot Storage |
| AWS S3 Bucket | S3 Blockstore | Snapshot data is stored as blocks in an AWS S3 bucket. Snapshot metadata is stored in a managed MongoDB database. The metadata database tracks which blocks comprise each snapshot. The blocks are compressed and de-duplicated. To create or edit an S3 blockstore, see Manage S3 Blockstore Snapshot Storage |
You can add, edit or delete any snapshot store listed.
Additional Information¶
For additional information on managing snapshots, see:
- Manage Blockstore Snapshot Storage
- Manage S3 Blockstore Snapshot Storage
- Manage File System Snapshot Storage
- Assign Snapshot Stores to Specific Data Centers
- Configure Block Size in a Blockstore
- Groom Priority Page, to manually direct Ops Manager to move blocks between blockstores
Oplog Stores Page¶
This page configures the backing replica sets that store oplog slices. Oplog slices are compressed batches of the entries in the tailed oplogs of your backed-up deployments.
Warning
Do not modify the oplog store’s connection string to point to a different replica set. Existing data will not be copied and a resync will be required.
From this page you can:
- Add a member to a replica set by adding the host to the replica set connection string in the <hostname>:<port> field. Do not modify the connection string to point to a different replica set.
- Change the authentication credentials or connection options for a oplog store by modifying the appropriate fields.
- Add an additional oplog store by clicking the Add New Oplog Store button at the bottom of the page.
- Enable and disable new assignments to oplog stores using the checkboxes in the Assignment Enabled column.
- Assign labels that can be used to assign the oplog store to a specific group. Enter labels in Assignment Labels. Separate multiple labels with commas.
After saving changes to the oplog store’s values, you must restart all the Ops Manager instances, including those running activated Backup Daemons, for the changes to take effect.
Alerts Tab¶
The Admin interface’s Alerts tab sets and displays global and system alerts. Global alerts apply a group-level alert condition to multiple groups. System alerts monitor the health of Ops Manager.
Control Panel Tab¶
Message History Page¶
This page displays alert messages sent and the recipients. To filter the list, click Filter by Recipient.
Send Test Message¶
Use this page to send messages to users to test validity of their addresses.
Server Pool¶
This page allows for the administration of the server pool.
Servers¶
The Servers tab allows Administators to view information regarding servers in the pool, such as availability, as well as cancel pending requests and recycle servers that have been terminated but not returned to the pool. The Servers tab provides three views:
| View | Description |
|---|---|
| Server List | Lists servers in the pool and their availability (i.e. whether they are bound to a specific Ops Manager group or unbound). From this list, Administrators can terminate unbound servers. For servers bound to a group, owners of the group can terminate the servers from their Deployment view. |
| Pending Requests | Lists the pending requests. Administrator can cancel pending requests from this view. |
| Recycle Bin | Lists terminated servers that have not been returned to the pool. From this view, Administrator can recycle terminated servers to return them to the pool. If the list of terminated servers exceed the list displayed on the current page, Recycle All recycles all terminated servers in the recycle bin, not just the servers displayed on the current page. |
See also
Servers Request Options¶
The Servers Request Options tab allows Administrators to
control which server options are displayed to the users when users make
a server request. These options are the properties and values specified
in the serverPoolPropertiesFile file.
See also
Agent Configuration¶
The Agent Configuration tab displays the
serverPoolKey needed to configure the Automation Agent for
a server to be added to the server pool.