411 results found

1. “Content-Security-Policy” header

   Hello,

   We want to add the “Content-Security-Policy” header to the OpsManager/MongoDB answers to increase the security level:

   frame-ancestors 'none' (Do not render in frames)
   script-src 'self': only loads scripts originating on the site (subdomains excluded)
   default-src 'none': recommended for services returning HTML.
   Could you please tell us how to set up these elements ?

   Thank you in advance for your support.

   Regards

   7 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. Add addition authentication mechanisms to the Ops Manager Alerting webhook

   Capability to use JWT or SSL certs would be great.

   7 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

3. Consider supporting the installation of mongosh via Ops Manager/automation agent

   Today, it is possible to install MongoDB software (mongoimport/export, mongodump/restore, mongo, bi connector) from Ops Manager via the automation agent.

   Ideally, it will be possible to have the same experience for the new MongoDB Shell (mongosh), so that customers don't need to put in place a separate set of processes nd scripts to install it.

   7 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

4. 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

   7 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

5. Allow Webhook notifications for System Alerts

   Webhooks are available for Project and Global Alerts. However they are not available for System Alerts.

   It would be ideal to be able to use Webhooks for all alerts.

   •  

   7 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

6. Ops Manager Prometheus metrics

   MongoDB Ops Manager would need to expose endpoints for Prometheus for MongoDB Clusters. There are a number of metrics that popular MongoDB Exporters do not provide, for example:
   1. Enterprise Backup status
   2. Replication Alarms
   3. Agent statuses
   4. A number of Cluster statuses
   etc

   There is no way to get this data into Prometheus at the moment

   7 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. Ops Manager

   In Ops Manager ,Whenever we do changes in the configuration the deployed mongodb instnaces ,GUI prompt for Review & Deploy ,If we have a provision for schduling the deployment in later time would fullfil the real Automation.

   • Do the changes at convenient time
   • Do deploy thru a schedulers
   7 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

8. Add collection level statistics to the measurements API

   Get Database Measurements currently provides information from dbStats.

   Adding collection level statistics would be useful for gathering information via the API on a regular basis to measure growth of each collection and other metrics. Data Explorer functionality is not available via the API.

   7 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

9. Ability to customize subject line for System & Global Alerts

   Currently there's no way to customize the subject line of either a system or global alert. The subject line only has the project name & time. It doesn't even say why the alert was generated until the email alert is opened. Having the ability to modify the subject line, even if it's to certain predefined fields such as alert condition for example would be helpful in addressing alerts in an efficient and effective manner.

   7 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

10. Ability to turn on/off MongoDB Agent auto-update in specific/all Cloud Manager/Atlas Project(s)

    What is the problem that needs to be solved? Ability to turn on/off MongoDB Agent auto-update in specific/all Cloud Manager/Atlas Project(s).

    Why is it a problem? (the pain) Cloud Manager/Atlas Project will warn a user with One or more software components are out of date: MongoDB Agent every time a new version of MongoDB Agent is released, so a user will need to always manually click on Update Software Components button to get rid of that warning (filename: 2020-04-06mongodbagentupdatewarning.png). Frequent updates of MongoDB Agent creates lots of noise for users who is willing to get rid of out of date: MongoDB Agent warning in their Cloud Manager/Atlas Projects.

    What is the problem that needs to be solved? Ability to turn on/off MongoDB Agent auto-update in specific/all Cloud Manager/Atlas Project(s).

    Why is it a problem? (the pain) Cloud Manager/Atlas Project will warn a user with One or more software components are out of date: MongoDB Agent every time a new version of MongoDB Agent is released, so a user will need to always manually click on Update Software Components button to get rid of that warning (filename: 2020-04-06mongodbagentupdatewarning.png). Frequent updates of MongoDB Agent creates lots of noise for users who is willing to get rid… more

    •  

    7 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  ·  Cloud 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. Add `serverStatus.uptime` counter info into Metrics

    What is the problem that needs to be solved? We already collect serverStatus.uptime counter info from each and every MongoDB Server process, so we just need to add serverStatus.uptime counter info into Metrics so that it will be possible to track serverStatus.uptime changes through the time.

    Why is it a problem? (the pain) If you'd like to calculate MongoDB Server process availability to know for how long your MongoDB Server process(es) was/were up and running, you'll need to analyze MongoDB Server process logs (in case if they are ever available for required period of time) to see last time MongoDB Server process was stopped/started. With serverStatus.uptime counter info available in Metrics at Ops Manager side it will be very easy (also programmatically via Public API call) to identify down time of MongoDB Server process since serverStatus.uptime counter will be reset every time MongoDB Server process is restarted (i.e. a MongoDB Server process restart will always be indicated easily).

    What is the problem that needs to be solved? We already collect serverStatus.uptime counter info from each and every MongoDB Server process, so we just need to add serverStatus.uptime counter info into Metrics so that it will be possible to track serverStatus.uptime changes through the time.

    Why is it a problem? (the pain) If you'd like to calculate MongoDB Server process availability to know for how long your MongoDB Server process(es) was/were up and running, you'll need to analyze MongoDB Server process logs (in case if they are ever available for required period of time) to see last time MongoDB… more

    7 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

