On-premise observability for the public sector

Wrentrix is designed with the public sector in mind, among other regulated environments. That is a design goal, and it doesn't describe any institution. We do not list public bodies as customers here, and nothing on this page implies any government approval or accreditation.

Questions that come up early

Public bodies tend to assess a monitoring product through a particular set of questions. We've ordered these as they often come up, with the answers we can give and the items we would rather discuss directly.

Traffic with a deadline

Public services get a type of load that private systems rarely see. It comes from a date set by law or by announcement, and not from a weekly habit:

• A tax or declaration deadline, when most filers appear on the last two days.
• Exam results released at a stated minute, with everyone refreshing at once.
• An application window that opens at a set time, with people ready to go.
• An announced benefit payment, or a new requirement after a public notice.

This has real consequences for your monitoring design.

Baselines won't predict it. Hour-of-week baselines learn from the recent weekly pattern, so a once-a-year event looks like a large anomaly. It isn't a false signal, since the traffic really is unusual, but it doesn't tell you anything new. On that day, use SLOs.

Peak planning needs real numbers. Here is a worked example with invented numbers. If 1,200,000 people must complete a filing, and last year's data suggests 30% come on the final day, mostly within 10 busy hours, the average load during those hours is:

1,200,000 × 0.30 = 360,000 filings
360,000 ÷ (10 × 3,600 s) = 10 filings per second

If one filing takes around 25 backend requests, you are at 250 requests per second on average, and peaks within those hours may be several times higher. A figure like this tells you what to load test before the deadline, not after it. Traces from an earlier cycle show which requests make up a real filing, which helps you make a realistic load test, not one that just hits the home page.

Make the promise explicit. An SLO on "submission completes" for the period up to the deadline has a clear meaning for technical staff and for leadership. It also makes a good basis for post-event review. A burn-rate alert during that period is a good reason to wake someone, and this makes an extended on-call for known dates easy to justify.

Rehearse at the front door. Deadline-day failures are often in the components ahead of the application, such as identity systems, gateways or certificates. Probes and TLS expiry alerts should be checked well before a known date. An expired certificate on deadline day is a very visible way to fail.

Depending on other institutions

Government services often rely on other public systems: identity verification, population records, tax or address data. When one of these slows down, your service appears broken to citizens, and you have no way into that other system.

Treat them as you would any external dependency. Your outbound spans should clearly name each peer system, so you can see how long each call is taking. If a page depends on a call to another institution, then that call's percentiles belong on your dashboard, and on the agenda if you need to raise it with them. A TCP probe on the route to each integration tells you whether a network path has gone. Timeouts and fallback behaviour are worth testing: when an identity lookup is slow, does your service fail cleanly, or do threads pile up until everything stops? Connection pool exhaustion is one of the ways this goes wrong.

Small teams and long-lived systems

Many public IT departments look after a wide range of systems with few people, and some of those systems are old and outlast the staff who built them. Monitoring should be designed around that reality, not around a large SRE function.

Prefer fewer alerts over more coverage. A team of six can't keep up with hundreds of alerts. Begin with one SLO for each public service, and page only on fast burn. The alert fatigue guide can help you decide what to delete.

Use zero-code where you can. Older Java and .NET applications often have no one left who can safely change the code. On Kubernetes or OpenShift, method-level tracing arrives through an admission webhook without any code change, starting at the pod's next restart. Applications on plain Linux servers can still have host monitoring, including process discovery, and that alone can settle the question of what is actually installed on a machine no one remembers building. For legacy JVM or .NET on hosts, ask us what's possible.

Keep knowledge in the system. When someone leaves, their knowledge leaves too. Runbooks attached to alerts, along with an automatically drawn service map, retain part of what they knew. So does "explain this screen", on an SLO, deploy or anomaly, particularly for a new employee who has yet to learn the system. It's available in Turkish, which matters when not every technician reads English documentation comfortably.

