Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.chronosphere.io/llms.txt

Use this file to discover all available pages before exploring further.

Observability platforms exist to answer a deceptively straightforward question: Is the system working as intended? Answering this question requires many steps. Someone has to collect the telemetry data, organize it, make it searchable, watch for problems, respond when they occur, and dig deep enough to prevent them from recurring. Different people complete different parts of that work, which requires different tools and workflows. Within Chronosphere are several personas that map to different parts of the observability journey. Chronosphere personas divide into two groups based on the tasks each persona is primarily concerned with:
  • Developer personas are focused on understanding data that affects their organization’s end users.
  • Administrator personas are focused on data about the observability system itself, such as its health, cost, and access controls.

​
Understanding personas

Chronosphere product personas aren’t built around job titles. Titles and responsibilities can vary wildly between, and even within, each organization. In some cases, many key roles in observability have no established title at all. Therefore, these product personas are oriented around jobs to be completed. The core tenet of these personas is that a single user typically occupies many of these personas at different times, sometimes within a single workflow. A single engineer might occupy different personas throughout their day, or even within a single incident. For example, the Watcher notices a spike and becomes the Responder. If the Responder can’t find the root cause, they become the Investigator. After the incident, the same person might become the Maker to improve the alerting that let the problem occur. This fluidity is why these personas are defined by motivation and task, and not by job title. An observability system moves data through four broad stages:
  1. Ingest: Telemetry (metrics, traces, and logs) is collected from services and infrastructure and sent to the platform.
  2. Observe: Data is organized into dashboards, service views, and SLOs so teams can monitor system health.
  3. Investigate: When something goes wrong, data is queried and correlated to identify the scope and root cause of the problem.
  4. Control: Data volume, cost, and quality are managed to keep the system sustainable and the signal high.
Each persona operates primarily within one or two of these stages, driven by a specific motivation and stance: either proactive (acting before a problem surfaces) or reactive (responding after one does).