Procurement: Observability Tooling
What this is and who it’s for
This runbook tells you how to buy observability tooling — logging, metrics, tracing, and alerting — on a Maryland contract vehicle without overpaying or getting locked in. It’s for an agency tech lead or CIO who needs the capability and the procurement officer who has to put it on a contract. It assumes you already know what good observability looks like; the job here is converting that into a defensible requirement, the right vehicle, a SOW you can stand behind, and an evaluation that picks a tool on merit. If you can’t yet describe the signals you need and how long you’ll keep them, stop and read the prerequisites first.
Prerequisites
- You’ve read the [Observability technical-practice runbook]([FILL IN: observability runbook link]) and can name the four signals you need (logs, metrics, traces, alerts) and the questions each one answers. You cannot write a defensible requirement for a capability you can’t describe.
- Your agency has a stated data-retention requirement — how long each signal must be kept, by policy or regulation [VERIFY]. Retention is the single biggest driver of observability cost, so it has to be decided before you price anything.
- Your agency has determined its compliance posture for hosted services — whether StateRAMP or FedRAMP authorization is required, and at what impact level [VERIFY]. This narrows the vendor field before you start, so settle it up front.
- You know, roughly, your scale: number of hosts/containers, log volume per day, and metric cardinality. Per-host and per-GB pricing means scale, not features, usually decides the bill.
The practice
Run this as four moves in order: define the requirement, pick a vehicle, write the SOW, evaluate. The hosting model is the hinge decision — it changes the vehicle, the SOW, and the cost shape — so make it explicitly rather than letting a vendor make it for you.
Define the requirement
Write down four things before you talk to anyone: the signals you need, the retention per signal, the scale, and the compliance posture. State signals as outcomes (“p99 latency per endpoint,” “centralized error logs across services”), not product features. Set retention per signal — hot/queryable versus cold/archived — because vendors price these tiers very differently. Capture scale as numbers (hosts, GB/day, metric series), since this is what drives cost at every vendor.
Choose a hosting model
SaaS vendor (vendor-hosted)
The vendor runs everything; you send data and pay by volume or host. Fastest to stand up and lowest operational burden, but it sends agency telemetry to a third party — so the vendor must carry the required StateRAMP/FedRAMP authorization [VERIFY], and that requirement belongs in the SOW as a pass/fail gate. Procurement-wise this is a service subscription, which often maps cleanly to an existing IT-services or software vehicle. Watch the cost shape: per-GB and per-host pricing scales with your data, not your budget.
Self-hosted open source
You run the stack (for example Prometheus, Grafana, Loki, Tempo) on your own infrastructure. No per-GB licensing and full data control, which simplifies the compliance story because telemetry never leaves your boundary. The cost moves from license to labor and infrastructure, so the procurement is usually for implementation and managed-operations services plus the underlying compute — not for the software itself. Budget for the people who will run it; “free software” is not free to operate.
Managed cloud-native
You use the observability tooling built into the cloud provider your workloads already run on. Tight integration and one less vendor relationship, and it typically inherits the provider’s existing authorization [VERIFY], which can shorten the compliance review. The trade is portability: these tools are provider-specific, so the data-exit clause matters more here, not less. Procurement often rides the existing cloud-services vehicle as an add-on rather than a new contract.
Map to a vehicle
Match the model to the smallest vehicle that fits. A SaaS subscription under the small-purchase threshold [VERIFY] may not need a full RFP; a multi-year enterprise deal will. Self-hosted implementation work is a services buy and may fit a master services vehicle. Confirm the candidate vehicles in Procurement notes before committing.
Write the SOW
Fork the skeleton in Reference implementation. Keep the required signals, retention, and compliance posture as explicit, testable requirements — not preferences. Put data ownership and exit in writing every time, regardless of model.
Evaluate
Score against the published rubric, not against the demo. Weight data ownership/exit and compliance as gates: a tool that fails either is out, however good the dashboards look. Run the scale numbers through each vendor’s pricing model and evaluate cost at projected volume, not at pilot volume.
Map the capability to a tool category
Commercial APM / observability SaaS
Full-stack platforms that cover logs, metrics, traces, and alerting in one product (for example Datadog, New Relic, Splunk — named as examples, not endorsements). Fastest path to coverage and the least to operate. Procurement angle: a subscription service where per-GB/per-host pricing and the StateRAMP/FedRAMP authorization [VERIFY] are the deciding terms — do not assume pricing, require it in writing at your projected scale.
Open-source stack
A composed stack — Prometheus for metrics, Grafana for dashboards, Loki for logs, Tempo for traces, OpenTelemetry for instrumentation. No license cost and full data control; you pay in operations. Procurement angle: you’re buying implementation and managed-operations services and compute, not software, so the SOW centers on staffing, SLAs, and runbook handoff rather than license terms.
Cloud-native provider tooling
The observability suite from your existing cloud provider. Lowest integration effort and usually inherits the provider’s authorization [VERIFY]. Procurement angle: typically an add-on to the existing cloud-services vehicle, so the work is amending scope rather than running a new procurement — but the exit clause carries the portability risk and must be explicit.
Reference implementation
Fork this SOW skeleton. Every bracketed item is a decision you must make or a value a human must verify; do not ship it with placeholders intact.
# STATEMENT OF WORK — OBSERVABILITY TOOLING
### 1. Scope
The Contractor shall provide [SaaS subscription | implementation and managed operations | cloud-native add-on] for an observability platform covering logs, metrics, distributed traces, and alerting for [AGENCY / SYSTEM]. Estimated scale: [N hosts/containers], [N GB/day log volume], [N metric series]. Term: [base period + option years].
### 2. Required Signals
The platform shall ingest, store, query, and alert on:
- **Logs** — structured, centralized, searchable across all in-scope services.- **Metrics** — system and application, at [resolution], with [retention].- **Traces** — distributed, sampled at [rate], correlated to logs and metrics.- **Alerts** — threshold and anomaly, routed to [channel], with on-call paging.
### 3. Retention
- **Logs:** [N days hot / N days cold].- **Metrics:** [N days at full resolution / N days downsampled].- **Traces:** [N days].- Retention shall be configurable per signal without re-contracting.
### 4. Service Levels
- **Platform availability:** [e.g. 99.9%] measured monthly.- **Data ingestion latency:** [target] from emit to queryable.- **Support response:** [severity tiers and response times].
### 5. Data Ownership and Exit
All telemetry data is the property of [AGENCY]. On termination the Contractor shall, within [N days], export all data in [open format] at no additional charge and certify deletion of agency data from its systems. No proprietary format shall prevent export of raw data.
### 6. Security and Compliance
The service shall hold [StateRAMP | FedRAMP authorization at IMPACT LEVEL] for the term. Logs containing PII shall be redacted or tokenized per [AGENCY] data-handling policy; the Contractor shall describe its redaction and access-control controls.
### 7. Support and Onboarding
The Contractor shall provide implementation, instrumentation guidance, dashboard and alert configuration, and knowledge transfer sufficient for [AGENCY] staff to operate the platform unaided by end of [period].
### 8. Pricing
Pricing shall be stated at the estimated scale in Section 1 AND at [+50% | +100%] of that scale, so cost growth is visible before award. [FILL IN: ceiling / NTE amount per agency budget authority.]Score every responsive bid against this rubric. Treat the two gate rows as pass/fail: a failure on either eliminates the bid regardless of total score.
| Criterion | Weight | Notes |
|---|---|---|
| Compliance authorization (gate) | Pass/fail | StateRAMP/FedRAMP at required level [VERIFY] |
| Data ownership and exit (gate) | Pass/fail | Open-format export, no lock-in |
| Cost at projected scale | 30% | Scored at +50%/+100% scale, not pilot |
| Signal coverage | 20% | Logs, metrics, traces, alerting completeness |
| Operational burden | 15% | Staff effort to run and maintain |
| Integration fit | 15% | Works with current stack/cloud |
| Support and onboarding | 10% | Response SLAs, knowledge transfer |
| Scalability headroom | 10% | Performance and pricing at growth |
Common pitfalls
- You bought the tool before defining the requirement. If the demo happened before the retention and scale numbers existed, you bought features, not fit. Go back to “Define the requirement,” then re-evaluate against the rubric.
- The bill exploded at scale. Per-host and per-GB pricing looks cheap in a pilot and ruinous in production. Require pricing at +50%/+100% of projected scale before award, as in SOW Section 8.
- No data-exit clause, so you’re locked in. If the contract has no open-format export and deletion-on-termination clause, the vendor owns your leverage at renewal. SOW Section 5 is non-negotiable; make it a rubric gate.
- Compliance authorization was an afterthought. Discovering at award that the vendor lacks the required StateRAMP/FedRAMP authorization [VERIFY] restarts the procurement. Make it a pass/fail gate in evaluation, not a scored line item.
- Logs carry PII with no retention or redaction plan. Centralized logs concentrate sensitive data, and long retention turns a leak into a large one. Require redaction/tokenization and per-signal retention in SOW Sections 3 and 6 before any data flows.
Procurement notes
Candidate Maryland vehicles depend on the hosting model and dollar value, and must be confirmed with your procurement officer.
- SaaS subscription: [FILL IN: Maryland contract vehicle — e.g. COMMBUYS master contract # / NASPO ValuePoint cloud vehicle].
- Self-hosted implementation services: [FILL IN: Maryland IT master services vehicle #].
- Cloud-native add-on: amend the existing cloud-services contract [FILL IN: vehicle / order #].
Thresholds decide the path. Below the small-purchase threshold [VERIFY] you may avoid a full solicitation; above it you run an RFP against this runbook’s SOW and rubric [VERIFY]. A typical timeline runs roughly [VERIFY: e.g. 4–8 weeks for a small purchase, 3–6 months for a competitive RFP] — confirm against current Maryland procurement guidance before you commit a date to anyone.
For SOW drafting mechanics beyond this skeleton, see [How to write a good SOW]([FILL IN: link to SOW meta runbook]).
Maintenance
Owner: [FILL IN: runbook owner] · Last reviewed: 2026-05-31 · Next review: 2026-08-31