Skip to content
Snippets Groups Projects
Select Git revision
  • main default protected
1 result

next-gen-o11y.adoc

next-gen-o11y.adoc 10.44 KiB

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.

750

The first architecture is generic, now look at a solution for the observability platform:

750

The technology

750

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.

Auto instrumentation

750

750

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.

Download diagrams

View and download all the diagrams above in our open source tooling site.