Be realistic about operating it. A self-hosted platform needs an owner too. Storage must be watched, and upgrades must be scheduled. If your institution outsources operations, decide who owns this and put it in the contract.

Closed networks and shared environments

Many public networks are isolated from the internet, or heavily filtered. Wrentrix's air-gapped operation covers this: no license calls, no outward telemetry, no external model, and an image-less agent install for closed networks. Test it by running with outbound traffic denied.

Shared environments raise a different question. A central IT body may run services for several institutions or departments, each of which should see only its own systems. Team-based RBAC with scoped views is the mechanism for this, with mappings from LDAP or SSO groups. Check the design with your security office, and test with real non-admin accounts. Where the separation has to be absolute, a separate installation may be the correct answer, which is a conversation to have up front.

Rules that apply, in general terms

This isn't legal advice. Your legal and information security units need to interpret the requirements that apply to you, and we don't claim that using Wrentrix satisfies any of them.

• KVKK applies to public institutions as data controllers, with some specific provisions. Telemetry from citizen-facing services can hold national ID numbers, addresses and health or social data in URLs and logs. The data residency page describes how to find and reduce it.
• Türkiye's information and communication security framework, including the 2019 Presidential Circular and the accompanying guide, sets out expectations for public bodies. These include data localisation for certain data and logging. Check the current text and how it classifies your assets.
• In the EU, GDPR applies, and NIS2 includes public administration entities within its scope, subject to how each member state has implemented it.
• Records and retention rules may require keeping certain logs for a stated period. Others may require limiting retention. Compare both to your storage planning, and ask us about retention in Wrentrix for your version.

Sensitive categories deserve special care. Health and social assistance data may appear in URLs if you're careless. A monitoring view that shows such a URL to every technician is an access problem, even when all of it is on your own hardware.

Questions to include in a procurement

Whichever product you are considering, a technical specification tends to be stronger if it's written around things you can test. Some suggestions:

1. The product must run with all outbound traffic denied for a defined period, with no loss of function.
2. No component may require privileged containers or root. Vendors should show this on a test cluster.
3. Installing the agent must not restart any workload, and agent failure must not stop new pods from starting.
4. Telemetry must be accepted over open standards, so instrumentation remains usable if the product changes. OTLP is the obvious one.
5. Audit records must cover administrative changes, and it must be possible to export them.
6. Any AI feature must be able to run on local hardware and be fully disabled.
7. The interface and documentation must be available in the required languages.
8. Include a proof of concept on a real system, with a controlled failure for diagnosis.

When this may not be the right fit

• A small institution with one or two simple websites and no sensitive data may need only basic uptime and host monitoring.
• If systems are entirely run by an outside contractor who already provides monitoring, make sure a second tool would actually have an owner.
• If you have no OpenShift, Kubernetes or Linux footprint, talk to us first, since those are the platforms described here.

Frequently asked questions

Can on-premise APM run in a closed government network?

Yes. Wrentrix runs fully air-gapped, with no license calls, no telemetry leaving the network and no external model. For closed networks, an image-less agent install is also available. Test this during a proof of concept by denying all outbound traffic.

Is Wrentrix available in Turkish?

Yes. Both the UI and the assistant are available in English and Turkish. That includes natural-language questions and the AI explanations, if you choose to enable AI.

How should I monitor a citizen portal on deadline day?

Define an SLO on the actual submission journey and alert on fast burn, since baselines can't predict a yearly event. Estimate peak load from last cycle's data and load test early, using real request patterns taken from traces. Check certificates and front door paths well before the date.

Can different departments have separate views?

Yes. Team-based RBAC offers scoped views mapped from LDAP or SSO groups, so each team sees its own services. If the requirement is absolute separation, discuss whether a separate installation is more appropriate. Always test scoping with a real non-admin account.

Does Wrentrix have government accreditation?

We make no claim of accreditation or certification on this page. For specific requirements in a tender or security review, write to info@wrentrix.com and describe what you need.