Skip to main content

Release Notes

Current version: 1.5.9. Upgrade method: for standalone deployments, change the tag of x-ops-image at the top of ops.yaml, then run docker compose -f ops.yaml pull && up -d; for Kubernetes, download the manifests again and apply them over the existing deployment. Data volumes remain unchanged, and monitoring history plus alert configuration are preserved.

Read Before Upgrading From 1.4.x
  • Data sources are managed only from the UI Data Sources page. ENV_MYSQL_*, ENV_REDIS_*, ENV_KAFKA_ENDPOINTS, ENV_ELASTICSEARCH_*, ENV_MONGODB_URI, ENV_PROMETHEUS_HOST, ENV_FLINK_URL, and similar variables in ops.yaml / ConfigMap are no longer read (the startup log lists them). Existing data sources are not affected. You can delete those lines.
  • Logs and traces require two different buckets (ENV_S3_BUCKET_LOKI / ENV_S3_BUCKET_TEMPO), and both buckets must be created before deployment. ENV_S3_ENDPOINT should be host:port, without http://.
  • For already-running instances, do not change data volume paths to match the new documentation. The new /data/mdis/ layout is only for fresh installations.

v1.5 - July 2026​

Configuration entry points are consolidated into the UI, and Kubernetes monitoring plus object-storage usability are now complete.

New​

  • Bulk import / export for data sources. The Data Sources page supports YAML / JSON bulk import, including downloadable commented templates. Import is idempotent by type + name, so the same file can be imported repeatedly. Each entry is validated and connection-tested during import, and you can run Validate only first. One-click export to YAML in the same format is also supported for backup, reinstall recovery, and copying to another environment, with without passwords and with plaintext passwords options. The API POST /api/alert/sources/import is also available.
  • Test Connection also verifies whether data is actually collected. A reachable port and valid credentials do not necessarily mean charts have data; target delivery, collector process startup, and metric scraping still need to succeed. The test now queries the platform Prometheus at the same time and distinguishes connected and collecting from connected but no data yet. The latter includes causes and self-check queries. The list Status column now shows Connected - Collecting / No Data.
  • Kubernetes collector component mode. Only Prometheus + kube-state-metrics are installed in the monitored cluster as collectors, and metrics are pushed back to the platform through remote_write. This supports two scenarios: the platform runs outside the monitored cluster, and one platform monitors multiple clusters. All collection happens inside the monitored cluster; the apiserver, kubelet, and kube-state-metrics do not need to expose any port. The cluster only needs outbound access to the platform. Dashboards provide a Cluster dropdown at the top.
  • The gateway adds Bearer-authenticated metric and log write endpoints (ENV_PROMETHEUS_REMOTE_WRITE_TOKEN / ENV_LOKI_PUSH_TOKEN), enabling multi-cluster onboarding and cross-cluster log pushes.

Changed​

  • Data sources now have a single entry point: the UI Data Sources page (breaking change; see the warning above). Slow-query diagnostic targets now come from MongoDB data sources whose purpose includes Diagnose. MongoDB is no longer a built-in data source and can now be edited or deleted like other sources. Only Prometheus remains built-in.
  • Kubernetes monitoring now requires the platform to run inside the monitored cluster (incluster), or collector components must be installed in the monitored cluster. The previous external scraping method (static), which required a Bearer Token and three NodePorts, and the Kubernetes cluster data source type have been removed.
  • Logs and traces now use two independent buckets. Component data directories are unified as /data/mdis/<component>. Cluster manifests provide example bucket names mdis-loki / mdis-tempo.
  • Namespace, node label, and taint key are unified as hap-ops.
  • The Limits Ratio on K8s dashboards is the ratio between container limits and node allocatable resources. Kubernetes allows overcommit by design, so it is no longer highlighted in red as a usage threshold.

Fixed​

  • Several root causes of empty Kubernetes monitoring after deployment: the gateway Service did not expose ops-server port 8081 and lacked ENV_OPS_SD_URL, so collectors could not fetch service discovery data; the ops-agent Service had to be headless, otherwise all dynamic ports were refused; the single-file ops.yaml did not create the namespace and lacked ServiceAccount / ClusterRole / kube-state-metrics. Manifests and documentation have been corrected. kubectl apply -f ops.yaml now installs everything and produces data immediately.
  • The K8s dashboard Cluster and Namespace dropdowns could not load values, which also left container, Pod dropdowns, and related panels empty. The cluster identifier is now injected directly in the collection configuration, and namespaces now use metrics that are always exposed by newer kube-state-metrics.
  • Three causes of MongoDB data sources collecting no metrics: credentials entered in the UI were not passed to the collector process; multi-node replica set connection strings conflicted with the collector's direct connection mode; the collector enabled items that required additional database permissions, and insufficient privileges interrupted the entire metrics endpoint. All have been fixed, and collection recovers after upgrade.
  • The Host Monitoring dashboard had no data at all during 1.5.8. A hidden filter on the host dashboard was incorrectly tied to the K8s cluster label, while host metrics do not carry that label. The metrics were always present. Upgrading to 1.5.9 restores the dashboard with no configuration change.
  • Three misleading slow-query behaviors: selecting the Diagnose purpose required a gateway restart to take effect (now immediate); when enabling slow query failed on the target database, the UI still showed Enabled (now it reports insufficient permission and provides manual commands); all exceptions were shown as slow-query recognition policy not enabled (now messages distinguish no target database, insufficient account permission, failed status read, and truly disabled).
  • Collection status was inaccurate: host sources always showed Not Collected (hosts are scraped directly by the platform Prometheus, not through ops-agent, and now the actual scrape result is queried); a running collector process could still show process exited (now it distinguishes port not listening, response interrupted, scrape timeout, and no data, and points to the relevant log file); Flink connectivity was invisible in the list (now included in connectivity checks).
  • Kubernetes no longer logs repeated docker.sock connection errors. ops-alloy now decides whether to collect Docker logs based on whether that socket exists. If you previously mounted the host docker.sock into ops-alloy to silence the error, remove it. That collects host container logs, not Pod logs.
  • The collector remote_write example address now includes the /prometheus/server/ prefix. The old example returned 404 and only retried silently in container logs. The two K8s manifest sets no longer push metrics back to the platform itself.
