In SQL Monitor, I want to...

Make SQL Monitor scale to more machines and networks

CONTEXT: We want to monitor many different servers in different domains and locations

PROBLEM: Network configuration for cross-domain monitoring can be challenging, and SQL Monior can slow down if many servers are being mointored

EXAMPLE SOLUTIONS:
• Create a central web interface that can access multiple Base monitors
• Provide an optional agent that can be deployed for easier network configuration
• Make a single installation of SQL Monitor scale to a larger number of servers, and make network configuration easier

118 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Daniel RothigDaniel Rothig shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Paul MillarPaul Millar shared a merged idea: network  ·   · 
    Maximiliano MoralesMaximiliano Morales shared a merged idea: RedGate.Response.Engine.Alerting.Base.Service.exe  ·   · 
    nhartmannhartman shared a merged idea: Create a central web interface that can access multiple Base monitors  ·   · 
    AdamAdminAdam (User Experience Specialist, Red Gate Software) shared a merged idea: Allow users to monitor servers in different domains and networks  ·   · 

    18 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • StephenStephen commented  ·   ·  Flag as inappropriate

        "Something" really needs to be done to make this a whole lot easier. I've been a SQL Monitor user since the first v3 came out and am one of those Accidental DBAs who have a love-hate relationship with all things Windows and SQL Server security/Login/User stuff.

        Having just reset a Windows box at Rackspace and using SQL Monitor on Azure, it took a half day to get SQL Monitor and that box to agree to being monitored.

        Having had to erase everything to with the box's history from SQL Monitor and re-add it, rather than any re-deploy Action, I'm just glad that adding a box to SQLM isn't a daily chore/endurance/pain-in-the-posterior.

        Even having read the SQLM documentation re Security, and the prior non-DBA's write-up (proved inaccurate), scaling to more than a few boxes is a limitation/weakness of the current SQLM iteration (5.1 BTW).

        The far-end installer needs help to make it usable by A-DBA's like me.

        The Host needs help with re-deployment. We absolutely need Friendly Name overrides on EVERY SINGLE PAGE - so tired of seeing a Group Name (friendly), then get stuck with an I.P. or a Rackspace device-ID on emails/subpages/configs at random... Even things like that will promote scalability by making the tool consistent/easier to use. It's often a case of "do I have to go over to SQLM to.....?" Sorry, but that's the truth...

      • eric twilegareric twilegar commented  ·   ·  Flag as inappropriate

        I think each server should just have a locally installed agent. Having to open ports like 135 between the base on the server is weird to say the least.

      • eric twilegareric twilegar commented  ·   ·  Flag as inappropriate

        I'd prefer installing an agent on each sql server that pipes data back to a central basemonitor/web access stack. The amount of ports that have to be open between the base monitor and your sql server is disturbing.

      • Anonymous commented  ·   ·  Flag as inappropriate

        I'd love to see this move forward. Especially with the capacity to automatically discover new servers as they come online within a specified network.

      • Paul MillarPaul Millar commented  ·   ·  Flag as inappropriate

        Create a client agent (we monitor from our domain, across VPNs to customer sites/datacenters - opening RPC/WMI/et al does not go down well, nor does fixing RPC to individual port ranges.

        It can be done, but large customers / hosting providers pretty much make life a lot harder than it needs to be, distracting majorly from the main monitoring / support / diagnosis tasks - an agent with single or few port requirements would make life so much easier - assuming LAN-like line of site doesn't work well for us. Deploy agent with a service account addresses one of the domain trust suggestions too.

      • MauricioMauricio commented  ·   ·  Flag as inappropriate

        I would like this also. My work network mandates distinct VLANs / Domains for each group of servers, heavilly firewalled and with no trust on the domains.

        so using Windows Authentication is impossible, as is fixing the WMI ports on monitored servers. having 2 or more "central management" is not exactly "central" anymore. having multiple servers capturing data on distinct networks and reporting to one single database would be great.

        I was also part of the beta for SQL Monitor Hosted, and as an example this could work for that product also: having multiple relays could make our life easier when we need to monitor servers on distinct domains/vlans.

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        Be sure to consider time differences. Untrusted domains may not have the same time source and therefore not be in sync. We are having problems with this very issue.

      • Eric HumphreyEric Humphrey commented  ·   ·  Flag as inappropriate

        I'd like to add that sometimes you need to use different base monitors to monitor different subnets or vlans of servers, but all report back into the same repository. The whole goal is one pane of glass for all servers, not a segmented view.

      • twiggytwiggy commented  ·   ·  Flag as inappropriate

        Look at the way Paessler PRTG handles this. Allow a web service to hook to multiple base monitors. PRTG calls them Probes. The web service just connects to the base monitors via ports so Admins could punch holes in firewalls to make this work. Users can login to the web server either with native or Windows accounts (hint hint) and see databases in any variety of situations domains, etc.

      • AnonymousAnonymous commented  ·   ·  Flag as inappropriate

        This would be quite helpful. I know that our environment is an edge case but we're having trouble trying to figure out how we can monitor 1200+ databases across several instances without setting up multiple base monitors and web servers. Maybe another title for this could be a "Scale out" base monitor solution?

      • nhartmannhartman commented  ·   ·  Flag as inappropriate

        Given the sizes of some SQL environments we found that it is necessary to have multiple base monitor servers. However currently it is cumbersome to have to navigate to multiple URL's or switch the base monitor that's tied to a web server. Having a central console that is easily and always connected to multiple base monitors would alleviate this problem. Also this could allow you to monitor from various networks and domains.

      • AdamAdminAdam (User Experience Specialist, Red Gate Software) commented  ·   ·  Flag as inappropriate

        This is something we are considering. We have some ideas of how we could achieve this, for example a remote monitor (which can be installed on external network and will collect data and send to base monitor) but nothing is concrete yet.

        Please let us know what considerations we would need to make for your own environments.

      • AdamAdminAdam (User Experience Specialist, Red Gate Software) commented  ·   ·  Flag as inappropriate

        We have multiple servers in different domains. At present there is no trust between the domains and we have a seperate login for each domain. Each domain also has its own IP address range and there may be 2 or more firewalls between the servers. Is an optional agent based approach feasable where all the work happens locally & say XML is punted back & forth over a particular port?

      Feedback and Knowledge Base