Chapter 5: Evolutionary observability
The introduction shows how observability data can help an organization understand performance and value, while illustrating the costs of relying on ad hoc spreadsheets to use that data.
After this chapter you will be able to
- Observability beyond troubleshooting. Explain how telemetry helps Epetech beyond diagnosing problems: it gives the business visibility into platform value and lets leaders examine performance across applications and services to spot trends.
- Spreadsheet-driven observability friction. Trace how leaders’ spreadsheet-based queries create shadow IT and why changes to data structures turn those spreadsheets into a recurring burden for developers.
- Insight and rapid response. Explain how observability turns output data into insight about a system and helps teams detect, diagnose, and address problems quickly.
- Evolutionary feedback loop. Explain why the section treats observability as an evolving feedback loop rather than only an after-the-fact dashboard.
- Complementary telemetry in diagnosis. Explain why metrics, logs, and traces are more useful together than default metrics and alerts alone, using the checkout failure to show how an investigation moves between them.
- Cross-system request traces. Explain what a trace follows and how a correlation ID helps investigate a request that crosses processes or applications.
- Limits of application monitoring. Explain why monitoring application performance alone did not give Epetech the customer experience it wanted. Describe how gaps elsewhere in delivery and business operations remained invisible or were reported too late to act on.
- Eight observability lenses. Describe the eight areas of observability named in the section and explain, using examples, how their data supports different engineering and business stakeholders.
- Context for healthy operation. Explain why a metric alone cannot show whether a system is running well, using the section’s contrasting CPU-usage examples.
- Known-known failure signals. Describe how to observe a failure mode whose cause and expected good state are already understood.
- Tracing partly unknown failures. Explain why telemetry that follows processes across systems helps diagnose failures whose precise form was not anticipated.
- Investigating unforeseen failures. Describe the challenge of unknown-unknowns and the analysis approaches the section identifies for finding them.
- Single pane of glass value. Explain why a single pane of glass helps people use observability data across systems and roles. Distinguish a unified place to query and visualize data from a requirement to store everything in one database.
- Data collection and ingestion. Trace how metrics, logs, and traces reach the observability system and what the ingestion APIs do. Describe the alternative for protected sources that cannot send data directly.
- Specialized stores and dashboards. Describe where metrics, logs, and traces are stored and how users explore them through the unified dashboard.
- Effective observability platform qualities. Explain why observability can be treated as a complete platform and describe the qualities the section identifies in the best observability platforms.
- Frictionless authorized access. Explain how the observability platform should use the platform’s existing identity and authorization architecture so users can sign in with familiar credentials and receive the right permissions automatically.
- Platform-wide telemetry visibility. Explain why metrics, logs, traces, and other telemetry should be available across the platform rather than isolated by team, particularly when diagnosing distributed incidents.
- Code-managed customizable views. Describe how dashboards, alerts, and querying should fit into platform configuration and how users should be able to tailor observability to their needs.
- Automatic telemetry collection paths. Describe how the platform collects metrics, logs, and traces through automatic scraping and application-published telemetry, then forwards the data to a centralized observability datastore.
- Low-friction observability integration. Explain why platform-managed collection reduces onboarding work for application teams and keeps applications insulated from changes to observability backends.
- Observability responsibility boundaries. Explain what development teams, the platform team, and vendors each provide in Epetech’s shared responsibility model, and why clear boundaries reduce friction.
- Limits of team-owned observability. Explain why separate teams’ observability tools can work in a small organization but become inadequate as systems and teams grow.
- Broader observability product opportunity. Explain why the section proposes extending platform-style, self-serve product thinking from engineering needs to observability for the wider organization.
- Telemetry collection and ingestion flow. Trace how metrics, logs, and traces move from external sources through the collection agent and ingestion service toward storage.
- Message bus buffering role. Explain why the architecture places a message bus between collection and ingestion, particularly during peaks or downstream outages.
- Telemetry-specific storage routing. Describe how processed metrics, logs, and traces are routed to different storage solutions and why persistence matters for metrics.
- Grafana visualization and alerting. Explain how Grafana brings the stored telemetry together for dashboards, alerts, and analysis.
- Build-or-buy trade-offs. Explain how SaaS and in-house observability options differ in time to value, costs, and control, including the labor and opportunity costs of operating tooling.
- Evidence-led evolutionary decisions. Describe how to keep build-or-buy options open, test them with real systems, and question requirements that assume one option is mandatory.
- Per-cluster observability limitations. Explain why relying on observability deployed separately in each Kubernetes cluster becomes less effective as the platform scales.
- Independent external monitoring. Describe the section’s proposed separation of observability components and explain what an external monitoring service safeguards against.
- People-centered adoption strategies. Explain how education, visible successes, team support, and incentives can encourage people to adopt observability.
- Low-friction workflow integration. Describe how easy-to-use tools, automation, and development-workflow integration reduce the effort of adopting observability.
- Mandatory baseline and team choice. Distinguish the baseline observability expected of systems from tracing detail that teams may choose to add, including the limits of COTS software.
- Customer experience beyond uptime. Explain why uptime alone may not capture a platform customer’s experience, using the comparison between brief outages and slower responses.
- SLI SLO and SLA roles. Distinguish a service-level indicator, an objective based on that indicator, and a customer agreement about unmet expectations.
- Published goals and observability. Explain why a platform should publish customer-relevant service-level goals and track them visibly through its observability system.
- Software-defined SLO dashboards. Explain why the platform should create and share SLO dashboards with its customers, and describe how the dashboards and their backing code should appear in platform documentation.
- SLO dashboard interpretation. Describe the information shown in the example dashboard and how teams use it to assess objectives and diagnose problems.
What it builds on
- Observability-driven development (chapter 2) · Assumes familiarity with observability-driven development practices that produce telemetry.
- Evolutionary platform architecture (chapter 2) · The earlier concept of an evolving platform architecture.
- Developer experience (chapter 1) · The importance of developer experience to platform use.
Section by section
Introduction
The introduction shows how observability data can help an organization understand performance and value, while illustrating the costs of relying on ad hoc spreadsheets to use that data.
- Observability beyond troubleshooting: Explain how telemetry helps Epetech beyond diagnosing problems: it gives the business visibility into platform value and lets leaders examine performance across applications and services to spot trends.
Why it matters: It explains why people outside the platform team want to use observability data. - Spreadsheet-driven observability friction: Trace how leaders’ spreadsheet-based queries create shadow IT and why changes to data structures turn those spreadsheets into a recurring burden for developers.
Why it matters: It shows how access to useful data can still create delivery friction when everyone builds a separate way to consume it.
Key terms: observability-driven development, telemetry data, portfolio, shadow IT, spreadsheets, data structure
5.1 Why observability matters
The section defines observability as insight into a system’s state and usefulness, then shows how that insight supports faster responses, shared decisions, and platform improvement.
- Insight and rapid response: Explain how observability turns output data into insight about a system and helps teams detect, diagnose, and address problems quickly.
Why it matters: Insight from system data helps a team act before a problem has a greater effect on customers. - Shared and standardized data: Describe how accessible, shared observability data can serve development and business teams while reducing duplicated dashboards and confusion.
Why it matters: A shared view makes useful evidence available without repeated reporting work or competing versions of the same data. - Evolutionary feedback loop: Explain why the section treats observability as an evolving feedback loop rather than only an after-the-fact dashboard.
Why it matters: Treating observability as feedback lets teams use what they see to improve the platform, not just review what happened.
Key terms: observability, internal state, output data, insights, telemetry, shared data, observability dashboards, shadow IT, telemetry debt, evolution
5.1.1 Observability is more than metrics and alerts
The section explains how metrics, logs, and traces provide complementary evidence that can be connected to diagnose a system problem.
- Complementary telemetry in diagnosis: Explain why metrics, logs, and traces are more useful together than default metrics and alerts alone, using the checkout failure to show how an investigation moves between them.
Why it matters: Connecting the evidence helps you fix the actual cause rather than the first apparent symptom. - Metrics and alert signals: Describe what metrics record and what they contribute when a problem is first detected.
Why it matters: Metrics can flag a problem quickly without necessarily explaining its cause. - Detailed log events: Describe how logs help investigate a known event and why their individual details matter.
Why it matters: Detailed log entries provide clues that an aggregate measurement may hide. - Cross-system request traces: Explain what a trace follows and how a correlation ID helps investigate a request that crosses processes or applications.
Why it matters: Following a request across boundaries can reveal a cause outside the component where the symptom appeared.
Key terms: metrics, logs, traces, telemetry data, insights, alerts, CPU and memory usage, HTTP errors, disk capacity, discrete events
5.1.2 Use cases for observability beyond basic monitoring of applications
The section broadens observability beyond application monitoring by showing how eight kinds of data can inform engineering decisions, business decisions, and customer experience.
- Limits of application monitoring: Explain why monitoring application performance alone did not give Epetech the customer experience it wanted. Describe how gaps elsewhere in delivery and business operations remained invisible or were reported too late to act on.
Why it matters: It explains why a technically healthy application may still leave customers dissatisfied and decision-makers without useful information. - Eight observability lenses: Describe the eight areas of observability named in the section and explain, using examples, how their data supports different engineering and business stakeholders.
Why it matters: The lenses help teams choose data according to the decisions people need to make, rather than collecting only application metrics.
Key terms: application observability, end-user experience, customer experience, infrastructure, application, service health, incidents, portfolio, platform
5.1.3 What does good look like?
The section uses three categories of operating states to explain what observability data to collect and how to make more system behavior understandable over time.
- Context for healthy operation: Explain why a metric alone cannot show whether a system is running well, using the section’s contrasting CPU-usage examples.
Why it matters: Context lets you decide which measurements indicate a real problem rather than merely looking unusual. - Known-known failure signals: Describe how to observe a failure mode whose cause and expected good state are already understood.
Why it matters: Known failure modes can be detected directly and sometimes remedied quickly. - Tracing partly unknown failures: Explain why telemetry that follows processes across systems helps diagnose failures whose precise form was not anticipated.
Why it matters: Tracing helps investigate failures that could not be covered by an alert for every specific cause. - Investigating unforeseen failures: Describe the challenge of unknown-unknowns and the analysis approaches the section identifies for finding them.
Why it matters: Not every problem has a predefined alert or an obvious cause, so observability must also support discovery. - Evolving observable knowledge: Explain the section’s overarching aim of turning discoveries about system behavior into known-knowns.
Why it matters: Each investigation can improve what the team can recognize and address next time.
Key terms: healthy, meaningful load, operating states, known-knowns, telemetry, queries, alerts, self-healing, known-unknowns, instrumenting
5.1.4 Viewing observability through a single pane of glass
The section explains how a single pane of glass can bring together observability data from different sources and outlines an architecture for collecting, storing, and querying it.
- Single pane of glass value: Explain why a single pane of glass helps people use observability data across systems and roles. Distinguish a unified place to query and visualize data from a requirement to store everything in one database.
Why it matters: A unified experience can make data from many tools useful without forcing all the data into one store. - Data collection and ingestion: Trace how metrics, logs, and traces reach the observability system and what the ingestion APIs do. Describe the alternative for protected sources that cannot send data directly.
Why it matters: The collection path must accommodate both different data types and sources that cannot send data directly. - Specialized stores and dashboards: Describe where metrics, logs, and traces are stored and how users explore them through the unified dashboard.
Why it matters: A common viewing experience can sit over stores designed for different kinds of evidence. - Kubernetes observability exploration: Describe the exercise’s sequence for evaluating observability tools for Kubernetes and its applications, including what to record after trying a stack locally.
Why it matters: Trying a stack against stated goals exposes questions that a platform implementation would have to address.
Key terms: single pane of glass (SPOG), correlation, data sources, ingestion APIs, metrics, logs, traces, polling, time-series database, log management system
5.2 Observability as a platform service
This section presents observability as a platform service and identifies the qualities that make such a platform effective.
- Effective observability platform qualities: Explain why observability can be treated as a complete platform and describe the qualities the section identifies in the best observability platforms.
Why it matters: These qualities provide a starting point for thinking about observability as a service rather than just a collection of monitoring tools.
Key terms: observability platforms, integration capabilities, data aggregation, user-friendly experience, distributed systems
5.2.1 The end-user access experience
This section explains how an observability platform can give end users easy, unified, responsive access to telemetry and configurable observability tools.
- Frictionless authorized access: Explain how the observability platform should use the platform’s existing identity and authorization architecture so users can sign in with familiar credentials and receive the right permissions automatically.
Why it matters: Familiar sign-in and appropriate permissions make observability easier for developers to use. - Platform-wide telemetry visibility: Explain why metrics, logs, traces, and other telemetry should be available across the platform rather than isolated by team, particularly when diagnosing distributed incidents.
Why it matters: A cross-service view helps teams diagnose incidents that no single team’s data can explain. - Responsive observability at scale: Describe what users should still be able to expect from observability as the organization adds services and telemetry volume grows.
Why it matters: Observability remains useful during critical incidents only if users can get a timely, coherent view. - Code-managed customizable views: Describe how dashboards, alerts, and querying should fit into platform configuration and how users should be able to tailor observability to their needs.
Why it matters: Code-managed defaults and customization give users a useful starting point without forcing everyone into the same view.
Key terms: identity provider, single sign-on, role-based access control, platform-wide aggregation, metrics, logs, traces, holistic view, mean time to recover, unified and responsive experience
5.2.2 Automatic collection of customer data
This section explains how a platform automatically collects application telemetry and shields application teams from the collection infrastructure.
- Automatic telemetry collection paths: Describe how the platform collects metrics, logs, and traces through automatic scraping and application-published telemetry, then forwards the data to a centralized observability datastore.
Why it matters: These two collection paths let the platform gather telemetry without relying on a single way for applications to provide it. - Low-friction observability integration: Explain why platform-managed collection reduces onboarding work for application teams and keeps applications insulated from changes to observability backends.
Why it matters: Platform-managed collection makes observability easier to adopt and avoids coupling each application to a particular backend.
Key terms: telemetry, metrics, logs, traces, scrape service, platform endpoints, collection agent, onboarding, well-known endpoints, backend technologies
5.2.3 Who needs to respond when things need attention?
This section assigns observability responsibilities across development teams, the platform team, and vendors, then offers an exercise for checking application telemetry.
- Observability responsibility boundaries: Explain what development teams, the platform team, and vendors each provide in Epetech’s shared responsibility model, and why clear boundaries reduce friction.
Why it matters: Knowing who owns each layer helps teams respond without disputes over the tools or the service-specific signals. - Demo telemetry correlation exercise: Describe how the exercise connects a demo application to an observability stack and checks that its telemetry is visible.
Why it matters: Checking both normal traffic and an error shows whether the application’s signals actually reach the dashboard.
Key terms: shared responsibility model, development team’s responsibility, platform responsibility, vendor responsibility, demo application, observability stack, instrumentation, Metrics, Logs, and Traces, telemetry data
5.3 Observability platform as a separate internal product
The section traces how observability needs change as an organization grows and argues for treating observability as a self-serve internal product that serves more than developers.
- Limits of team-owned observability: Explain why separate teams’ observability tools can work in a small organization but become inadequate as systems and teams grow.
Why it matters: It explains why an approach that was practical at startup scale may not serve a growing organization. - Limits of centralized tooling: Describe what the growth-phase monitoring and DevOps initiatives improve, and why they do not fully resolve engineering friction.
Why it matters: Standard tools can improve operations without making observability easy for every team to adopt. - Broader observability product opportunity: Explain why the section proposes extending platform-style, self-serve product thinking from engineering needs to observability for the wider organization.
Why it matters: It frames observability as a useful internal product for data-dependent teams across the company, not just a set of developer monitoring tools.
Key terms: start phase, unified view, cross-service problems, dedicated monitoring team, Enterprise-style tooling, DevOps initiative, engineering friction, self-serve, preconfigured architecture patterns, product mindset
5.3.1 Architecture of an observability platform
This section traces a sample observability platform architecture from telemetry collection through buffering, processing, storage, and access.
- Telemetry collection and ingestion flow: Trace how metrics, logs, and traces move from external sources through the collection agent and ingestion service toward storage.
Why it matters: Separating collection from ingestion makes the data path easier to scale and adapt. - Message bus buffering role: Explain why the architecture places a message bus between collection and ingestion, particularly during peaks or downstream outages.
Why it matters: Buffering helps telemetry ingestion remain resilient when processing capacity fluctuates. - Telemetry-specific storage routing: Describe how processed metrics, logs, and traces are routed to different storage solutions and why persistence matters for metrics.
Why it matters: Different telemetry types need storage that supports their respective uses in monitoring and troubleshooting. - Grafana visualization and alerting: Explain how Grafana brings the stored telemetry together for dashboards, alerts, and analysis.
Why it matters: A unified interface makes separately stored telemetry usable for operational monitoring. - Configuration and query access: Distinguish Grafana’s configuration storage from the endpoint used to query stored telemetry.
Why it matters: Separating configuration from telemetry access clarifies what these supporting components do.
Key terms: external data collection agent, data ingestion service, metrics, logs, traces, message bus, buffering, fault tolerance, data storage service, Prometheus
5.3.2 Should you build or buy?
This section frames the observability build-or-buy decision as a trade-off in total cost, time, and control that should be tested with real systems rather than settled by assumption.
- Build-or-buy trade-offs: Explain how SaaS and in-house observability options differ in time to value, costs, and control, including the labor and opportunity costs of operating tooling.
Why it matters: A cheaper-looking option may cost more once operating effort and delayed value are included. - Interoperable technology choices: Justify favoring smaller, interoperable observability technologies that meet specific needs over a bloated all-in-one stack.
Why it matters: Choosing for interoperability helps keep the platform useful and adaptable as needs change. - Evidence-led evolutionary decisions: Describe how to keep build-or-buy options open, test them with real systems, and question requirements that assume one option is mandatory.
Why it matters: Testing assumptions before committing reduces the risk of an unnecessarily restrictive choice.
Key terms: time to value, opportunity costs, labor costs, SaaS observability platform, evolutionary architecture, software-defined delivery, domain design, interoperate, vendor lock-in, evolutionary architectural approach
5.3.3 Cross-platform observability
The section explains why observability for an engineering platform should extend beyond individual clusters and include an independent way to detect outages.
- Per-cluster observability limitations: Explain why relying on observability deployed separately in each Kubernetes cluster becomes less effective as the platform scales.
Why it matters: Monitoring that disappears with the cluster or fragments across clusters cannot give a reliable view of a growing platform. - Independent external monitoring: Describe the section’s proposed separation of observability components and explain what an external monitoring service safeguards against.
Why it matters: A separate safeguard can alert the team when the systems they normally use to observe the platform are themselves down.
Key terms: per-cluster solution, dashboards, monitoring, alerting, aggregate the observability data, developer control plane, dedicated infrastructure, external monitoring service, basic data collection, internal observability tools
5.3.4 Strategies to drive adoption
This section explains how to encourage adoption of an observability platform and presents a build-versus-buy exercise grounded in requirements, staffing, and capability gaps.
- People-centered adoption strategies: Explain how education, visible successes, team support, and incentives can encourage people to adopt observability.
Why it matters: A platform is useful only if teams are willing and able to use it. - Low-friction workflow integration: Describe how easy-to-use tools, automation, and development-workflow integration reduce the effort of adopting observability.
Why it matters: Making observability the easy, routine path helps teams adopt it consistently. - Mandatory baseline and team choice: Distinguish the baseline observability expected of systems from tracing detail that teams may choose to add, including the limits of COTS software.
Why it matters: A shared minimum need not force every service into the same depth of instrumentation. - Business trust and ongoing adaptation: Explain how business evidence, trustworthy data, feedback, and a shared culture sustain observability adoption.
Why it matters: Credible results secure support, while feedback keeps the platform useful as needs change. - Observability build-buy tradeoffs: Apply the exercise’s facts to identify what Epetech must establish before choosing between a custom platform and a SaaS product.
Why it matters: Neither option can be chosen responsibly without checking requirements against the full effort and capability gaps.
Key terms: education and awareness, quick wins, observability champions, incentivize adoption, automated metrics collection, log aggregation, prebuilt dashboards, CI/CD pipelines, definition of “done”, baseline level of observability
5.4 Observability of published service-level indicators, service-level objectives, and service-level agreements
The section explains how customer-relevant service measures, published objectives, and observable results help a platform set expectations and build trust.
- Customer experience beyond uptime: Explain why uptime alone may not capture a platform customer’s experience, using the comparison between brief outages and slower responses.
Why it matters: Measures should reflect the experience customers actually have, not just an impressive uptime number. - SLI SLO and SLA roles: Distinguish a service-level indicator, an objective based on that indicator, and a customer agreement about unmet expectations.
Why it matters: Keeping measurements, targets, and agreements distinct makes service promises clearer. - Published goals and observability: Explain why a platform should publish customer-relevant service-level goals and track them visibly through its observability system.
Why it matters: A published promise is more useful when the team can see whether the platform is keeping it.
Key terms: uptime, resilience, response time, service-level indicator (SLI), service-level objective (SLO), service-level agreement (SLA), published service-level goals, observability system, customer expectations
5.4.1 SLOs as code
This section shows how to publish software-defined SLO dashboards for a platform and invites readers to design an SLO using Prometheus data.
- Software-defined SLO dashboards: Explain why the platform should create and share SLO dashboards with its customers, and describe how the dashboards and their backing code should appear in platform documentation.
Why it matters: A published, reproducible dashboard makes the platform’s service objectives visible to its customers. - SLO dashboard interpretation: Describe the information shown in the example dashboard and how teams use it to assess objectives and diagnose problems.
Why it matters: The dashboard connects a service objective to its current status and the trends behind it. - Prometheus-based SLO exercise: Describe how the optional exercise asks readers to propose a platform SLO, choose an SLI, and plan to collect, visualize, and monitor the needed data in relation to developer satisfaction.
Why it matters: An SLO is more useful when its measurement and monitoring plan reflect what platform users care about.
Key terms: SLO dashboard, software-defined, platform user documentation, target SLO, error budget, burn rate charts, warning and critical alerts, SLO, SLI, Prometheus data
5.5 Summary
Where this is used later
- Embracing DevOps cultural principles (chapter 10) · Earlier explanation of why observability matters.
- Account baseline observability (chapter 7) · The exercise’s tool choices and implementation questions can inform the later account-baseline observability work.
- Scaling the orchestration of control plane services and extensions (chapter 9) · Observability as a platform service.
- Differentiating through user experience (chapter 10) · Connects platform adoption to the experience offered to users.
- Adapter pattern: Observability hooks (chapter 9) · Provides the adoption rationale for integrating observability into platform workflows.
- Implementing feedback loops (chapter 10) · Connects ongoing platform improvement to feedback loops.
- Understanding SRE (chapter 10) · Earlier discussion of service-level indicators and objectives.
- Aligning SRE with organizational goals (chapter 10) · Earlier coverage of service-level indicators and service-level objectives provides context for the measures reviewed here.
Concepts explained in this chapter
- observability systemAn observability platform is a shared system that provides organization-wide capabilities for collecting, integrating, and interpreting observability data and supporting operational decisions.
- dashboardA dashboard is a visual interface that presents selected metrics, statuses, and trends for monitoring a system or objective.
- trajectoryTracing is the recording and analysis of request paths and spans across components of a distributed system.
- observabilityObservability is the ability to determine and explain a software system’s internal state and usefulness from its output data.
- telemetryTelemetry data consists of automatically emitted records such as metrics, logs, and traces that describe software-system behavior, performance, and state.
- monitoringStructured logging is the practice of emitting log records in a machine-readable format with consistent fields and values.
- time-series databaseA time-series database is a database optimized for storing and retrieving timestamped measurements and other time-indexed data.
- instrumentationInstrumentation is the addition of code or integration components that emit telemetry from software during execution.
- observability dataObservability data is telemetry describing the internal behavior and external effects of a software system, including its logs, metrics, and traces.
- unknown unknownAn unknown unknown is a relevant condition, behavior, or failure mode whose possibility has not previously been recognized.
- service-level objectiveA service-level objective is a target value or range for a service-level indicator that defines an intended level of service performance or reliability.
- PrometheusPrometheus is an open-source monitoring system that collects and stores time-series metrics and supports querying and alerting.
- shared-responsibility modelA shared responsibility model divides security responsibilities between a platform provider and the users of the platform.
- known knownA known-known is a failure or operating condition whose possibility and specific behavior are already understood.
- known unknownA known unknown is a potentially relevant failure or operating condition whose existence is recognized but whose complete behavior is not understood.
- predictive analysis engineA predictive analysis engine is a software system that analyzes data to identify likely future conditions, failures, or weaknesses.
- application observabilityApplication observability is an observability practice narrowly focused on the behavior and performance of application software.
- customer satisfactionCustomer satisfaction is the degree to which customers judge a product or service to meet their expectations and needs.
- service healthService health is an indication of whether a service and its dependent resources are operating as expected.
- service-level indicatorA service-level indicator is a quantitative measurement of a service’s reliability or performance from the perspective of its users.
- ingestion apiAn ingestion API is a software interface that accepts, validates, formats, and routes data into an observability system.
- log management platformA log management system is software that collects, stores, aggregates, searches, and analyzes log records.
- pipelineA pipeline workflow is a defined arrangement of automation steps or jobs that executes as a coordinated process.
- single pane of glassA single pane of glass is a unified interface that presents and enables analysis of data from multiple systems or sources.
- domain teamA development team is a group responsible for building and operating one or more software applications or services.
- engineering platform teamA platform product team is a team responsible for developing and evolving an internal platform product.
- GrafanaGrafana is an open-source observability and visualization platform for querying, displaying, and alerting on data from multiple sources.
- performanceA success measure is a defined indicator used to determine whether an initiative has achieved its intended outcomes.
- resilienceResilience is the ability of a system to continue providing acceptable service or recover when experiencing faults, disruption, or degraded conditions.
- evolutionary architectureEvolutionary architecture is an architectural approach that preserves the ability to change through small, incremental, and rapid modifications.
- observability-driven developmentObservability-driven design is a software design approach that incorporates the data and instrumentation needed to understand system behavior.
- log aggregationA log aggregation system collects logs from multiple sources and makes them available for centralized storage and querying.
- self-healing mechanismSelf-healing is the capability of a system to detect deviations from its desired state and automatically restore correct operation.
- continuous improvementAn iterative development cycle is a repeated, bounded period in which a team plans, builds, evaluates, and improves a software increment.
- role-based access controlRole-based access control is an authorization method that grants permissions according to assigned roles.
- self-serviceSelf-service is a pattern in which users obtain resources or perform supported operations directly without depending on an intermediary for each request.
← Chapter 4: Governance, compliance, and trust
Chapter 6: Building a software-defined engineering platform →
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.