Multi-Tenancy Isolation in VictoriaMetrics, VictoriaLogs and Grafana: Building Client Separation in a Shared Stack
Voltir provides monitoring for servers, 1C systems and databases as both a cloud service and on-premise installation. In the cloud all clients share one stack containing vmstorage, vmselect, vminsert, VictoriaLogs, Grafana, vmalert, Alertmanager and Postgres. Separate stacks per customer would require ten full copies of caches and ten update cycles per release, so the company keeps a single stack and implements isolation manually at each layer.
Every tenant receives a numeric account_id. VictoriaMetrics routes writes and reads through paths such as /insert/<account>/… and /select/<account>/…, while VictoriaLogs and VictoriaTraces read the account from the AccountID header. Nginx sits in front and calls the platform API via auth_request to determine the tenant from the Bearer token before forwarding requests. Storage endpoints are never exposed externally.
Each tenant has its own Grafana organization whose data sources are created by the platform with the account ID embedded in the URL or secureJsonData header. Users receive at most the Editor role; Org Admin is deliberately withheld because an administrator could change the data-source URL or header and read another tenant’s metrics or logs. The platform explicitly checks role values and rejects anything higher than Editor for tenant users.
Write authorization compares the account supplied in the URL with the account belonging to the token; a mismatch returns 403. For logs and traces the platform returns the correct account in the auth_request response and nginx overwrites any client-supplied header. VictoriaLogs only understands the AccountID header and silently ignores X-Tenant-ID, writing everything to account 0 if the header is missing.
A single vmalert instance reads all rule files. Each tenant’s rules file contains groups narrowed by an extra_filters clause containing the tenant’s account ID. VictoriaMetrics appends this filter to every selector, preventing a rule from seeing data outside its tenant. Global rules without filters were removed after one self-test rule began scanning thousands of deleted tenants and consuming excessive CPU.
During testing a rule containing the Russian string “пять минут” instead of a valid duration value caused vmalert to reject the entire rules directory on reload. Subsequent changes to other tenants stopped being applied, and a container restart would have left alerting completely disabled. The platform now validates durations, severity levels and Go templates before writing rule files, performs atomic replacement under lock, and reverts on reload failure.
Deleted tenants left behind rule files, Grafana organizations, users and time series. Over several months the team accumulated 196 orphaned rule files, 705 phantom Grafana users and more than three thousand stale accounts visible in /admin/tenants. A single cleanup module now removes every external artifact when a tenant is deleted, and an hourly reconciliation job compares files, organizations and storage accounts against the database, failing CI if any residue remains.
Resource isolation remains incomplete. All tenants share memory, CPU and disk. Heavy parallel queries from one dashboard or high-cardinality series from a single Kubernetes cluster can still trigger OOM events that affect every tenant. Per-container memory limits, reduced cache sizes in VictoriaLogs and request queuing mitigate but do not eliminate the shared-resource risk.
Related articles
Yandex Black October: How Architectural Flaws and Capacity Mismanagement Turned Data Center Losses Into a 11-Day Fintech Coma
In October 2026 three Yandex data centers in Central Russia were physically destroyed within days, triggering the collapse of Yandex Cloud and multiple core services. Between the first and third site failures engineers had 74 hours to restore quorum and rebalance workloads yet failed to do so because Control Plane components remained tied to the lost zone and spare capacity had been eliminated to cut costs. Core banking and BNPL systems entered Read-Only mode after losing quorum, forcing a complete stop-the-world reconciliation that lasted until 22 October. Backups stored inside the same regional S3 buckets proved unusable, resulting in a seven-day RPO and primary-key collisions after restoration. The incident exposed that Metro-Cluster designs had been incorrectly treated as full Disaster Recovery and that aggressive AP microservice patterns created logical split-brain conditions outside the database layer.
Astra Group Releases Low-Code Astra AI Platform for Building Corporate AI Agents in Closed Environments
Astra Group has launched the Astra AI Platform, a low-code constructor designed for creating corporate AI applications that operate entirely within closed circuits without reliance on foreign clouds. The platform targets small and medium businesses as well as large corporations, enabling rapid deployment of AI secretaries, technical support assistants, and other agents in days rather than months. It forms part of the broader Astra AI ecosystem and includes two main constructors: one for machine learning model training and deployment, and another for LLM-based language assistants, document search, and process automation. Users can assemble scenarios from visual blocks, debug them in real time, or extend functionality with custom Python code when needed. The solution supports RAG-based knowledge bases, integration with external tools such as CRM and ERP systems, and the coordination of multiple agents for distributed task handling. One demonstrated use case involves processing ten pages of engineering drawings and specifications in five minutes to prepare data for downstream systems. The product is already listed in the Russian domestic software registry and available to customers.
The Real Costs of Using Claude and GPT for Russian Businesses Exposed
Accessing generative AI models like Claude and GPT has become straightforward for Russian companies, yet calculating their true expenses remains complex. Hidden factors such as intermediary commissions, currency conversion rates, taxes, and the often-overlooked costs of model reasoning tokens can double or triple initial estimates. Founder Vitaly Nagay of the Heli service analyzed these financial and organizational risks for Russian firms relying on foreign AI providers. In one example, a support department processing 20,000 monthly queries sees costs rise from $240 to $480 when reasoning tokens are included. Nagay recommends evaluating providers by dividing actual ruble charges by the model's official dollar pricing to reveal hidden markups. Additional concerns involve data control, document compliance, and access history when employees use personal subscriptions. Companies are advised to verify billing details, data storage policies, and issue dedicated API keys with spending limits before procurement.
Decoding Windows 10 and 11 Error Codes: How to Identify Root Causes and Fix System Failures
Windows frequently reports problems using codes that seem aimed only at developers, leaving users to decipher issues like 0xc000007b, 0x800f081f, and Kernel-Power 41 on their own. The article explains that error codes typically describe failed operations rather than underlying causes, such as access denials stemming from permissions, security software conflicts, or corrupted components. It provides a structured diagnostic approach starting with version checks via winver, context analysis of when errors occur, and preservation of critical data before troubleshooting. Detailed tables cover common codes across update, application launch, driver, and boot failure categories, while sections address Blue Screens of Death, Windows Update problems, driver errors like Code 43, and event log analysis. Recovery methods including DISM, SFC, safe mode, and point-in-time restore are outlined with warnings against risky generic fixes. The guide emphasizes sequential diagnosis to avoid data loss and notes the end of Windows 10 support.