ServiceControl is the monitoring component of the Particular Service Platform: it ingests audit and error messages, tracks endpoint heartbeats, and exposes results over an HTTP API consumed by ServicePulse. For local run and debug steps see the README.md, for test categories and setup see testing.md, and for coding conventions see coding-and-design-guidelines.md.
src/— ServiceControl, ServiceControl.Audit, ServiceControl.Monitoring instances, persisters, and their test projectsdocs/— design rationale, testing guidance, and architecture decision recordsdeploy/— PowerShell installation and management modules for ServiceControl instancestools/— build and CI helper scripts.github/workflows/— CI pipelines for build, test, container publishing, and dependency maintenance
- ServiceControl documentation — public documentation entry point
- README.md — how to run and debug ServiceControl, ServiceControl.Audit, and ServiceControl.Monitoring locally
- Testing overview — index of test kinds, local setup for each, and the scenario checklists to rerun after a change
- Coding and design guidelines — conventions for new code
- Deployment and Packaging — how instances are packaged and deployed
This section points to sources that explain why ServiceControl is designed the way it is. Each entry says which question it answers. How-to material such as testing setup stays in the pages linked under Start here.
- Ingestion pipeline — why batch parallelism is a storage decision, not an instance decision
- Error ingestion design — relational-persister error ingestion design
- Bulk retries design — how ServiceControl retries failed messages in bulk
- Retries over Azure Storage Queues transport — transport-specific retry handling
- Data versioning design — the cache-versioning invariant for API responses
- Event log design — what the event log is and what it records
- Multiple ServiceControl instances communication — how primary, audit, and monitoring instances talk to each other
- Handling unavailable runtime dependencies — how instances react when a dependency is unavailable
- Telemetry — telemetry configuration and emitted metrics
- Throughput collection — why and how usage data is collected
A pull request is listed here only when it is the canonical record for a decision area: it establishes a durable constraint or convention, or rejects an alternative likely to return, and no docs/ file or ADR covers it. Bug fixes and routine changes are not listed; recover them from git log and gh pr view.
- Pagination limits belong to the API layer, not the persister — #5899
- Timestamps in the error instance come from an injected
TimeProvider, notDateTime.UtcNow— #5843 - HTTPS certificates load during settings validation so an unusable certificate fails fast, and an ingestion-only worker serves its own certificate — #5891, #5923
- Endpoint throughput recording uses an atomic upsert because duplicate keys are routine, not exceptional — #5895
- Failed audit imports use deterministic ids derived from the message id so repeated failures do not duplicate — #5919
- SQL Server and PostgreSQL primaries can be upgraded, but the upgrade path does not create them — #5921
- New RavenDB databases use the Lucene search engine, and indexes still on Corax are flagged — #5833
Keep this index current when a canonical source is added, replaced, or retired; link, do not copy.