Patch Versions Included in This Series (1.5.0 - 1.5.9)
VersionMain Changes
1.5.9Host dashboard regression fix, data source export, connection test verifies actual collection
1.5.8K8s cluster identifier injected during collection, slow-query target takes effect immediately, Flink connectivity status
1.5.7Single-file ops.yaml completes K8s collection objects, Bearer write endpoints
1.5.6Multi-node replica set MongoDB collection
1.5.5MongoDB collection credential propagation, Kubernetes collector component mode
1.5.4Docker log collection enabled only when needed under Kubernetes, cluster manifests available for download
1.5.3Kubernetes monitoring consolidated to incluster
1.5.2Data directories unified as /data/mdis/<component>
1.5.1Logs and traces split into independent buckets
1.5.0Single data source entry point, bulk import

v1.4 - July 2026​

The self-developed alerting subsystem replaces Grafana alerting, and delivery changes to a single image.

New​

  • Built-in alerting subsystem, replacing the former Grafana alerting. It includes seven monitoring types: base resources with custom PromQL, ports, SSL, MySQL, MongoDB, Kafka backlog, and Kafka rebalance. The warning -> alert -> recovery state machine reduces noise and notifies only on state changes. Notification channels include Feishu, DingTalk, WeCom, email, and custom Webhook. Global alert history can be filtered by type, status, and time.
  • Unified data source management. A new top-level Data Sources page centrally manages hosts, middleware, K8s, and Flink, with multiple instances supported. The left menu is displayed dynamically based on enabled data sources. Test Connection performs real authentication. Credentials are AES-encrypted. Adding a data source in the UI automatically starts the exporter and registers the scrape target, without changing environment variables or restarting.
  • Collection status and post-deployment self-check. The Data Sources page directly shows Collecting / No Data / Stopped / Not Collected. Red states reveal the raw failure reason and provide copy-ready troubleshooting commands. The Overview page summarizes six states: metric collection, host monitoring, HAP service logs, tracing, alert notification, and slow-query diagnostics.
  • MongoDB slow-query diagnostics support sharded clusters, and multiple instances are automatically aggregated for analysis.

Architecture Changes​

  • Single-image delivery: all components are merged into ops-allinone and distinguished by ROLE, so only one image needs to be pulled or imported offline. The ops.yaml structure has changed accordingly; regenerate it from the latest deployment documentation.
  • Independent alert data storage: a new ops-mongo container stores rules, state, history, channels, and data sources, decoupled from the business database.
  • New required setting: ENV_ALERT_CRYPTO_KEY (credential encryption key).
  • The former Grafana alerting / notification / silence screens have been removed. Recreate rules in the new Alert Management page.

Fixed​

  • Host monitoring disappeared after upgrade during 1.4.8. The upgrade migration missed the host type, and upgrading to 1.4.10 restores it automatically.
  • Data sources created through the API defaulted to disabled, and Kafka / MongoDB / MySQL purposes were empty. The data sources were created but never collected. They are now enabled by default and default purposes are applied.
  • The same MongoDB could be registered twice, and built-in data source purposes were reset on every restart.
  • MySQL / MongoDB monitoring did not decrypt passwords, causing connection failures and false alerts.
  • Object storage compatibility: Loki uses path-style and Tempo uses bucket_lookup_type, supporting Tencent Cloud COS and Alibaba Cloud OSS.
  • Failed ops-mongo connection now retries in the background with backoff instead of permanently disabling the alerting subsystem. Startup order no longer requires manual intervention.
  • Trace service names strip namespace suffixes and no longer only support default.
Patch Versions Included in This Series (1.4.0 - 1.4.10)
VersionMain Changes
1.4.10Host monitoring upgrade loss fix, API data source defaults, deployment self-check
1.4.8Data source collection status
1.4.6Trace service names support any namespace
1.4.5Background retry for ops-mongo, data sources enabled by default after creation
1.4.4Prometheus size-based retention
1.4.3Object storage compatibility, istio tracing appProtocol
1.4.1MySQL / MongoDB credential decryption
1.4.0Built-in alerting subsystem, unified data sources, single-image delivery

v1.3 - June 2026​

  • Kubernetes cluster monitoring, with new K8s dashboards and menu entries.
  • A single agent supports monitoring multiple middleware instances.
  • Loki data retention (30 days by default) and the delete API are enabled.

v1.2 - April - May 2026​

  • Added log viewing, APM distributed tracing, and a unified interface for metrics / logs / traces.
  • The log panel is split into Container Console and Service Logs. Service Logs support automatic expansion of structured fields and full-text search by phone number / ID / traceID, and all filters support multi-select.
  • Supports subpath deployment, such as mounting the reverse proxy at /mdis.
  • Deployment resource requirements corrected to 4C / 8G.

v1.1 - February 2025​

  • MongoDB slow queries and index suggestions, with alert configuration support.

v1.0 - January 2025​

  • Initial version: system resource monitoring.