#5253
The overall goal of this PR is to migrate alerts data out of `meta`
table into `alerts` table. To accomplish this three main changes are
made. Unfortunately, all three of these changes need to be synchronized
and submitted in the same PR.
1. A new migration script is added to
- Parse alerts JSON currently stored in the `meta` table into Rust
models for alerts. These Rust models are isolated to the migration
script since they represent the schema of alerts as they are stored in
the `meta` table before this migration executes.
- Convert those Rust models into Sea ORM entities for alerts.
- Insert all the Sea ORM entities for alerts into the new `alerts`
table.
2. Create get/put/delete/list methods for accessing the data in the
`alerts` table
- These functions use SeaORM to query and update the database.
- These functions must also convert between SeaORM alert entities and
the application's current data model for alerts (as defined in
`config::meta::alerts`.
- It's entirely expected that the models inside `config::meta::alerts`
will change over time. When this happens in the future, developers will
need to update the transformation functions between SeaORM alert
entities and the models in `config::meta::alerts`. Luckily, the compiler
should help to direct developers to where these transformation functions
need to be updated.
3. Update the old logic in `/src/service/db/alerts.rs` that previously
read and wrote alerts to the `meta` table so that it now reads and
writes alerts to the `alerts` table.
- The methods for accessing the `meta` table included logic for
triggering "cache update events" to the cluster coordinator and for
sending events to the super cluster queue. Since the new logic accesses
the `alerts` table rather than the `meta` table, this logic for emitting
events had to be reproduced.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced a new `ListAlertsParams` struct for flexible querying of
alerts.
- Enhanced `TriggerCondition` struct with new timing parameters.
- Added new error variants for improved error handling in alert
management.
- Created a comprehensive alert management system with CRUD operations.
- Added integration tests for various functionalities related to alerts
and dashboards.
- Introduced a new `Alerts` variant in the `FolderType` enum for better
folder management.
- **Bug Fixes**
- Improved error handling for folder deletion when alerts are present.
- **Documentation**
- Updated documentation for several functions to clarify their scope and
functionality.
- **Chores**
- Added new dependencies to support additional functionality.
- Introduced migration scripts for database schema changes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
The previous mechanism for generating hashes for dashboard models
depended on hashing the JSON representation of the dashboard that was
stored in the `meta` table.
As part of the migration of dashboards out of the `meta` table and into
a dedicated `dashboards` table, this ☝️ presented some problems:
Specifically when we want to translate from the Dashboard ORM model to a
`core::meta::dashboards::Dashboard` model, we need to generate the hash
at the time of translation since `hash` is a field on
`core::meta::dashboards::Dashboard`. We can't simply generate a hash
from the JSON stored in the `dashboards.data` column because this JSON
no longer contains fields for `title`, `owner`, `description`, and
`role`. Those fields are now stored in DB columns, and changes to those
columns in the DB columns would *not* result in changes to the hash on
the JSON blob.
Therefore, rather than hashing the JSON blob, this PR implements hash
functions on the Rust types for the dashboards. Therefore changes to
fields in those Rust structs will result in changes to the hash values,
but changes to the way in which the data is stored in the DB will not
affect the hash values.
⚠️ Note that this PR is changing the hash function on the dashboard
models, so hashes generated for the same model before and after this
deployment will not be the same. My understanding is that this shouldn't
be an issue since hashes are just used as a way of checking on the UI if
the dashboard model has been updated to avoid overwriting the changes of
another user. I believe that this change to the dashboard function might
just have the effect (around the time of deployment) where it would
appear to the UI that the dashboard has been updated when, in fact, it
has not.
https://github.com/openobserve/o2-enterprise/actions/runs/11979723563
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced a new type alias `OrdF64` for enhanced precision in
floating-point operations.
- Added the `Hash` trait to multiple dashboard-related structs and
enums, enabling their use in hash-based collections.
- **Bug Fixes**
- Improved error handling and assertion clarity in API testing for
folder and dashboard operations.
- **Chores**
- Standardized hashing mechanism for dashboard objects in database
operations.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
This is the first PR for #5068 .
We need to move `dashboards` into the `config` crate so that DB access
functions in the `infra` crate can return types defined in the
`dashboards` module.
When the `dashboards` module is in the `openobserve` crate we cannot use
them in the `infra` crate since that would introduce a circular
dependency.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
- **New Features**
- Introduced a new function to move dashboards, enhancing dashboard
management capabilities.
- Added a new `SendReport` trait for improved report handling and
modularity.
- Enhanced error handling across various dashboard and report management
functions.
- **Improvements**
- Updated import paths for better clarity and organization, particularly
for dashboard-related modules.
- Improved timestamp handling for alerts to ensure accurate tracking of
updates.
- Enhanced OpenAPI documentation to reflect updated schema references
for dashboards.
- Expanded development dependencies to support improved functionality.
- Enhanced the logic for handling report triggers based on frequency
types.
- **Bug Fixes**
- Refined error handling in dashboard creation and deletion functions to
provide clearer responses.
- Standardized error handling across report management functions for
consistency.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Taiming Liu <liutaiming3@gmail.com>
#5069
**Description**
- Introduces migrations to
1. Create a new `folder` table
2. Transform folder records from `meta` table into `folder` table
3. Delete folder records from `meta` table
- Updates folder and dashboard service logic to use the new `folder`
table rather than the `meta` table
**Prior steps**
Before this PR is merged, two others must be merged first
1. https://github.com/openobserve/openobserve/pull/5095
2. https://github.com/openobserve/openobserve/pull/5096
After these other PRs are merged this PR will be updated to merge into
`main` rather than into `ps/5069/move-folder-2`.
**Next steps**
Feature #5069 will be complete with this PR.
This will open us up to starting on feature #5068.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced new folder management functionalities, including creating,
updating, listing, and deleting folders.
- Added support for error handling improvements in dashboard and folder
operations.
- Implemented a new README for SeaORM entities detailing usage and
generation instructions.
- **Bug Fixes**
- Enhanced error handling in various functions to ensure appropriate
responses based on success or failure.
- **Documentation**
- Added documentation for SeaORM entities and their generation process.
- **Refactor**
- Streamlined folder and dashboard management functions for better
clarity and maintainability.
- Updated API structure for folder-related endpoints to improve clarity
and response handling.
- Improved error handling strategy across multiple service functions.
- Enhanced database interaction methods for folders and dashboards,
promoting modularity and consistency.
- Modified initialization workflow to ensure database schema updates on
application start.
- Simplified error handling in folder management service functions.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
This PR creates a general `self_reporting` module to be used internally
for both Usage and Error reporting
- channel-based queues to receive ReportingData (Usage or Error) and
ingest buffed data in batch determined by either `batch_size` or
`timeout`
- General `Error` data structure that can be extended to work with
different kinds of error types throughout the system
- Single interface, `publish_error()` can be used once Error type is
defined
- Removed usage gRPC ingestion service previously used only for
ingesting Usage data. Instead, using the general internal gRPC ingestion
service
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Introduced a garbage collection mechanism for the local cache,
enhancing resource management.
- **Improvements**
- Enhanced error handling during configuration initialization for better
debugging.
- Updated time calculations to improve accuracy and consistency.
- **Dependency Updates**
- Updated versions of key dependencies to leverage new features and
fixes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
This PR implements the new design of **Pipeline** introduced by #4432
---
**2 types of pipelines differentiates by the source**
Type I: **Realtime**
- source is a stream (Logs, Metrics, & Traces)
- takes effect when the source stream is being ingested
Type II: **Scheduled** (aka DerivedSteram)
- source is a SQL query
- takes effect based on the given schedule
The new pipeline is represented as a graph consists of different types
of Nodes that are connected by edges.
**Pipeline Data Model**
```rs
pub struct Pipeline {
pub id: String,
pub version: i32,
pub enabled: bool,
pub org: String,
pub name: String,
pub description: String,
pub source: PipelineSource,
pub nodes: Vec<Node>,
pub edges: Vec<Edge>,
}
```
**4 types of node**
I. StreamNode: either used for source node of realtime pipeline or for
destination nodes
II. QueryNode: used for source node of scheduled pipeline
III. FunctionNode: used for executing vrl functions
IV. ConditionNode: used for checking routing conditions
Rules applied to validating a pipeline when it's created:
1. non-empty nodes list
2. non-empty edges list
3. 1st node in nodes list is either StreamNode or QueryNode
4. non-empty `conditions` in all ConditionNode nodes in nodes list
5. all leaf nodes are of type StreamNode
6. In the same branch, unchecked `after_flattened` FunctionNode can't
follow checked
`after_flattened` checked FunctionNode
Pipeline execution is implemented with the struct `ExecutablePipeline`,
a ready-execute pipeline object cached in memory based on the Pipeline
objects modified on the UI side.
`ExecutablePipeline` object
- builds the relationships among all the nodes based on the edges
- topologically sorts the nodes based on the level to determine which
node to process first
- registers all the vrl function node once
`ExecutablePipeline` object processes ingested records in batch.
Starting from the source node, each connecting edge has a channel
connecting the parent and child node, used for passing the records. This
approach enables batch processing in parallel.
---
**Deprecated Features**
1. previous implementation of pipeline
2. Function x Stream associations
- Functions can still be added/edited/removed as before
- Needs to create a pipeline in order to apply chosen functions to the
desired stream
The new release when this pr is merged will automatically migrate **old
pipelines** and **Function x Stream associations** to new pipeline
format and can be found in `Stream Pipelines` tab with `Migrated-`
prefix names.
**_Note: Auto generated pipelines are paused by default. Please verify
the pipelines before enabling them_**
Co-authored-by: Taiming Liu <liutaiming3@gmail.com>
Co-authored-by: Bhargav <BJP232004@GMAIL.COM>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Enhanced query handling with restrictions based on stream settings.
- Improved response messaging to indicate partial data availability.
- **Bug Fixes**
- Adjusted query start time when exceeding maximum duration limits,
ensuring compliance with stream settings.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Now we use sql to plan to execute the query.
we split the PhysicalPlan to two stage:
1. Partial plan, it can be distributed will run on all the nodes.
2. Final plan, it can't be distributed will run on the leader querier
and merge the result.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Updated to version 0.10.9, introducing enhancements and new
dependencies for improved data processing functionalities.
- Added new Protocol Buffers schemas to define structures for cluster
management and data processing frameworks, enhancing integration
capabilities.
- **Bug Fixes**
- Improved error handling in configuration to prevent runtime panics.
- Enhanced logic in caching mechanisms for more reliable query
responses.
- **Documentation**
- Added module declarations to improve organization and clarity within
the codebase.
- **Refactor**
- Streamlined execution plans and SQL processing for better performance
and maintainability.
- **Tests**
- Introduced new functions for log ingestion in test suites to enhance
reliability and coverage.
- **Style**
- Made formatting adjustments across various files to improve
readability and consistency.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Neha P <neha@openobserve.ai>
Co-authored-by: oasisk <ashish.j.kolhe@gmail.com>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Updated critical dependencies to enhance software capabilities.
- Improved data structure management in StreamTable and Geoip
implementations for better performance and clarity.
- **Bug Fixes**
- Enhanced efficiency of entry removal in the data persistence process.
- **Chores**
- Routine updates to external package versions for improved
functionality and security.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Bug Fixes**
- Improved caching behavior and response processing in search requests.
- Enhanced error handling and response generation for better user
experience.
- **Tests**
- Disabled specific UI interaction in Playwright tests to prevent test
failures.
- **Chores**
- Updated configuration defaults to improve clarity and efficiency.
- Made internal constants publicly accessible for broader usage.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Patrick Sullivan
Hengfei Yang
Subhra264
Huaijin
udev
Yashodhan Joshi
Loakesh Indiran
Ashish Kolhe
John Vandenberg
Taiming Liu
dependabot[bot]