[approval] TAG Observability WG: Observability Query Language Standards

[halcyondude]

Hello!

TAG Observability's community members have come together to produce a proposal for a Working Group. With the co-chairs' support we would like to inform of the proposal and request the TOC's approval to formalize and launch the working group.

What's below is an excerpt from the WG's Charter document, and has gone thru several rounds of community input and review. Chris Larsen (Netflix) and Vijay Samuel (EBay) have driven the proposal and will be co-chairing the proposed WG.

Thanks,

Matt Young
Alolita Sharma

---

Problem Statement

A variety of domain specific languages (DSL) exist for observability data systems with little consistency or interoperability between them. Observability is a foundational aspect of the development experience and there is a wealth of telemetry ingestion, storage and processing systems available. Switching to another vendor or tool remains a challenge as users must often write bespoke tools to migrate data and queries. In order to do so, users must spend time learning the intricacies of a different observability system with non-obvious differences from the previous system.

The OpenTelemetry (OTel) initiative makes it possible to interoperate across Open Source projects/vendors from a client compatibility and an ingestion perspective. With OTel as an inspiration, there is still work necessary to standardize how data is queried out and standardize the schema/nomenclature used to represent the data as well.

Working Group Goals

This working group will conduct research and analysis into various observability query languages and deliver a set of recommendations ready for a follow-up group or open source project to turn into an ad-hoc standard with a reference implementation. Research and analysis will incorporate information such as:

1. Common, uncommon and desired use cases across observability data
2. Input and output data models for query languages
3. Language design goals, caveats and examples mapped to use cases
4. Semantic details for language operations
5. Adoption, tooling and infrastructure around the DSLs
6. Survey end user sentiment regarding existing DSLs

Evaluation deliverables will be a set of documents including end-user surveys, interview notes, use cases, examples and semantic descriptions of query languages.

The standard query recommendation deliverables will include information on:

1. A document stating the design goals of a standard language along with benefits and trade-offs
2. Base data model definitions of observability data types to incorporate Semantic definitions of operations on observability data
3. A schema for query results of the various types
4. Recommended APIs for querying observability data
5. A recommended query syntax

Creating an ad-hoc standard and reference implementation using the recommendations as a spec is out of scope for this proposed working group under the Observability TAG charter. A follow up group will be responsible for finalizing the standard and potentially creating implementations after the work of this group is complete.

[AloisReitbauer]

I overall like the initiative. I also have some comments/questions:

• Do you have people on the team who have designed these query languages. From our own experience, this is a very special skill set and we should have people working on this with proper experience.
• Why would we need a recommended API if the goal is to have a query language?
• What is the planned involvement of vendors/projects. There are already quite some query languages and APIs out there and most of this work has already been done by individuals.
• If the outcome is recommended syntax, this means this is a first step of a standard.
• What would a reference implementation look like? This would need to be done by individual projects. Also, other standard bodies like W3C require at least three independent implementation for something to become a standard.

[manolama]

Thanks @AloisReitbauer, we'll wait a few more days for comments and post on Wednesday the 12th of April.

[manolama]

• Yes, we plan to work with many query language creators to capture their knowledge in the database. Before publishing final recommendations, we intend to review multiple iterations of the draft for comment.
• The API is a recommendation for interoperability. Having semantic and syntactic recommendations for a QL helps but recommending APIs and models for output will help to make the QL truly portable between systems without having to rewrite a ton of tooling. Plus, there are aspects that may not make it into the QL grammar that need accounting for, e.g. start/stop time ranges, step intervals, etc.
• We plan to collaborate with creators of existing implementations to gather feedback and publish on the repo. As you said, some of this work has already been completed in silos across the industry so we think its worth trying to gather all of that knowledge and work in one place. Then, similar to the OTel work on ingress, we can provide an standard for the query and egress of observability data in the ecosystem, similar to SQL and JDBC/ODBC, etc. End users should be able to achieve end-to-end interoperability on their observability stack. Open telemetry helps us achieve this from an ingest perspective. There is a known gap on the query side which is worth standardizing. Another benefit is having a database of use cases and examples showing how various projects/products work. End users could benefit from such a repository of examples when trying to understand the subtleties of various implementations.
• Its a step for implementation teams (could be an OSS project) to take and run with. After analyzing the use cases and semantic conventions, a recommended syntax may be the clear winner to satisfy the criteria.
• Yes, the reference implementation would be handled by a follow up working group. This group is primarily focused on open research and analysis. I.e. on the due diligence needed before trying to create a standard.

[TheFoxAtWork]

@erinaboyd @cathyhongzhang @rochaporto as TOC liaisons please review and provide your decision.

[cathyhongzhang]

I support the goal and deliverables of this WG. I would like you to ensure that your investigation covers all existing query languages without creating another similar wheel.

[TheFoxAtWork]

@halcyondude would you link to the TAG Observability issue where the working group can collect interested parties and invite them to the group once the other liaisons have approved this? We've begun fielding requests for how to participate and i would love to redirect them to an issue to express interest in the interim as a placeholder until something more formal is established.

ATTN: @leonardpahlke would recommend adding this into the implementation of Section 3 of #1043 so that when a WG is being proposed, the TAG has a corresponding linked issued to direct interested contributors and begin scoping the work, timelines, etc. Reference TAG Security proposal Template structure as a guideline for how those issues could look:
https://github.com/cncf/tag-security/blob/main/.github/ISSUE_TEMPLATE/proposal.md

[alolita]

Hi @TheFoxAtWork thank you for guidance on this wg approval process. I will link the issue where the working group can start the process of inviting interested parties to participate once we have approvals from the other TOC liaisons.

[erinaboyd]

I approve of the creation of this wg!

[rochaporto]

Also approve the creation of this WG.

There might be a need to clarify the expected outcome of step 6) and how far into a standard recommendation this group is aiming for. The FAQ clearly mentions it's a non-goal to define a standard, that could be made more clear in 6) as well.

[alolita]

Thanks for your approval TOC liaisons! Will circle back on this thread with the link to issue inviting participants to join the new workgroup.

[dungdm93]

OTQL = OpenTelemetry Query Language 🚀🚀🚀

[manolama]

Thank you everyone! Our meeting schedule is at https://github.com/cncf/tag-observability/blob/main/working-groups/query-standardization.md and we'll get that added to the community calendar.

[TheFoxAtWork]

Closing this issue as resolved.