Move PostgreSQL munin graphs in here

[knorrie]

At Mendix, we've always had the database statistics separate for munin. Let's move them in here instead, so that they are displayed as part of the Mendix application statistics.

[hvisage]

Will this be “configurable”? ie. I have my Mendix and PostgreSQL on different VMs, how will that be impacted by this ?

On 26 Jul 2018, at 21:14 , Hans van Kranenburg notifications@github.com wrote:

At Mendix, we've always had the database statistics separate for munin. Let's move them in here instead, so that they are displayed as part of the Mendix application statistics.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mendix/m2ee-tools/issues/37, or mute the thread https://github.com/notifications/unsubscribe-auth/ALH1Scnps69aqg8jCCXxHLfHkFsvhUjLks5uKhUcgaJpZM4ViZXc.

---

Hendrik Visage HeViS.Co Systems Pty Ltd T/A Envisage Systems / Envisage Cloud Solutions +27-84-612-5345 or +27-21-945-1192 hvisage@envisage.co.za

[knorrie]

See the commit "munin: move database statistics in here" in the develop branch. Since we already have all necessary info to make connections to the database in our configuration, we can use those to open a PostgreSQL connection and ask for a lot of specific things, and it can use mendix runtime configuration values.

If the code is in here, it works out of the box. On the database server, you only need to have basic default plugins for the operating system, like memory, cpu, disk usage etc. Those can of course not be included here.

At Mendix, we have the R&D "Delighter Days" this week, a week in which we aim to add a lot of small nice things for the users. My first thought was to improve the database connections graph, since currently it only shows the amount of open connections and some irrelevant incorrect total amounts, which make no sense, and no details about which open connections are idle etc... This leads to discussions in support tickets having customers ask "I need more database connections! I'm using all of them!" while in reality most of their connections are idle all the time.

When starting to change this, I realized the database statistics plugins were not even in here, so I added them. :-)

[knorrie]

Actually I'm still polishing this a bit and will collect some new example graphs while running it in a few places already, so I can update the documentation about the munin plugin.

[hvisage]

On 26 Jul 2018, at 21:54 , Hans van Kranenburg notifications@github.com wrote:

See the commit "munin: move database statistics in here" in the develop branch. Since we already have all necessary info to make connections to the database in our configuration, we can use those to open a PostgreSQL connection and ask for a lot of specific things, and it can use mendix runtime configuration values.

If the code is in here, it works out of the box. On the database server, you only need to have basic default plugins for the operating system, like memory, cpu, disk usage etc. Those can of course not be included here.

At Mendix, we have the R&D "Delighter Days" this week, a week in which we aim to add a lot of small nice things for the users. My first thought was to improve the database connections graph, since currently it only shows the amount of open connections and some irrelevant incorrect total amounts, which make no sense, and no details about which open connections are idle etc... This leads to discussions in support tickets having customers ask "I need more database connections! I'm using all of them!" while in reality most of their connections are idle all the time.

Ah! Well, in my case I just had all of those logging to the same munin server and graphs from there. But it might be interesting to have an out-of-band discussion (given the funs I’ve had to convince the “devs” how to optimize their queries/usage after the DB have been tuned to perfection with partial indexes etc. which we couldn’t do inside Mendix) to perhaps look at what/how pghero/pgbadger report on things to be able to give those in summarized views/timing reporting. But that is a bigger thing that what you might be consider doing :( When starting to change this, I realized the database statistics plugins were not even in here, so I added them. :-)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mendix/m2ee-tools/issues/37#issuecomment-408215880, or mute the thread https://github.com/notifications/unsubscribe-auth/ALH1SRW298saELK1cPHzbZXsyR9S3Aosks5uKh5fgaJpZM4ViZXc.

---

Hendrik Visage HeViS.Co Systems Pty Ltd T/A Envisage Systems / Envisage Cloud Solutions +27-84-612-5345 or +27-21-945-1192 hvisage@envisage.co.za

[knorrie]

Well, the monitoring graphs and alerts that are provided by default (in here and what we display in the trends section in our deployment portal) maybe cover 20% of all interesting information ever you can think of to make graphs of, but they give us enough insight for > 90% of the support cases to pinpoint things that look unhealthy and give a hint about causes for a malfunctioning customer application.

And, all of them are generic, and don't know anything about the logic of the projects you are building using Mendix (Well, the health check microflow is a very nice exception to this an example of a way to hook custom logic from the application into an alerting system).

When much more detailed information is required, and you want to build all kind of custom things involving your application logic, then it's better to look in the direction of products like datadog (which can be used with Mendix) since we're never going to duplicate all of that kind of functionality in our own product.

[knorrie]

Included in v7.2-rc1