Monitoring Collabora Online with Prometheus starts with knowing your load
Collabora Online runs its editing sessions in the browser, so when the server slows down or a Kit process fails, the first signal users give you is that documents will not open or freeze mid-edit. Prometheus scraping gives the team a continuous record of how many documents are open, how much memory each document process uses and how often errors occur, and Grafana dashboards turn that record into capacity views. Teams need this before a rollout to set baselines, after user numbers or document sizes grow, and whenever users report failures that no alert caught. Without these numbers, sizing decisions and incident reviews rest on guesses.
Collabora Online is licensed under the Mozilla Public License 2.0 (MPL-2.0), and it can be deployed from Docker images, system packages or Kubernetes, so the metrics endpoint you scrape depends on how your installation was built. Confirm in your own environment how the metrics endpoint is exposed, which port it listens on, and whether it is reachable only from your monitoring network. Check the Collabora Online Helm chart README if you run on Kubernetes, since it sets the resource requests and limits you will compare against your observed memory use.
The monitoring stack is separate software that your team must install, run and patch. Prometheus is Apache-2.0 licensed, so the project itself has no paid edition, but its storage is local and not clustered, and Alertmanager and Grafana each need their own deployment and retention decisions. Plan who owns those components, where their data lives and how alerts reach an on-call rota before the first production rollout. Treat the monitoring setup as part of the Collabora Online deployment scope, because an unmonitored editing service is harder to defend in an incident than one with a known baseline.
Deployment options for the monitoring stack
This table compares four places to run Prometheus and Grafana for Collabora Online metrics: a dedicated monitoring host, the same cluster as Collabora, Kubernetes with Helm charts, and Grafana Cloud. Read each row for who operates the stack and what it costs you in control, storage and upkeep. The main takeaway is that the choice follows from who will own the storage, upgrades and alert routing, not from the dashboards themselves.
| Option | Fit | Who operates it | Main trade-off |
|---|---|---|---|
| Dedicated monitoring host | Small or single-site Collabora fleets with a clear owner for one Linux server | Your platform or sysadmin team, including OS patching and backups | Prometheus local storage is not clustered or replicated, so one host is a single point of failure |
| Same cluster as Collabora | Teams that want metrics close to the pods and little extra infrastructure | Your platform team, sharing capacity with the Collabora workload | Monitoring fails when the cluster it watches fails, so alert on an external path too |
| Kubernetes with Helm charts | Teams already running Kubernetes and managing other services the same way | Your platform team, through chart values and version pins you maintain | Chart configuration adds moving parts, and you must confirm storage and retention settings yourself |
| Grafana Cloud | Organizations that prefer a managed service and can send metrics outside the host | Grafana Labs runs the service; you own the agent, data sources and alert rules | Free tier, Pro starting at 19 US dollars per month plus usage, and Enterprise with a 25,000 US dollar yearly minimum (Grafana pricing) |
| Grafana with SQLite default | Trials and labs only | Whoever installs Grafana | Grafana's installation docs say SQLite does not scale for production, so use MySQL or PostgreSQL for production |
Setting up scraping, storage and dashboards
This sequence takes Collabora Online metrics from a verified endpoint into Prometheus, keeps them for the capacity window you need, routes alerts through every Alertmanager instance, and presents them in Grafana dashboards built from version-controlled files. Each step closes with a check, so the team knows the pipeline works before alerting depends on it.
Confirm the metrics endpoint for your version
Owner: the monitoring engineer, working with the Collabora Online administrator. Check the release notes and documentation for your installed branch to confirm that a metrics endpoint exists, its path, its port and whether it requires authentication. Record the exact version in your runbook, because endpoint behavior can differ between branches such as 25.04 and 26.04. Done when a manual HTTP request from the Prometheus host returns metric text from one server, and you have written down the address Prometheus will scrape.
Restrict access to the metrics endpoint
Owner: the platform team, with the network and security team. Limit the metrics port to the Prometheus servers using firewall rules, network policy or a reverse proxy allow list, and keep it off the listener that serves editing traffic. Scrape configuration can add TLS and basic authentication, so review the Prometheus security model documentation and choose the controls that fit your environment. Done when a request from an unapproved host is refused and the approved Prometheus host still receives metrics.
Add scrape targets for every instance
Owner: the monitoring engineer. Add a scrape job to the Prometheus configuration that lists each Collabora Online server or pod as a target. Use static_configs for a fixed set of servers, or service discovery on Kubernetes where pods change. Scrape each instance directly, not through the load balancer that routes by WOPISrc, because a balanced request would reach an arbitrary instance and leave the others unmeasured. If you set replica counts by hand, update the target list whenever they change. Done when the Prometheus targets page shows every instance as up and each series carries a stable instance label.
Set retention and decide on remote write
Owner: the monitoring engineer, with the team that owns long-term storage. Keep the default 15-day retention or set it by time or size with the storage flags, such as --storage.tsdb.retention.time and --storage.tsdb.retention.size, sized to the capacity-planning window you need. Local storage is not clustered or replicated, so manage the data directory like a single-node database with its own backup plan. If you need longer history, decide whether to configure remote write to an external store and name the team that will operate it. Done when the retention settings are recorded in the service definition and disk use is tracked.
Point Prometheus at every Alertmanager
Owner: the monitoring engineer. In the alerting section of the Prometheus configuration, list every Alertmanager instance as a separate target instead of placing a load balancer in front of them. Alertmanager clusters coordinate grouping, inhibition and silences between members, and that coordination depends on Prometheus reaching each one directly. If you run a single Alertmanager, the same list has one entry. Done when the Prometheus status page shows each Alertmanager as active and a test alert reaches its configured receiver. The Alertmanager documentation describes the cluster options.
Provision Grafana dashboards as code
Owner: the monitoring engineer. Define the Prometheus data source and the Collabora dashboards as YAML provisioning files that Grafana loads at startup, and store the dashboard JSON in Git so every change is reviewed. Where the team already uses Terraform or Git Sync, follow that workflow instead. Start with panels for documents open, memory per Kit process and error counts, the same signals used for alerting. If Grafana runs in high availability, use MySQL or PostgreSQL for its configuration database. Done when a new Grafana instance built from the repository shows the same dashboards with no manual edits.
Verify scraping and alerting end to end
Owner: the monitoring engineer, with the Collabora Online administrator. Run a PromQL query against each target to confirm samples arrive for every metric you plan to alert on, and check that results return for every instance label. Then force an alert in a test environment where possible: lower a threshold temporarily or stop the metrics endpoint on one test instance. Confirm the rule fires in Prometheus, reaches Alertmanager and notifies the receiver, then restore the original rule and endpoint. Done when the alert clears and the dashboard values match your test query results.
Which Collabora Online numbers to alert on
Collabora Online capacity is driven by how many documents are open and how much memory each Kit process holds, so most alerts follow those two numbers. Errors and server availability tell you when the service is failing, and the capacity trend tells you when the current pod count will stop being enough.
Documents open per server
The count of documents currently open on each Collabora Online server is the closest thing to a load signal you have. Collaborative editing ties every user on one document to one pod, so a rising count on a single pod can overload it while the others sit idle. Compare the number per pod, not only the total, and record the normal peak for each working day. Confirm the exact metric name for your release in the metrics output of your own instance before writing any rule.
Memory per Kit process
Each document session runs in a Kit process, and its memory use grows with document size and editing activity. Compare the memory per Kit process and the total per pod against the Helm chart's recommended 8000 MiB limit and 6000 MiB request for each pod. Alert on sustained growth that approaches your chosen ceiling, since a pod that hits its memory limit can drop every open session on it. Set the thresholds from the baseline you measure in your own environment.
Error counts by type
Track errors as separate series by type rather than as one total, because a rising count of WOPI request failures points to a different cause than a rising count of document load failures. A sudden jump after a network or DNS change often means a WOPI allow list or protocol mismatch. Alert on the rate of change over a short window, and review the error families with your Nextcloud or other WOPI host logs when the alert fires.
Server availability
Availability is the simplest check: whether each Collabora Online server answers its health endpoint and whether Prometheus can scrape it at all. A scrape failure can also mean the metrics endpoint is blocked by a firewall or reverse proxy rule, so treat it as a question about the path as well as the process. Alert on a target being down for longer than a short grace period, and keep a separate probe that loads a test document from the WOPI host's side.
Pod restarts and load balancer routing
Restarts show up as resets in counters and as gaps in the series, and each restart drops any sessions held by that pod. Because load balancers must route by the WOPISrc parameter so that all users on one document reach the same pod, a routing change can split a document across pods. Alert on restart counts and on any document seen on more than one pod. Confirm the metric names and labels for both in your release.
Capacity trend over weeks
A single peak tells you little, so chart the weekly maximum of documents open and memory per pod across several months. A rising baseline means the pod count you set manually will eventually be too small, and because autoscaling is disabled for this workload, you must add replicas yourself. Review the trend monthly, and plan capacity changes ahead of the date the trend crosses your own threshold.
Using Grafana dashboards for capacity planning
Because the Collabora Online Helm chart disables horizontal pod autoscaling, replica counts are set by hand, so growth has to be planned from load you have actually observed. Build a Grafana dashboard that plots concurrent open documents and active sessions against the number of Collabora pods over the same time range, and add the memory and error panels from the Prometheus metrics alongside them. The question to answer is how many documents each pod carries at peak, how much of its memory budget is used at that point, and how much headroom remains before a new replica is needed. Confirm the per-pod resource requests and limits in your chart values against the chart README before you set any target, because the sizing figures in your dashboard are only meaningful against the limits your pods actually run with.
Provision dashboards and data sources from files, not by hand in the Grafana interface. Grafana provisioning loads data sources, dashboards and alerting resources from YAML or JSON files at startup, and it documents further as-code options including Terraform and Git Sync. Keep dashboard JSON in version control, review changes the same way you review chart changes, and redeploy Grafana from the same files so that a rebuilt instance shows identical panels. Terraform is worth considering if your organization already manages Grafana resources that way. Either route works, but choose one and keep the dashboard definitions out of the database that stores Grafana's configuration.
If more than one Grafana instance serves the dashboards, the configuration database cannot be SQLite. Grafana documents SQLite as unsuitable for production, and its high availability pattern uses two or more active-active servers behind a load balancer sharing a MySQL or PostgreSQL database, with database-backed auth tokens so users can reach any node. Confirm the supported database versions in the Grafana installation documentation before you choose one. Alerting needs extra configuration in this setup to avoid duplicate notifications, and Grafana Live has limitations in high availability, so test notification delivery from a single alert rule before you rely on it for capacity alarms.
Securing the metrics endpoint and the monitoring stack
Metrics describe your documents, users and infrastructure, so the endpoints that expose them need the same care as the editing service. The cards below cover who can read metrics, how Grafana is hardened, what must stay out of labels and dashboards, and how to keep Prometheus, Grafana and Collabora Online patched.
Restrict access to the metrics endpoint
Collabora Online's metrics endpoint should not be reachable from user networks or the public internet. Decide whether to require authentication at the scrape path, restrict it to the Prometheus server's address with network policy or a firewall rule, or both. Check it from outside the monitoring network after every ingress or proxy change, because a rule that worked for the internal scraper can expose the endpoint when a reverse proxy begins forwarding paths it did not forward before. Confirm the exact path and access options against the Collabora Online documentation for your version.
Authenticate Prometheus scrapes
Prometheus pulls metrics from each target, so the scrape configuration is part of your security boundary. Store any scrape credentials or bearer tokens in files with restricted permissions rather than inline in the configuration, and rotate them on a schedule your team can actually follow. Prometheus's security model describes what the project itself does and does not protect, so read it before deciding which controls belong in front of Prometheus and which belong in the network layer.
Harden Grafana cookies and content policy
Grafana's hardening guidance recommends secure and SameSite cookies, a Content Security Policy, and Trusted Types. Enable secure cookies only when Grafana is served over HTTPS, and test that dashboards, embedded panels and any plugins still load under the policy you set. Also hide the Grafana version from unauthenticated users and require authentication for Grafana's own metrics endpoint. Verify each setting in a staging instance, since strict policies often break panels that were working before.
Enable DNS rebinding checks
Grafana can verify the domain used in requests against the configured root URL, which blocks DNS rebinding attacks against an instance that is reachable on an internal network. Set the root URL to the name users actually type, and make sure your reverse proxy passes the original host header through. Test by requesting Grafana with an unexpected host name and confirming the request is refused. Changing the public name later requires updating this setting along with any OAuth callback URLs.
Keep document content out of metrics
Collabora Online metrics should describe counts, memory, timings and error totals, never file names, document identifiers, user names or document text. Check every label you add in Prometheus relabeling and every panel query in Grafana, because a label that carries a document or user identifier creates both a privacy exposure and a cardinality problem. Review dashboard annotations, panel titles and alert payloads too, since Alertmanager notifications are often copied into chat channels and tickets with broader access than the monitoring system.
Patch on the release cadence
Prometheus minor releases stop receiving bug fixes after six weeks, so plan regular upgrades to a supported line, and use the long-term support branch when you want a longer patch window. Grafana publishes patch releases at least monthly and supports each minor release for nine months. Collabora publishes security advisories for Collabora Online itself, so subscribe to them and track the server version alongside the monitoring stack. Record which versions run in each environment so a fixed advisory can be confirmed in production.
Questions buyers ask about Prometheus monitoring for Collabora Online
What drives the cost of monitoring Collabora Online with Prometheus?
The software itself costs nothing to license, so the cost comes from the infrastructure, the storage, the implementation work and the people who run the stack. Prometheus is licensed under Apache-2.0 and has no paid enterprise edition, according to its GitHub repository. Costs you should expect to see in a quote are:
- Servers for Prometheus, Alertmanager and, if you use it, Grafana, sized for your number of Collabora Online targets and retention period.
- Storage, since Prometheus keeps data locally for 15 days by default and its storage is not clustered or replicated.
- Implementation effort for scrape configuration, alert rules and dashboards.
- Ongoing operation, including upgrades, which recur as Prometheus ships a new minor release every 6 weeks.
Ask for each item to be priced separately so you can see which parts scale with your deployment.
Can our own team set up Prometheus monitoring for Collabora Online without outside help?
Yes, a team with Linux, container and Prometheus experience can build this without a partner, provided it has the time and skills to maintain it. The work is mostly scrape configuration, alert rules, dashboards and runbooks, and the Prometheus and Grafana documentation covers each step. The points that usually decide the question are whether someone owns the stack after go-live, whether anyone has tested alerts against real Collabora Online load, and whether the team can handle upgrades on the schedule the projects publish. A partner is worth considering if those skills are thin, because the monitoring has to be trusted during an incident.
How long does a Prometheus monitoring rollout for Collabora Online take?
The duration depends on how many Collabora Online servers you run, whether you already operate Prometheus, and how many dashboards and alerts you need before go-live. A single server with an existing Prometheus instance is a much smaller job than a multi-node deployment with Alertmanager high availability, Grafana behind a load balancer and retention sized for capacity planning. No duration is fixed in the supplied material, so ask for a timeline in the written scope that lists each deliverable, the environments covered and the review points. Fixed-scope engagements agree deliverables and timelines in writing before work starts.
What does the monitoring work need from our environment?
It needs network access from Prometheus to the metrics endpoint of each Collabora Online server, plus access to Alertmanager and any notification channels you use. You also need storage that fits your retention target, since local Prometheus storage is not replicated and should be managed like any single-node database. On the people side, you need an owner for alert routing and a clear on-call path, because alerts only help when someone acts on them. Confirm with your Collabora Online documentation which metrics the version you run exposes and how the endpoint is protected, and agree who can read dashboards that may show user activity.
Does Grafana licensing add a cost to this setup?
Grafana is optional, and the open-source edition is the usual choice for dashboards. Grafana relicensed Grafana, Loki and Tempo to AGPLv3 on April 20, 2021, and offers Grafana Enterprise as a non-AGPL commercial option, according to the Grafana Labs licensing page. Features such as SAML, team sync and SCIM provisioning are available only in Enterprise and Grafana Cloud, according to the Grafana authentication docs. If your identity requirements depend on those features, include that in the cost comparison. Confirm the licence terms with your legal team before you distribute or host modified versions.
Can Prometheus metrics replace Collabora Online audit logs?
No, metrics and audit logs answer different questions, so you need both if you must show who did what. Prometheus values reliability over precision and is not suited to uses that require 100% accuracy, according to the Prometheus overview docs. Metrics show trends such as documents open, memory per Kit process and error rates, which is what capacity planning and alerting need. Audit records of individual user actions belong to Collabora Online logging and audit configuration, which should be shipped to your log platform. Confirm with your compliance team which evidence they require before deciding what to retain.
How often does the monitoring stack need upgrades?
Prometheus publishes a new minor release every 6 weeks, and a minor release generally stops receiving bug fixes after those 6 weeks, according to the Prometheus release cycle page. Teams that want longer support can run the long-term support line, which receives bug fixes for one year. The current LTS line is 3.13, supported until July 31, 2027, according to the same page. Grafana publishes patch releases at least monthly and supports each minor release for 9 months, according to its upgrade guidance. Plan these upgrades as recurring operational work and include them in the support scope you agree with any partner.
How DeployOpen scopes and runs Collabora Online monitoring
DeployOpen sets up Collabora Online monitoring under a fixed-scope written agreement that lists the exact endpoints to scrape, the dashboards to build, the alert rules to ship and the handover items the client's team will receive. The scope is agreed before work starts, and a quote follows from it. DeployOpen does not publish a price list, so the fastest way to get an accurate figure is to bring a list of your Collabora Online servers, the number of WOPI hosts in front of them, the Prometheus and Grafana instances you already run, and any retention or on-call requirements. Ask the provider to state in writing which items are one-time work and which recur.
The work is carried out inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks, so Prometheus, Alertmanager and Grafana stay under your control and no metrics leave your environment. Before scoping, confirm where the metrics endpoint is exposed and who may reach it, since the Grafana hardening guidance on requiring authentication for metrics applies to the stack as a whole. DeployOpen is a Chainscore Labs company. It prepares monitoring evidence and runbooks that your team or an independent auditor can review, but it does not issue audit reports, attestations or certifications.
Ongoing tuning is handled separately. Thresholds for documents open and memory per Kit usually need adjustment after the first months of real use, and Prometheus and Grafana releases need to be applied on their own schedule. DeployOpen offers these as optional retainers, which you can add or decline without changing the original build scope. When comparing offers, ask whether the retainer covers alert rule review, dashboard changes, Prometheus and Grafana version upgrades and response times for alerts, and whether it includes a review of how Collabora Online version changes affect the metrics you rely on.
