Like Prometheus, but for logs.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 
loki/vendor/cel.dev/expr
renovate[bot] 275c97cec7
fix(deps): update module github.com/fsouza/fake-gcs-server to v1.50.2 (#14313)
7 months ago
..
.bazelversion feat: upgrade prometheus (#13671) 10 months ago
.gitattributes feat: upgrade prometheus (#13671) 10 months ago
.gitignore feat: upgrade prometheus (#13671) 10 months ago
BUILD.bazel fix(deps): update module github.com/fsouza/fake-gcs-server to v1.50.2 (#14313) 7 months ago
CODE_OF_CONDUCT.md feat: upgrade prometheus (#13671) 10 months ago
CONTRIBUTING.md feat: upgrade prometheus (#13671) 10 months ago
GOVERNANCE.md feat: upgrade prometheus (#13671) 10 months ago
LICENSE feat: upgrade prometheus (#13671) 10 months ago
MAINTAINERS.md feat: upgrade prometheus (#13671) 10 months ago
README.md feat: upgrade prometheus (#13671) 10 months ago
WORKSPACE feat: upgrade prometheus (#13671) 10 months ago
checked.pb.go feat: upgrade prometheus (#13671) 10 months ago
cloudbuild.yaml feat: upgrade prometheus (#13671) 10 months ago
eval.pb.go feat: upgrade prometheus (#13671) 10 months ago
explain.pb.go feat: upgrade prometheus (#13671) 10 months ago
regen_go_proto.sh feat: upgrade prometheus (#13671) 10 months ago
regen_go_proto_canonical_protos.sh feat: upgrade prometheus (#13671) 10 months ago
syntax.pb.go feat: upgrade prometheus (#13671) 10 months ago
value.pb.go feat: upgrade prometheus (#13671) 10 months ago

README.md

Common Expression Language

The Common Expression Language (CEL) implements common semantics for expression evaluation, enabling different applications to more easily interoperate.

Key Applications

  • Security policy: organizations have complex infrastructure and need common tooling to reason about the system as a whole
  • Protocols: expressions are a useful data type and require interoperability across programming languages and platforms.

Guiding philosophy:

  1. Keep it small & fast.
    • CEL evaluates in linear time, is mutation free, and not Turing-complete. This limitation is a feature of the language design, which allows the implementation to evaluate orders of magnitude faster than equivalently sandboxed JavaScript.
  2. Make it extensible.
    • CEL is designed to be embedded in applications, and allows for extensibility via its context which allows for functions and data to be provided by the software that embeds it.
  3. Developer-friendly.
    • The language is approachable to developers. The initial spec was based on the experience of developing Firebase Rules and usability testing many prior iterations.
    • The library itself and accompanying toolings should be easy to adopt by teams that seek to integrate CEL into their platforms.

The required components of a system that supports CEL are:

  • The textual representation of an expression as written by a developer. It is of similar syntax to expressions in C/C++/Java/JavaScript
  • A binary representation of an expression. It is an abstract syntax tree (AST).
  • A compiler library that converts the textual representation to the binary representation. This can be done ahead of time (in the control plane) or just before evaluation (in the data plane).
  • A context containing one or more typed variables, often protobuf messages. Most use-cases will use attribute_context.proto
  • An evaluator library that takes the binary format in the context and produces a result, usually a Boolean.

Example of boolean conditions and object construction:

// Condition
account.balance >= transaction.withdrawal
    || (account.overdraftProtection
    && account.overdraftLimit >= transaction.withdrawal  - account.balance)

// Object construction
common.GeoPoint{ latitude: 10.0, longitude: -5.5 }

For more detail, see:

Released under the Apache License.

Disclaimer: This is not an official Google product.