441 results found

1. Do not download EOL releases

   Currently our Ops Mgrs keep re-downloading EOL releases of mongodb, e.g. mongodb-linux-x8664-2.6.12, mongodb-linux-x8664-3.0.15, etc. Ops Manager should automatically exclude EOL releases - they are taking up unnecessary disk space.

   12 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Ops Manager  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Ops Manager API call for Host Mappings

   This feature request is for a new Group/Project API call for the management of the host mappings created in Ops Manager from monitoring information. Whether it be an endpoint for "Reset Duplicates" or full featured create/delete of individual host mappings, both will alleviate issues where overlapping mappings affect monitoring in Ops Manager.

   Note: The issue of overlapping mappings may occur when a mongod process has moved/changed IP addresses multiple times. With enough cycling (as seen in Kubernetes clusters with frequent pod restarts), eventually a previously mapped IP address may now be associated with a different mongod process.

   12 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Send `Monitoring is down` and `Backup is down` alerts for each MongoDB Agent (Monitoring/Backup Module) and include hostname information in

   What is the problem that needs to be solved? Monitoring is down and Backup is down alerts needs to be sent for each individual MongoDB Agent (Monitoring/Backup Module) which become down, Monitoring is down and Backup is down alerts should include hostname information in them.

   Why is it a problem? (the pain) Customer can't easily identify which MongoDB Agent (Monitoring/Backup Module) become down without hostname information available in the alert (in multi-project environment this becomes operational pain for the customer).

   12 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Monitoring / Alerts  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Allow assignment of Backup Resources before starting Backup Job

   For very large clusters, ideally backup resources should be assignable before the backup begins. For each shard and config server, assignment of the following would assist in scaling Ops Manager backups.

   • Snapshot Store
   • Oplog Store
   • Backup Daemon (if using FCV <= 4.0)

   Starting the backup could trigger an email to the Backup Administrator who could then assign these resources on the Admin page.

   12 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  Backup  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Support Arbiters with MongoDB Kubernetes Operator

   Support arbiters with MongoDB Kubernetes Operator so that Replicasets should be deployed in PSA configuration.

   12 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   under review  ·  0 comments  ·  Enterprise Kubernetes Operator  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Add Ops Manager's Org ID/Name into all SNMP Alert Traps

   What is the problem that needs to be solved? Ops Manager's Org ID/Name is not included into any of SNMP Alert Traps sent from Ops Manager's Application Server.

   Why is it a problem? (the pain) Operator who watch Monitoring System (the one that receive SNMP Alert Traps from Ops Manager) needs to see Ops Manager's Organization ID/Name in order to quickly understand to where that Ops Manager's Alert is related to. Monitoring System (the one that receive SNMP Alert Traps from Ops Manager) needs to do additional work for each SNMP Alert Trap received (via GET /groups/{PROJECT-ID}/GET /orgs/{ORG-ID} API calls (if possible at all)) in order to resolve Ops Manager's Project ID (which is included into every SNMP Alert Trap) into Ops Manager's Organization Name/ID.

   What is the problem that needs to be solved? Ops Manager's Org ID/Name is not included into any of SNMP Alert Traps sent from Ops Manager's Application Server.

   Why is it a problem? (the pain) Operator who watch Monitoring System (the one that receive SNMP Alert Traps from Ops Manager) needs to see Ops Manager's Organization ID/Name in order to quickly understand to where that Ops Manager's Alert is related to. Monitoring System (the one that receive SNMP Alert Traps from Ops Manager) needs to do additional work for each SNMP Alert Trap received (via GET /groups/{PROJECT-ID}/GET /orgs/{ORG-ID}… more

   11 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. Provide mechanism for internal password rotation of the automation user

   Ops Manager automation currently uses an mms-automation user for node management, but the password for that user is set once and stays forever unless it is updated via the Ops Manager API.

   This feature would provide a mechanism that allows this password to be re-generated via the UI or an API call and have it automatically updated on the managed mongod instances as well.

   11 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Automation  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. Create an option to turn ON/OFF daily snapshots schedule from "Ops Manager- Continuous Backup - Edit snapshot schedule"

   Currently, we have the option to take daily snapshots at different intervals (6 hrs, 8 hrs, 12, hrs, 24 hrs) but we do not have an option to not configure daily snapshots. While daily snapshots are considered essential, we have almost 200 replica sets of different DB sizes and the daily snapshots, tend interfere with itself due to large DB size and not completing itself in good time for the next day's daily snapshot to run. So if we turn off the daily snapshot or tune the frequency of the daily snapshots on select large replica sets, we will avoid the backup from failing and we can at least ensure the weekly full backup is successful on these very large DBs.

   Currently, we have the option to take daily snapshots at different intervals (6 hrs, 8 hrs, 12, hrs, 24 hrs) but we do not have an option to not configure daily snapshots. While daily snapshots are considered essential, we have almost 200 replica sets of different DB sizes and the daily snapshots, tend interfere with itself due to large DB size and not completing itself in good time for the next day's daily snapshot to run. So if we turn off the daily snapshot or tune the frequency of the daily snapshots on select large replica sets, we will avoid… more

   10 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Backup  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

9. SAML support in Ops Manager API

   SAML is available as an authentication mechanism and we're currently using it with keycloack (centralized identity provider).

   It works well with Ops Manager but there seems to be no support whatsoever in Ops Manager 4.4 API to programmatically add / update / delete SAML groups on Organizations or Projects.

   The official API documentation doesn't even recognize that SAML is available.

   Mongo support has confirmed that and it's a target feature in their internal backlog.
   This idea will hopefully speed up things.

   10 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   2 comments  ·  Automation  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

10. Ops Manager API - System Alerts

    The ops manager api documentation specifies endpoints for polling group alerts and global alerts but is missing system alerts. We should be able to poll for system alerts via the ops manager api as well.

    10 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Ops Manager  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

11. Allow the Kubernetes Operator to delete a project

    Currently it is not possible to delete a project via kubectl command.

    As the Kubernetes Operator allows one to create a project (configmap) and deploy a replica set, we would expect it to also allow the deletion of a project so that we can fully automate the solution.

    10 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Enterprise Kubernetes Operator  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    planned  ·  AdminDan (Admin, MongoDB) responded

    While deletion of a deployment is possible via Kubernetes, deleting a MongoDB resource doesn’t remove it from the Ops Manager UI. You must remove the resource from Ops Manager manually. To learn more, see Remove a Process from Monitoring.

    
    

    Deleting a MongoDB resource for which you enabled backup doesn’t delete the resource’s snapshots. You must delete snapshots in Ops Manager.

    
    

    Find out more.

    
    

    Work is planned to remove Ops Manager as a prerequisite (though it's use will still be optional and supported) and as part of that we hope to address this deletion aspect.

12. Add Timezone support to Ops Manager Application logs

    All of our hosts are in the same TZ. We would like to be able to set the Ops Manager related logs timestamps to our local TZ.

    10 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

13. MongoDB Agent (Automation Module): don't attempt to auth with `net.tls.clusterFile` / `net.tls.certificateKeyFile` and use Agent X.509 cert

    Problem Statement,
    What is the problem? MongoDB Agent (Automation Module) attempts to auth with net.tls.clusterFile / net.tls.certificateKeyFile X.509 certificate first, pretending it is a Replica Set member.

    Why is this a problem? MongoDB Server process logs are flooded by unnecessary noise from such MongoDB Agent (Automation Module) auth attempts pretending it is Replica Set member. MongoDB Server will always log Replica Set member auth certificate usage outside of internal MongoDB Server client (https://github.com/mongodb/mongo/blob/6212e50e73dd032b448a514fe6893c6490a28a9f/src/mongo/db/commands/authentication_commands.cpp#L294-L300),

    Example,
    {"t":{"$date":"2021-05-10T11:08:03.110+0000"},"s":"W", "c":"ACCESS", "id":20430, "ctx":"conn116","msg":"Client isn't a mongod or mongos, but is connecting with a certificate with cluster membership"}

    Proposal,
    * Don't attempt to auth with X.509 certificate from net.tls.clusterFile / net.tls.certificateKeyFile MongoDB Server parameters and use MongoDB Agent X.509 certificate configured.

    Problem Statement,
    What is the problem? MongoDB Agent (Automation Module) attempts to auth with net.tls.clusterFile / net.tls.certificateKeyFile X.509 certificate first, pretending it is a Replica Set member.

    Why is this a problem? MongoDB Server process logs are flooded by unnecessary noise from such MongoDB Agent (Automation Module) auth attempts pretending it is Replica Set member. MongoDB Server will always log Replica Set member auth certificate usage outside of internal MongoDB Server client (https://github.com/mongodb/mongo/blob/6212e50e73dd032b448a514fe6893c6490a28a9f/src/mongo/db/commands/authentication_commands.cpp#L294-L300),

    Example,
    {"t":{"$date":"2021-05-10T11:08:03.110+0000"},"s":"W", "c":"ACCESS", "id":20430, "ctx":"conn116","msg":"Client isn't a mongod or mongos, but is connecting with a certificate with cluster membership"}

    Proposal,
    * Don't attempt to auth… more

    9 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Automation  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

14. Add memory monitoring metrics

    Atlas -> please make buffers, cached, and MEM shared available under system memory metrics on Atlas for end users so we can calculate the criteria for auto scaling .

    Currently only Mongodb support can see these three metrics

    9 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Monitoring / Alerts  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

15. Disable Query Targeting: Scanned Objects / Returned alerts on specific, recurring aggregations.

    We run routine, recurring aggregation pipelines (essentially, summing up the values of different categories of transactions) on a 5-minute interval. These aggregation pipelines scan for all objects that match a certain type, then sum the cumulative value of certain values of those objects based on category. This means that we regularly have queries that scan >500,000 objects and consolidate them down to ~12 or so objects that are returned.

    In this specific case, I'm alright with the scan/return ratio being very high, and I don't want to be spammed with alerts every five minutes. However, I don't want to disable this alarm for all queries, just these recurring ones that I expect to have a poor ratio.

    We run routine, recurring aggregation pipelines (essentially, summing up the values of different categories of transactions) on a 5-minute interval. These aggregation pipelines scan for all objects that match a certain type, then sum the cumulative value of certain values of those objects based on category. This means that we regularly have queries that scan >500,000 objects and consolidate them down to ~12 or so objects that are returned.

    In this specific case, I'm alright with the scan/return ratio being very high, and I don't want to be spammed with alerts every five minutes. However, I don't want to disable… more

    9 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

16. Encrypt Password LDAP Query User

    The LDAP Query user's password appears in plain text in mongod.config file. The ability to mask its password in automation config file using credentialstool would mitigate a security risk.

    9 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Ops Manager  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

17. Configure MongoDB Automation Agent collecting stats on some collection to not trigger alerts

    We just had a support case about some alerts being raised on our cluster because the MongoDB Automation Agent collecting stats on some collection doing queries without index triggers "Scanned Objects / Returned" ratio has went over 1000.

    It would be really nice to at least not raise alerts when it's the mongodb automation agent that triggered it. Were monitoring our alerts a lot and these are false positive we can't do anything about it seems other than create all the indexes it needs, which might change over time. We have no guarantee of which index it needs.

    Another alternative would be to tell us in the performance advisor which index to create to avoid those.

    I'm not sure what's the right solution here, but the way this works right now is wrong.

    We just had a support case about some alerts being raised on our cluster because the MongoDB Automation Agent collecting stats on some collection doing queries without index triggers "Scanned Objects / Returned" ratio has went over 1000.

    It would be really nice to at least not raise alerts when it's the mongodb automation agent that triggered it. Were monitoring our alerts a lot and these are false positive we can't do anything about it seems other than create all the indexes it needs, which might change over time. We have no guarantee of which index it needs.

    Another alternative… more

    9 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    1 comment  ·  Automation  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

18. Introduce Helm Chart for MongoDB, MongoDBUser and secrets

    Provide a helm chart that deploys MongoDB, MongoDBUser, secrets and all other resources needed.

    The goal is to simplify the deployment of a MongoDB instance and everything that comes with it down to a helm one-liner.

    9 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    4 comments  ·  Enterprise Kubernetes Operator  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close
    started  ·  Andrey responded

    We have an example of a HELM chart that can deploy all resources.
    We will be working on adding more refined charts
    https://github.com/mongodb/mongodb-enterprise-kubernetes/tree/master/helm_chart

19. Improve Enterprise Kubernetes Operator PVC expansion

    The enterprise operator should be capable of performing all the steps necessary to increase the PVC after the end-user has adjusted the storage values within the MongoDB custom resource.

    Reference:
    https://www.mongodb.com/docs/kubernetes-operator/stable/tutorial/resize-pv-storage/

    Why is the Operator incapable of doing the steps starting from step 3 by itself if I simply do step 5?

    So what we think should be the case:

    We update the database resource with a new storage value.

    Then should perform the following steps:

    • Patch each persistence volume which can be found in the sts / pod spec.
    • Remove the sts with --orphan because the name should be known to the operator as it is the one controlling the sts.
    • Recreate the sts with the new volume size which is known as it is in the MongoDB custom resource.
    • And finally perform a rolling restart of the sts.

    We consider this to be an anti-pattern of the principle behind the enterprise operator as it is clearly stated:

    "You provide the MongoDB Enterprise Kubernetes Operator with the specifications for your MongoDB cluster. The MongoDB Enterprise Kubernetes Operator uses this information to specify to Kubernetes how to configure that cluster including provisioning storage, setting up the network connections, and configuring other resources."

    Most other DB operators for K8s support something like this already.

    The enterprise operator should be capable of performing all the steps necessary to increase the PVC after the end-user has adjusted the storage values within the MongoDB custom resource.

    Reference:
    https://www.mongodb.com/docs/kubernetes-operator/stable/tutorial/resize-pv-storage/

    Why is the Operator incapable of doing the steps starting from step 3 by itself if I simply do step 5?

    So what we think should be the case:

    We update the database resource with a new storage value.

    Then should perform the following steps:

    • Patch each persistence volume which can be found in the sts / pod spec.
    • Remove the sts with --orphan because the name should be… more
    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Enterprise Kubernetes Operator  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

20. Allow multiple authentication sources simultaneously

    Currently Ops Manager authentication supports either the Application Database, LDAP, or SAML, but these methods cannot be combined. Ideally we would like to move to LDAP, but we are stuck with the local authentication method as we depend on a local admin user which is used when first deploying and configuring the Ops Manager ecosystem. We also do not want to depend solely on the availability of the LDAP servers regarding an admin user. The MongoDB cluster deployments do support multiple authentication methods at the same time (we have local admin and monitoring accounts while users are authenticating via LDAP), it would be great if you could allow the same setup for Ops Manager.

    Currently Ops Manager authentication supports either the Application Database, LDAP, or SAML, but these methods cannot be combined. Ideally we would like to move to LDAP, but we are stuck with the local authentication method as we depend on a local admin user which is used when first deploying and configuring the Ops Manager ecosystem. We also do not want to depend solely on the availability of the LDAP servers regarding an admin user. The MongoDB cluster deployments do support multiple authentication methods at the same time (we have local admin and monitoring accounts while users are authenticating via LDAP),… more

    8 votes

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    2 comments  ·  Ops Manager  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close