[Disscusion]Discuss the development direction of the ozhera-intelligence module

[psxjoy]

Motivation

Currently, Ozhera is part of the Apache Incubator, and the foundational features are in a relatively advanced development phase. I’d like to initiate a discussion on the development roadmap and key milestones for the ozhera-intelligence module.
I plan to leave the existing Ozhera modules as they are while using the ozhera-intelligence module to enable intelligent analysis for the Ozhera platform. Ideally, I’d like to decouple the ozhera-intelligence module, allowing it to function independently and offer broader support to other projects.

Goals

The ozhera-intelligence module will enable intelligent analysis for the Ozhera platform. The key goals for this module include:

• Allowing users to integrate with commercial AI interfaces like OpenAI, Qianwen, etc., as large-scale model data sources, or deploy their own internal models.
• Developing new interfaces tailored for troubleshooting and analysis within the Ozhera platform, using TraceId as a unique identifier.
• Offering a general interface that supports external troubleshooting and analysis beyond the platform.

MileStone

I believe the project milestones can be broken down into four key stages:

1. Basic intelligent troubleshooting and analysis.
   When a request or exception triggers an alarm, Ozhera will generate a traceID. All exception nodes and information within this traceID will be sent to the internal intelligence platform for analysis, giving users an initial diagnosis and potential solutions.

2. Extended intelligent troubleshooting and analysis.
   Expanding on the first milestone, we’ll analyze issues not only from a data flow perspective but also by looking at JVM metrics, CPU usage, container load, disk and network IO, TCP connections, and other system resources for a more comprehensive analysis.

3. Perceptive intelligent troubleshooting and alerting.
   We aim to detect dependency issues across applications. When problems occur, we want to not only identify the issue but also understand its impact on other modules. By analyzing the exception chain, we can gauge the extent of the issue and its ripple effect across the system.

4. Proactive intelligent troubleshooting and remediation.
   Building on the previous milestones, we’ll categorize common issues and errors within the platform. With this knowledge, ozhera-intelligence will be able to handle issues without disrupting the project, performing automated tasks such as scaling resources or restarting services when needed.

Core API and Configuration Changes

1. Add a new configuration option: OzheraIntelligenceModel. This is used to define and track the configuration settings for the large model source. OzheraIntelligenceModel should include parameters like model address, model name, and a validation token.
   As we refine the previous three steps, we aim to consolidate common errors and issues into a structured classification system for the platform. To ensure smooth integration of the ozhera-intelligence module, the OzheraIntelligenceModel configuration must be in place.

2. Implement an API to return model answers.

3. Create an API specifically for troubleshooting internal issues on the Ozhera platform:

    public String handleInfo(String traceID){...//TODO}

4. Introduce a general-purpose query API for model interaction:

   public String handleInfo(String loginfo){...//TODO}

Compatibility

As the ozhera-intelligence module is still under active discussion, backward compatibility isn’t a primary concern at this stage. However, we need to clarify: should we support JDK8? Many existing projects still rely on JDK8, and supporting it would potentially broaden the user base.