469 results found

1. Support Cloudian S3 in OpsManager

   OpsManager currently supports the S3 implementations of AWS, IBM Cloud and Dell EMC Elastic Cloud Storage. We would like to use our existing Cloudian S3 storage. We've used it for a while now and it works, but we suggest making this an "officially supported" flavor, too.

   1 vote

   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  ·  Edit…  ·  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. Release Cadence to allow pegging Minor Version Upgrades prior to GA of next Major Release

   Issue:
   Current requirement to enable 'auto upgrades' to test and take advantage of Minor version updates (Example: 6.x.x >> 6.y.x). As a larger company with a 2-4 week release cycle in our products, we have seen need to start testing a Minor version upgrade to the current Major GA Release (Recent example below).

   Scenario where this could be a problem in summary (See detailed real world story further down):
   - Customer sees a new feature they wish to try.
   - Customer is pegged to last major version upgrade (currently 6.0.x) to allow for pegging the version in production
   - Customer cannot allow for 'auto upgrades' in production due to internal Release Management requirements, and must wait the full year cycle for features added in later minor versions of the current major release.

   The Ask: We respectfully request a resolution to a state where we can choose to peg any of our clusters to a specific minor version (i.e. 6.1.x, or 6.2.x...) and allow only auto upgrades in the patch/bug release numbers rolled out by Atlas. Thank you for your time and response to this critical upgrade in scheduling & control over Minor version upgrades.

   More detailed summary of need for control over Minor Release Update Cycles/Scheduling:
   As we have our own release management requirements, any change to a Production environment must go through UAT and Performance testing and approval before the release. Currently, with requirement of enabling 'auto upgrades' to move up to available Minor Release, we are hamstrung until late in the Major release cycle to begin testing and releasing a minor version in lower environments to then implement in Production. this is due to our internal Release Management requirement to peg the MongoDB version and driver in Production to a fully tested release, and to have lower environments testing and validating on same IaaS release version as production. And pegging a version is only allowed at the Major version going to GA. We wish to ask that Minor versions be left to live for 12-15 months to allow for pegging a minor version upgrade during the year. This would allow our teams to implement a Minor version upgrade early... and peg to that version pending the annual GA release to come.

   Below I highlight the real world example that caught our team in a catch-22 with v5.0 not meeting requirements of our application in sharded configuration, requiring us to enable 'auto upgrades' to get to 5.1.x or later.

   Resulting Request:
   We would like the ability to peg our clusters to specific minor releases. Example: to 5.3.x where patch releases are acceptable, but minor version updates to 5.4.x are not allowed until we have tested and approve within same our own CICD pipeline and process.
   Allowing for 'auto upgrades' in our clusters based on Atlas rollout schedules poses unwarranted risk to the production assets of the End Users
   The ability to be alerted of available minor updates with option to choose when to begin our own test/release and schedule same is requested.

   Recent situation/scenario:
   With requirement for 'auto updates' we were in a catch-22 with 5.0.x And 5.3.x, where we needed the features of graph lookup with sharded configuration in production.
   - We are rapidly reaching critical resource issues in Production with a Primary/Replica configuration.
   - We must proceed with upgrade to Sharded configuration to 1) allow for horizontal scaling to relieve pressure on Primary nodes for Read Preference Primary for mission critical operations requiring high idempotency, and that do not allow for eventual consistency within the SLAs and 2) relieve pressure on Oplogs due to high throughput and rapid data changes during normal operations. We have operations that lead to a requirement on a primary/replica set to be now 1.2TB to prevent OpLog window from dropping below 12hrs. - With horizontal scaling, we can spread the load on read primary across multiple nodes, which will alleviate the need for such a large Oplog Size, leading to better management and availability of storage.
   Without the 5.3.2 upgrade and change in our current primary/replica >> sharded configuration. We could not proceed with the much needed upgrades without accepting release management risks associated with enabling 'auto upgrades'. Although the recent scenario is resolved as 6.0 is now GA, if this were earlier in the GA release cycle, we would either 1) be blocked from the above critical upgrades, or 2) Forced to accept the risks of an 'auto upgrade' being implemented in Production ahead of our NonProd clusters. Going against best practices for Release Management.

   Issue:
   Current requirement to enable 'auto upgrades' to test and take advantage of Minor version updates (Example: 6.x.x >> 6.y.x). As a larger company with a 2-4 week release cycle in our products, we have seen need to start testing a Minor version upgrade to the current Major GA Release (Recent example below).

   Scenario where this could be a problem in summary (See detailed real world story further down):
   - Customer sees a new feature they wish to try.
   - Customer is pegged to last major version upgrade (currently 6.0.x) to allow for pegging the version in production
   - Customer… more

   1 vote

   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  ·  Other  ·  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. MongoDB Tools Apple Silicon native version

   6.0 now has a native release for Apple Silicon, but the tools are still compiled for x86_64. The https://github.com/mongodb/mongo-tools/blob/master/PLATFORMSUPPORT.md seems to point towards new platform support on internal systems like https://evergreen.mongodb.com/distros - can we get a native build of the tools ?

   1 vote

   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  ·  Other  ·  Edit…  ·  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 cluster_id parameter in host detail API

   As per the link https://www.mongodb.com/docs/ops-manager/current/reference/api/measures/get-host-process-system-measurements/ and below API :

   curl --user "{PUBLIC-KEY}:{PRIVATE-KEY}" --digest
   --header "Accept: application/json"
   --include
   --request GET "https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/hosts/{HOST-ID}/measurements?granularity={TIME-INCREMENT}&period={PERIOD}}&pretty=true"

   This will give us the details pertaining to one host and one project. However what if one host has multiple processes and part of multiple replica sets within same project in OPS Manager? Then it becomes difficult to gather gather data. Hence a clusterid parameter should also be added to distinguish details based on host pertaining to which cluster or replica set along with projectid which is already present.

   1 vote

   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  ·  Edit…  ·  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. Export Reports and Graphs

   OPtions to export the reports and graphs into a PDF or office tool will help Incident Management process to a great extend.

   1 vote

   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  ·  Edit…  ·  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. rename action for backup daemon "delete daemon" to "deactivate daemon"

   when you press link "delete daemon" on Admin->Backup->Daemons page it "deletes" daemon from this page, but after mongodb-mms.service gets restarted, this daemon comes up again. this link does not delete daemon - it actually deactivate backup daemon. another part for deactivation of daemon is to modify settings for service mongodb-mms to start only mms application without daemon.

   1 vote

   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  ·  Edit…  ·  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. mongocli - changing server type

   There is a missing option to change server type via mongocli. You can list the server type for the project, but not change it.

   available option for list:
   mongocli om serverUsage projects hosts list --endDate 2020-01-01 --startDate 2021-01-01

   https://www.mongodb.com/docs/mongocli/v1.8/reference/ops-manager/server-usage-list-all-project-hosts/

   1 vote

   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  ·  MongoDB CLI for Cloud Manager and Ops Manager  ·  Edit…  ·  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. Ops Manager UI estimates backup time and restore

   Backups and restore estimation as UI feedback for regular and continuous backups

   1 vote

   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  ·  Backup  ·  Edit…  ·  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. Logging: attr.error field type conflicts

   Hey!

   We are using fluent-bit to push MongoDB logs to Elasticsearch. When there are already logs in the elastic index, where attr.error is an object, then it does not accept log lines in which this field is a string:

   “error”:{“type”:“mapperparsingexception”,“reason”:“object mapping for [attr.error] tried to parse field [error] as object, but found a concrete value”}

   There is log with string attr.error:

   {“t”:{"$date":“2022-05-13T15:16:31.203+00:00”},“s”:“I”, “c”:“CONNPOOL”, “id”:22572, “ctx”:“MirrorMaestro”,“msg”:“Dropping all pooled connections”,“attr”:{“hostAndPort”:“mongodb-1.mongodb-headless.mongodb.svc.cluster.local:27017”,“error”:“ShutdownInProgress: Pool for mongodb-1.mongodb-headless.mongodb.svc.cluster.local:27017 has expired.”}}

   There is log with object attr.error:

   {“t”:{"$date":“2022-05-13T15:20:56.857+00:00”},“s”:“I”, “c”:“REPL_HB”, “id”:23974, “ctx”:“ReplCoord-680”,“msg”:“Heartbeat failed after max retries”,“attr”:{“target”:“alerta-mongodb-arbiter-0.alerta-mongodb-arbiter-headless.monitoring. svc.cluster.local:27017”,“maxHeartbeatRetries”:2,“error”:{“code”:93,“codeName”:“InvalidReplicaSetConfig”,“errmsg”:“replica set IDs do not match, ours: 61ea35f29cfd494fef169571; remote node’s: 61eef8589d065c56e61d6e52”}}}
   bitnami/mongodb:4.4.12-debian-10-r18 docker image is used

   Could you direct CONNPOOL error message to attr.error.errmsg instead of attr.error (the same as REPL_HB error message)?

   I understand that I can make a filter in fluent-bit, but the root cause will remain a problem for other users using structured logging as well.
   I think many people have this problem, but not everyone could notice the absence of some logs.

   Hey!

   We are using fluent-bit to push MongoDB logs to Elasticsearch. When there are already logs in the elastic index, where attr.error is an object, then it does not accept log lines in which this field is a string:

   “error”:{“type”:“mapperparsingexception”,“reason”:“object mapping for [attr.error] tried to parse field [error] as object, but found a concrete value”}

   There is log with string attr.error:

   {“t”:{"$date":“2022-05-13T15:16:31.203+00:00”},“s”:“I”, “c”:“CONNPOOL”, “id”:22572, “ctx”:“MirrorMaestro”,“msg”:“Dropping all pooled connections”,“attr”:{“hostAndPort”:“mongodb-1.mongodb-headless.mongodb.svc.cluster.local:27017”,“error”:“ShutdownInProgress: Pool for mongodb-1.mongodb-headless.mongodb.svc.cluster.local:27017 has expired.”}}

   There is log with object attr.error:

   {“t”:{"$date":“2022-05-13T15:20:56.857+00:00”},“s”:“I”, “c”:“REPL_HB”, “id”:23974, “ctx”:“ReplCoord-680”,“msg”:“Heartbeat failed after max retries”,“attr”:{“target”:“alerta-mongodb-arbiter-0.alerta-mongodb-arbiter-headless.monitoring. svc.cluster.local:27017”,“maxHeartbeatRetries”:2,“error”:{“code”:93,“codeName”:“InvalidReplicaSetConfig”,“errmsg”:“replica set IDs do not match, ours: 61ea35f29cfd494fef169571; remote node’s: 61eef8589d065c56e61d6e52”}}}… more

   1 vote

   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  ·  Edit…  ·  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 to be able to do archiving of Data to a different replica set than you Prod replica set.

    To be able to set up Archiving in Ops Manager so you would be able to keep a certain amount of data in Prod and move the rest of to an Archiving replica set.

    1 vote

    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  ·  Edit…  ·  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. Sharding

    When we create a new collection with a shard key using mongosh the same is not reflected in cloud manager. In cloud manager / ops manager the shard key for the new collection is not seen in the shard tab.

    1 vote

    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  ·  Cloud Manager  ·  Edit…  ·  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. Include "Fetch Time" in Profiler timings

    When we run the Profiler, the runtime of "select" type queries are dramatically understated. This is because the Profiler only counts the time of the "query", and doesn't include how long it took to "fetch" the result set.

    In one of our test cases, we "tuned" the query so it only shows as running 82 ms in the Profiler. However, when we actually run this same query in JavaScript, the runtime is 10 seconds. This is a very slow query which our end users experience many times a day.

    Is there a way to configure Profiler to be more realistic, and include the "fetch time" as well as the "query" time?

    Currently, the Profiler seems to be of little us in finding slow queries. We have to find them using other means.

    Thank you.

    When we run the Profiler, the runtime of "select" type queries are dramatically understated. This is because the Profiler only counts the time of the "query", and doesn't include how long it took to "fetch" the result set.

    In one of our test cases, we "tuned" the query so it only shows as running 82 ms in the Profiler. However, when we actually run this same query in JavaScript, the runtime is 10 seconds. This is a very slow query which our end users experience many times a day.

    Is there a way to configure Profiler to be more realistic,… more

    1 vote

    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  ·  Edit…  ·  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. Add command for suspending automation

    Add command for suspending automation (similar to what we have for unmanage)

    1 vote

    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  ·  MongoDB CLI for Cloud Manager and 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. Do not start backups for Sharded clusters unless all requirements are met

    With FCV > 4.2, Backups requires the backup module to be activated on at least one member per shard for sharded clusters but it also doesn't stop one from starting backups if the backup module is activated only on one member of the entire sharded cluster, for example, activating the backup module on a single member of the config server replica set and not on any member of the shards allow for one to start backups.

    Currently, if backups are enabled and at least one of the Replica sets in the Cluster has a backup module, backups will start for the cluster.
    The backups in the "missing" backup agent function scenario would not be consistent.

    With FCV > 4.2, Backups requires the backup module to be activated on at least one member per shard for sharded clusters but it also doesn't stop one from starting backups if the backup module is activated only on one member of the entire sharded cluster, for example, activating the backup module on a single member of the config server replica set and not on any member of the shards allow for one to start backups.

    Currently, if backups are enabled and at least one of the Replica sets in the Cluster has a backup module, backups will start for… more

    1 vote

    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  ·  Edit…  ·  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. Present MongoDB clients metadata on Ops Manager UI

    Before MongoDB version upgrades we should verify all drivers compatibility for the new version.

    It is sometimes difficult to track all of the drivers used connecting to the deployments. Currently it requires parsing of multiple mongos/mongod logs for client connections or internal code investigations.

    Suggestion

    It may be beneficial to collect and present clients statistics (version, type, IP) data on Ops Manager.

    Maybe this could be a feature that can be toggled on demand.

    1 vote

    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  ·  Edit…  ·  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. Virus threat in MongoDB CLI

    I am facing an issue when downloading MongoDB CLI on my win10 computer. The Windows virus scanner says there is a "Trojan:Win32/Caynamer.A!ml" in the file I am trying to download and ends the download. Is this threat real?

    1 vote

    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  ·  MongoDB CLI for Cloud Manager and 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. connection

    Ops Manager only shows number of connection. Most DB monitoring tool shows where the connection is coming from and whats being run from the session. This needs to be a part of Ops Manager

    1 vote

    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  ·  Edit…  ·  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. Increase maximum retention periof of backups

    Currently OpsManager's maximum retention period for backups is 84 months (7 years). We have the requirement to keep 10 years of backups, hence adding some values (96, 108, 120, 132, 144) in the "Store monthly snapshots for... months" in the backup schedule would be helpful. Another option might be to allow custom values (I guess this is the purpose of https://feedback.mongodb.com/forums/924355-ops-tools/suggestions/39441955-make-snapshot-retention-policy-more-customisable)

    1 vote

    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  ·  Backup  ·  Edit…  ·  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. Ops Manager to support Credentials Cache to connect to APP DB

    Ops Manager to support Credentials Cache to connect to APP DB
    Its related to case opened : Case: 00881812

    Also change alerting ( Email Subject )

    Currently we get alert with email subject as below even if issue is resolved
    System Alert - Backing Database Connection is Unhealthy

    We Should change alert email subject to Say "Healthy " instead of "Unhealthy " when issue is resolved.

    1 vote

    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  ·  Edit…  ·  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. Ops Manager and attempts to stepDown

    When the majority commit point is not reached, Ops manager should refrain from any config change process like stepDown of a particular primary.

    Sometimes the number of attempts for stepDown can go upto 200 times and the duratio ncould be hours dependign on the data size.

    More details are present in the below ticket:
    https://support.mongodb.com/case/00885173

    1 vote

    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  ·  Edit…  ·  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