12. Show Kubernetes resources in Ops Manager

    Show some of the Kubernetes resources in Ops Manager
    1. show namespaces in projects,
    2. Show list of resources in cluster view

    7 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  ·  2 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

13. Weekly alerts report as part of the UI

    Weekly alerts report as part of the UI with the option to download export to pdf

    6 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

14. 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

    6 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

15. Benchmark backups in Ops Manager

    It would be helpful if, on the Snapshot overview page or on the Admin -> Backup page, there was the ability to benchmark the backup to help identify bottlenecks.

    Allow the user to select a deployment to test and then do a random sampling of data (ie: 100MB) to a temporary Snapshot location and then graph out the metrics for things like Memory/CPU/Disk IO on the source host, Database performance, Backup Agent performance, Network throughput, Blockstore/File System Store/S3 write performance, etc.

    Then create a report based on this benchmark that can be sent to technical support for recommendations.

    This will help the user identify potential bottlenecks before they become a serious issue and assist technical support in helping the customer have a positive experience.

    It would be helpful if, on the Snapshot overview page or on the Admin -> Backup page, there was the ability to benchmark the backup to help identify bottlenecks.

    Allow the user to select a deployment to test and then do a random sampling of data (ie: 100MB) to a temporary Snapshot location and then graph out the metrics for things like Memory/CPU/Disk IO on the source host, Database performance, Backup Agent performance, Network throughput, Blockstore/File System Store/S3 write performance, etc.

    Then create a report based on this benchmark that can be sent to technical support for recommendations.

    This will… more

    6 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. Allow scheduling grooms

    Add the ability to schedule groom jobs at a specific point in time. Also expose this functionality through the API for easy modifications through configuration management tools.

    6 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

17. Improve backup job status in Backup jobs summary table

    When checking the backup job details for a 4.2 deployment, this is always reporting to be performing a "WT Checkpoint" even though it is not exactly generating a snapshot at that point in time.

    The request is to enhance the reporting for this summary table in order to get further details on what the Backup Module is doing at that precise point in time. If it is awaiting for the instruction to execute a snapshot, in the process of transferring blocks, etc.

    •  

    6 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

18. Implement IAM role authentication for AWS SES in Ops Manager

    At the moment using AWS SES for email delivery in Ops Manager requires AWS Access Key and Secret Key. Please implement the IAM role authentication for this option as it has been done for the S3 endpoints.

    6 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

19. adminCredentials secret should always be source of truth for OpsManager

    The secret is only taken into account by OpsManager initially when OpsManager is deployed. As soon as the password of this user is changed in OpsManager, this secret is out of sync.

    From the docs: "Use these credentials to log in to Ops Manager for the first time. Once Ops Manager is deployed, you should change the password or remove this secret."
    https://docs.mongodb.com/kubernetes-operator/v1.4/tutorial/plan-om-resource/#prerequisites

    Option 1: This secret should be in-sync with the OpsManager database. Preferably the sync should be from the k8s secret to the OpsManager database.

    Option 2: Create a CRD "MongoDBOpsManagerUser" that handles User/Password management for OpsManager similar to "MongoDBUser" for "MongoDB" resources.

    The secret is only taken into account by OpsManager initially when OpsManager is deployed. As soon as the password of this user is changed in OpsManager, this secret is out of sync.

    From the docs: "Use these credentials to log in to Ops Manager for the first time. Once Ops Manager is deployed, you should change the password or remove this secret."
    https://docs.mongodb.com/kubernetes-operator/v1.4/tutorial/plan-om-resource/#prerequisites

    Option 1: This secret should be in-sync with the OpsManager database. Preferably the sync should be from the k8s secret to the OpsManager database.

    Option 2: Create a CRD "MongoDBOpsManagerUser" that handles User/Password management for OpsManager similar… more

    6 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

20. Add hostname/port attributes into all Cluster/Replica Set alert types

    What is the problem that needs to be solved? Add hostname/port attributes into all Cluster/Replica Set alert types generated via SNMP Alert Traps, Ops Manager's Public API calls (Project/Global Alerts) and Alert Webhooks (Project/Global Alerts).

    Why is it a problem? (the pain) Hostname/port attributes are currently missed in Cluster/Replica Set alert types and we only provide a name of the Cluster/Replica Set for which the alert was generated. Operator who watch Monitoring System (the one that receive Ops Manager Alerts) needs to see hostname/port information of a Shard/Replica Set for which such alert was generated, in order to quickly understand to where that Ops Manager's Alert is related to. Monitoring System (the one that receive the alert from Ops Manager) needs to do additional work for alert received (via additional API calls (if possible at all)) in order to get hostname/port for each process of Cluster/Replica Set.

    What is the problem that needs to be solved? Add hostname/port attributes into all Cluster/Replica Set alert types generated via SNMP Alert Traps, Ops Manager's Public API calls (Project/Global Alerts) and Alert Webhooks (Project/Global Alerts).

    Why is it a problem? (the pain) Hostname/port attributes are currently missed in Cluster/Replica Set alert types and we only provide a name of the Cluster/Replica Set for which the alert was generated. Operator who watch Monitoring System (the one that receive Ops Manager Alerts) needs to see hostname/port information of a Shard/Replica Set for which such alert was generated, in order to quickly understand… more

    6 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