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)