-
Eric D. Schabell authored
Signed-off-by:
Eric D. Schabell <eric@schabell.org>
Eric D. Schabell authoredSigned-off-by:
Eric D. Schabell <eric@schabell.org>
Next Generation Observability Architecture
This architecture covers the use case around a complete next generation observability architecture, one that encompasses all the functionality and solutions that are needed across a modern organization. It’s tackling the challenges that cloud native observability at scale presents with all elements present to provide organizations with control over both the ever-increasing amounts of telemetry data and their associated cloud native costs.
Use case: The next generation observability architecture for organizations tackling the challenges of telemetry data and their associated cloud native costs.
The first architecture is generic, now look at a solution for the observability platform:
The technology
The following descriptions are for the technology that was chosen for this solution:
-
Chronosphere Observability Platform - the only observability platform that controls for the speed, scale, and complexity that comes with the technology and organizational changes associated with a cloud native and DevOps world. Chronosphere helps engineers detect and resolve infrastructure and application issues before they affect customer experiences and the bottom line. Chronosphere helps teams increase customer satisfaction, and gain competitive advantage - all while controlling costs.
-
Workloads - collection of telemetry generating applications, services, infrastructure, and other cloud native environments.
-
Telemetry collection - various ways that telemetry data can be collected before sending it onwards to the observability platform. There are several possibilities for this; Chronosphere collection tooling, open source projects from the Cloud Native Computing Foundation (CNCF), and third-party APIs. Chronosphere provides two options with the Chronosphere Telemetry Pipeline and the Chronosphere Collector that ingest telemetry for forwarding to the observability platform. The CNCF projects shown are Prometheus for metrics collection, OpenTelemetry Collector for traces, and Fluent Bit for logging. Finally, there are possible third-party APIs that could provide telemetry data ingestion.
-
Telemetry types - types of telemetry data to be ingested into the observability platform; metrics, traces, events, and logs.
-
Telemetry storage - long term telemetry data storage and Security Information and Event Management (SIEM) destination solutions.
-
Extra add-ons - optional elements that can be added to the next generation observability architecture and are all represented with shaded blue. They include Configuration Management, a Container Management Platform, infrastructure Automation, Auto Instrumentation, Profiling, Digital Experience Management (DEM) which contains Real User Monitoring (RUM) and Synthetics, Cost Management, and Incident Management.
Automation
TODO: description example scenario…
TODO: The first diagram is of a network based architecture, the second focuses on the data flow, the third includes the deployment of the Collector either as a DaemonSet in OpenShift or as a sidecar solution.
Config management
TODO: description example scenario…
TODO: The first diagram is of a network based architecture, the second focuses on the data flow, the third includes the deployment of the Collector either as a DaemonSet in OpenShift or as a sidecar solution.
Container management platform
TODO: description example scenario…
TODO: The first diagram is of a network based architecture, the second focuses on the data flow, the third includes the deployment of the Collector either as a DaemonSet in OpenShift or as a sidecar solution.
Cost management
TODO: description example scenario…
TODO: The first diagram is of a network based architecture, the second focuses on the data flow, the third includes the deployment of the Collector either as a DaemonSet in OpenShift or as a sidecar solution.
Digital experience monitoring (DEM)
TODO: description example scenario…
TODO: The first diagram is of a network based architecture, the second focuses on the data flow, the third includes the deployment of the Collector either as a DaemonSet in OpenShift or as a sidecar solution.
Incident response
TODO: description example scenario…
TODO: The first diagram is of a network based architecture, the second focuses on the data flow, the third includes the deployment of the Collector either as a DaemonSet in OpenShift or as a sidecar solution.
Profiling
TODO: description example scenario…
TODO: The first diagram is of a network based architecture, the second focuses on the data flow, the third includes the deployment of the Collector either as a DaemonSet in OpenShift or as a sidecar solution.
Real user monitoring (RUM)
TODO: description example scenario…
TODO: The first diagram is of a network based architecture, the second focuses on the data flow, the third includes the deployment of the Collector either as a DaemonSet in OpenShift or as a sidecar solution.
Synthetics
TODO: description example scenario…
TODO: The first diagram is of a network based architecture, the second focuses on the data flow, the third includes the deployment of the Collector either as a DaemonSet in OpenShift or as a sidecar solution.