Best Practices for MSPs: Designing Log Retention That Protects Margin and Scales For MSPs, logs are both essential and risky. They power incident response, compliance, and SLA accountability, but uncontrolled ingestion and overextended retention can quietly erode margin. Many MSPs default to flat retention across all clients and log types. It’s simple, and it doesn’t scale. Log Partitions shift logs from passive storage to active governance, aligning retention, ingestion, and tenant isolation to business value and service tiers. Here are the best practices to design Log Partitions intentionally , not reactively. 1. Design Retention Around Business Impact, Not Log Volume Not all logs carry equal value. A firewall audit log supporting a compliance investigation does not have the same business importance as a verbose application debug stream. A practical approach: Use shorter retention (e.g., 7 days) for high-volume, low-signal logs like debug or verbose syslogs. Use longer retention (e.g., 90 or 365 days) for compliance-critical or audit-relevant logs such as Windows Security or firewall logs. For MSPs, this often aligns naturally to client tiers: Bronze → operational visibility Silver → extended retention Gold → compliance-ready log preservation The key shift is this: Retention should reflect risk and SLA obligations, not just ingestion volume. 2. Align Partitions to Client or SLA Boundaries In multi-tenant environments, clean separation matters. Log Partitions allow you to segment logs by: Client SLA tier Service offering Use case For example: AcmeCorp-30d Tier2-Clients-90d ClientA-Compliance-365d This makes retention policies explicit and auditable. More importantly, it reinforces tenant isolation. A properly defined tenant boundary ensures logs are segmented cleanly and investigations remain scoped to the appropriate client environment. Flat retention across all clients may feel simpler — but it blurs cost accountability and governance boundaries. Example view of partitions segmented by customer, each with distinct retention policies. 3. Establish Routing Logic Before Ingestion Begins Partitions are assigned based on defined routing rules that rely on: tenant.id (required) Custom resource properties Defined partition rule logic Partition routing is not just about “good tagging hygiene.” Routing accuracy depends directly on these required properties being consistently defined. Tagging consistency directly impacts routing accuracy — and is required. Partition design should ideally happen before ingestion begins, since logs cannot be moved retroactively. You can create new partitions later, but only new logs will route there. Previously ingested logs retain their original partition and retention policy. For MSPs managing hundreds or thousands of resources, this is where operational maturity shows up. Clean property discipline enables scalable, automated partition routing. Inconsistent definitions create ambiguity and governance gaps. Partition routing rules are defined and managed centrally within the Logs Management interface. 4. Use Ingest Guardrails to Prevent Cost Surprises Log growth is rarely linear. New devices, verbose logging, configuration changes, or onboarding new clients can increase ingestion quickly. Each partition can be configured with: Ingest limits Automated shutoff rules Optional restart aligned with billing cycles This is one of the most powerful governance tools available. Instead of reacting to overages after they occur, MSPs can proactively contain ingestion within defined boundaries. This transforms logs from a cost liability into a controlled service component. Predictability protects margin. 5. Structure with Naming Conventions That Scale Clear naming improves governance and troubleshooting. Effective patterns include: Retention-based: 30-day-ops-logs Compliance-based: 365-day-audit Tenant-based: TenantA-prod-logs Consistent naming across tenants simplifies automation, reporting, and internal reviews. When partitions are named clearly, conversations about cost, retention, and SLA alignment become easier — both internally and with clients. 6. Monitor Partition Usage Regularly Log governance is not a one-time configuration. Best practice includes reviewing partition usage to identify: Unexpected ingestion growth Partitions approaching ingest limits Opportunities to reduce retention where risk is low Clients whose log needs are evolving This review cadence turns logs into a managed service component — not just stored data. The Usage page provides visibility into subscriptions, partitions, and ingest trends across your environment. 7. Understand the Design Boundaries Intentional design also means understanding architectural constraints. Partition-level constraints: Logs cannot be retroactively reassigned to new partitions. Queries are scoped to a single partition. Partitions themselves are flat — sub-partitions are not capable of group structure or hierarchy. Partitions have defined capacity limits per portal. Resource groups, however, can absolutely be hierarchical. Partition routing is driven by tenant and resource properties — not by nested partition structures. Current routing limitation (v1.0): Partitions route logs at the resource level. Different log types from the same resource cannot be sent to separate partitions. For example, you cannot route these from the same resource: Windows Security logs → Partition A Windows System logs → Partition B These are architectural guardrails, not blockers. Planning with them in mind ensures clean tenant isolation and predictable governance. When Should MSPs Use Log Partitions? Log Partitions are especially valuable when: Clients require different retention periods Compliance requirements vary across tenants Log ingestion has become unpredictable You want clear separation between noisy operational logs and long-term audit logs You need enforceable ingestion boundaries per client In short: when log storage becomes strategic. MSP Log Governance Checklist Before rolling out or refining Log Partitions, confirm: ☐ Logs have been classified by business impact (not just source). ☐ Retention periods align to SLA tiers or compliance needs. ☐ tenant.id and required custom resource properties are consistently defined. ☐ Partition routing rules are intentionally configured and validated. ☐ Ingest limits and shutoff policies are defined per partition. ☐ Naming conventions are standardized. ☐ Partition usage is reviewed on a recurring basis. ☐ Default partition reliance is intentional — not accidental. Final Thought Log Partitions allow you to align retention and ingestion with business value — turning what was once an unpredictable cost center into a governed, scalable service capability. ✅ Design intentionally . ✅ Review consistently . ✅ Protect both your clients and your margins. Dive Deeper Looking to go further? These resources provide additional guidance on retention strategy, partition configuration, and turning logs into a competitive advantage. Log Partitions Support Documentation What is Log Retention? [blog] From Cost to Competitive Edge: How MSPs Can Unlock Profit with LM Logs [on-demand webinar] Upcoming Event: Logs4Lunch [partitions-focused] Apr 8, 12:00 – 12:45 PM (CDT)
