Translated from the Korean original. Some screenshots show the original Korean interface.
How engineers raise the quality of MaxGauge maintenance
Hi, we're Hyemin Kim and Dongryul Kim from the DB Technology Division.
We are MaxGauge engineers who handle MaxGauge maintenance across many customers' DB environments.
In the field, we often find ourselves spending more energy on simple repetitive checks than on actual technical judgment. The larger the customer, the more servers and processes there are to manage, so check time grows exponentially. And because people handle it manually, unexpected blind spots can appear.
To automate this repetitive work so engineers can focus on more valuable analysis, we built MaxGauge Inspector, a MaxGauge check tool shaped by the concerns of entry-level engineers like us.
1. Why we built Inspector
1-1. What kept repeating in maintenance work
When an engineer visits a customer for a regular check, the process usually looks like this.
Key check items
- Check process status and abnormal logs
- Check that collected data is INSERTed correctly
- Check that Summary runs correctly
- Check key resource status on the collection server
With the current check process, check time grows as the number of servers and processes grows. Above all, manual checks require a person to review hundreds of metrics, so the level of detail can vary depending on which engineer does the work.
Junior engineers like us in particular have not yet experienced the full range of product issues, so we worried that our view of a problem would inevitably be narrow.
We thought that if the system could point out in advance the blind spots an experienced engineer would find by instinct, anyone doing the check could deliver the same level of service without missing anything.
That is why we built MaxGauge Inspector.
1-2. The first draft of Inspector
When we first planned Inspector, the goal was simple.
Ship a prompt-style shell so we can view all the check metrics quickly!
Since we had no development background at all, we planned it so that typing an item at the prompt above would simply run the SQL mapped to that item.
1-3. AI progress and a growing list of what's feasible
Once we started using Claude Code, however, we were able to expand the project's goals.
- Web-based checks without logging in to the server: Instead of going through complex security procedures to SSH into a server every time, you can see service, OS, session, and query status at a glance in the browser.
- Automatic records even when no engineer is around: It runs check items every 10 minutes and every 1 hour on its own and stores the results in a DB. So even if you arrive after a problem has occurred, you can check the state at a specific point in the past.
- Simple deployment with no package installs: Because many customer environments restrict installing external libraries, we aimed for a form where unpacking a single archive is all it takes to be ready to run.
2. Expanding while protecting the main product
2-1. A fork in system design: running it separately from the existing product
Before full development, we held an internal technical discussion on how to implement this utility.
At first, we also considered integrating the features into the existing product (MaxGauge) to save development resources. In the end, for stable operation and maximum responsiveness in the field, we decided to build it as a 'gateway-based standalone service.'
Here are the specific reasons for this architecture decision.
- Fault isolation and product stability
Since this utility was built to remove the hassle of manual checks, we physically isolated it so that unexpected errors or memory issues in its internal logic would not affect the availability of PlatformJS, the main product. We use port 8080 as the gateway to keep a single entry point, but separate the services internally, putting the stability of the main service first.
- An independent release cycle
Separately from the main product's update cycle, we gained the flexibility to update and ship check items whenever the field needs them.
- A productivity-first tech stack
Moving away from the constraints of the existing Java/JSP environment, we chose a Python environment, which works best with AI tools (Cursor, Claude Code, etc.) and is well suited to data processing. This sped up development dramatically and let us focus on quickly implementing the complex logic real checks require.
2-2. A standalone ecosystem built with Nginx and Python
- Gateway (Nginx): The core layer introduced as a result of the discussion. Externally, it exposes only port 8080, which security policy allows. Internally, it routes requests by path to either the existing service (PlatformJS) or the new service (Inspector).
- python-utils (using AI): We chose Python to implement the DB check logic. Because customer environments may restrict installing external packages, we tried to set up the server in the lightest and simplest way possible. We solved unfamiliar server setup and configuration with help from AI tools, which let us focus on the core: implementing the DB check logic.
- Single-package deployment: We set a goal of '1 minute to install' for field engineers. With no complex install steps and no external library dependencies, we put every component into one archive. As a result, even in environments with no internet access for security reasons, you just copy over a single install file, unpack it, and set the initial Gateway port, and it runs right away.
During development, we focused less on adding features and more on "a fully separated design that does not touch a single line of the existing product."
3. 'Vibe coding' with AI, from planning to implementation
3-1. Closing implementation gaps with detailed design and queries
Inspector's value depends on how accurately it turns the checks engineers ran every time into a system. So instead of simply handing features off to AI, we did the detailed design of data structures and logic ourselves before development.
We sorted the check scripts we had already written last year by function, and completed the query design one by one ourselves: which tables to read and which columns to join. Instead of asking AI to "build this feature," we gave it a clear guideline: "run this query we designed and pull out this data."
3-2. An engineer's eye, AI's hands
We knew DBs and MaxGauge well, but web development was new to us. For us, AI was the most reliable helper.
Rather than studying complex web technologies, we took a strategic approach and focused on building an engineer's perspective into the code.
1) A strict division of roles: people own the logic, AI owns the screens
First, we drew a clear line on "what people decide and what we leave to AI."
- The human side: Drawing on our MaxGauge maintenance experience, we acted as designers, defining which metrics are warning signs and what data must be queried in what form for accurate analysis.
- The AI side: AI implemented how to 'draw' the data we defined on screen.
We chose to give AI concrete data guidelines. We defined the purpose and layout of the data with instructions like "the query results follow this format, so put status badges at the top and draw a time-series graph at the bottom."
Thanks to this division of roles, we could focus on the overall structure even without much web development knowledge.
2) Insights from our own products (MaxGauge, exemONE)
To build screens for field use rather than just a pretty design, we drew heavily on the strengths of our own products.
- Intuitive status checks: Like when an Alert fires on the MaxGauge Realtime Monitor dashboard, we used 'colors (green/yellow/red)' rather than complex numbers so you can see current health at a glance.
- The value of data collection: Inspired by MaxGauge Performance and the exemONE analysis board, we laid out not only the current state but also past history on a timeline. We designed it to answer "How was it earlier?" right away, not just "Is it OK now?"
3) Finished through an operator's eyes
When AI wrote code quickly, we then reviewed the screens through an operator's eyes.
We iterated with feedback like "the threshold line needs to stand out more" and "clear date boundaries make overnight incidents easier to find."
We were inexperienced at web development, but because we had deep understanding of and experience with our own products, we could turn AI's output into genuinely useful 'screens for engineers.'
3-3. Inspector's core capabilities: from real-time diagnosis to time-series records
The finished Inspector became more than a simple check tool. It is engineers' experience turned into a system.
1) Live Check
Without logging in to each server one by one, you can view every check item together on a single web page.
- Status checks: Key metrics such as service availability, Tablespace, and OS stat are judged instantly by color.
- Partition table management: It checks remaining partitions and supports manual creation of partition tables when related issues occur, minimizing management risk.
- Summary & resources: It determines whether the 10-minute/1-hour Summary is delayed and checks disk capacity, Vacuum Age (PG), Temp usage, and more in real time.
2) History
Inspector's biggest differentiator is its records. An internal scheduler runs periodically and accumulates check results as time-series data.
- Stores CPU metrics every 1 minute and shows them as a graph
- Checks the daily volume of data collected by MaxGauge and shows it as a graph
3) Cross-checking logs against data
By comparing the logs of MaxGauge process activity with the data recorded in the collection DB, we can now confirm whether each task actually completed correctly.
4) Troubleshooting
It does not stop at watching status. We built in tools to fix problems on the spot. We focused on drastically cutting the effort engineers spent going back and forth between servers.
- Remote process control: Start or stop each process from the web UI without logging in to the server.
- Log viewer & parameter changes: Open even huge log files right in the browser, and if needed, change process settings (Parameter) immediately to tune them.
- SQL Script Manager: Beyond the metrics Inspector provides by default, if an engineer wants to check more information in the collection DB, they can run their own queries at any time to pull the data they need.
5) Unified support regardless of DB type (Oracle/PG)
It gives engineers exactly the same screens across different DB environments, Oracle and PostgreSQL.
Even when each customer runs a different DB type, the check flow and UI stay consistent, so engineers can work proficiently in any environment right away without having to adjust.
4. The synergy of two junior engineers and AI
4-1. The value of collaboration beyond technical growth
Looking back, more than half of what we learned on this project was 'outside the code.'
As junior engineers, it was a valuable time to learn firsthand how to run alongside AI and how to work in step with a colleague.
- The weight of domain knowledge: No matter how well AI writes code, verifying that the output reflects things accurately is ultimately a human job. Only by fully understanding what each line of my query means could I be sure whether AI's output was right or wrong. We realized that the expertise engineers need in the AI era goes beyond implementation skill. It is the ability to tell the right answer.
- A fuller perspective through collaboration: On my own, I would have been stuck with screens that only looked familiar to me. But working with a colleague, we raised 'how to present data so it can be read at a glance' and 'which layout makes anomalies easiest to spot from an engineer's point of view' and discussed them constantly. Because we reviewed and refined each other's screens critically through an operator's eyes, we went beyond implementing features and built a tool that maximizes readability and clarity in real check work.
- Using AI as an amplifier: In the past, we could only come up with solutions within the range of what we already knew and had experienced. Once we started using AI, ideas we had given up on because of technical limits began to become real. With AI filling in unfamiliar languages and complex libraries in real time, we found that an engineer's real capability is now the scale of what you can plan, not the amount you know.
4-2. What's next for Inspector
Inspector is now about to enter the stage of checking how much practical help it gives in the field. Going forward, we want to gradually add features such as automatic patching for frequent issues and keep reducing the hassle of maintenance work.
We also want to go beyond simply delegating checks to a tool, and use it as a chance to build insight into the data by having engineers interpret the metrics Inspector shows.
Now that we are free from simple repetition, if we focus on digging deep into DB domain knowledge, we believe check accuracy will rise and our expertise will naturally deepen too.
We cautiously hope that Inspector, built through this effort, can raise the quality of maintenance and become a tool that lays the groundwork for our company's engineers to grow.
Want to know how to manage DB performance more efficiently?
Related articles
