[DISCUSS] Incubating Proposal for OzHera

[Yu Xiao <xi...@apache.org>]

Dear incubator community,

I would like to propose OzHera[1] as a new apache incubator project, you
can find the proposal[2] of OzHera for more detail.

OzHera is an application performance observation platform that centers
around applications,
integrating metric monitoring, link tracing, logs, alerts, and other
capabilities.
The Hera platform has the following core features:

** Embrace Cloud Native
Complies with the Opentracing standard, integrating multiple star
open-source products such as OpenTelemetry,
Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
adapts to K8S,
providing one-click deployment on K8S through operator.

** Precise: Availability Metrics
We have defined corresponding availability metrics for common RPC
(Dubbo, HTTP, etc.) requests.
These request-scope metrics are automatically extracted from tracing
by Hera, and during extraction,
we enhance the ability to recognize business error codes.
A single metric can accurately express the exceptions encapsulated by
RPC and business processing.

** Quick: Metrics-Tracing-Logging Linkage
Based on traceId, it links the alarm -> metrics -> link -> log closed loop.
From the moment the alarm card touches the user, the user can quickly
view the link and log situation related to this alarm,
greatly improving the efficiency of problem locating.

** Economical
Less than 0.1% storage cost, satisfying 99.9% of tracing demands
OzHera achieves the recognition of abnormal calls (error span,
abnormal business error codes,
error logs, single span time exceeding 1 second, etc.) and ensures the
storage of data for the entire call link of abnormal traces.
For normal traces, we adopt a default random sampling strategy of one
in ten thousand.

** Enterprise-level Observable Products
Complete account, permission, application management mechanisms,
allowing users to quickly implement within the enterprise and connect
to the enterprise’s own account, application deployment system, etc.
It can also quickly dock with enterprise office software to achieve
alarm touch. Core links are well decoupled for rapid scaling,
and for large volumes of tracing, we have implemented tail sampling strategies,
able to support high qps, real-time observable demands of high
timeliness systems.

[1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
[2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal

Best,
Yu Xiao

ASF Member
Apache ShenYu V.P.
Apache Incubator PMC

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[Zhiyong Zhang <go...@apache.org>]

Thank you very much for your suggestion. We will separate the project today. In the future, I will also share some of the philosophies we adopted during the design stage. Currently, this project is online within Xiaomi. Thank you for your attention.

On 2023/09/06 14:58:34 Chojan Shang wrote:
> I am glad to see the proposal and get to know a new project. Metrics and tracing are crucial parts of modern applications.
> 
> However, it seems that OzHera still has a long way to go in terms of building a community. Even Mone appears to lack sufficient publicly available information. I am concerned about whether there are truly community contributors who can participate in maintaining the project.
> 
> In addition, other Incubator PMC members have also mentioned some issues worth paying attention to, such as branding. I hope to hear a sincere response.
> 
> Perhaps a better approach would be to first separate OzHera, collaborate openly for a period of time, and then proceed with the relevant evaluation and discussion.
> 
> Best,
> PsiACE
> 
> On 2023/09/05 03:11:28 Yu Xiao wrote:
> > Dear incubator community,
> > 
> > I would like to propose OzHera[1] as a new apache incubator project, you
> > can find the proposal[2] of OzHera for more detail.
> > 
> > OzHera is an application performance observation platform that centers
> > around applications,
> > integrating metric monitoring, link tracing, logs, alerts, and other
> > capabilities.
> > The Hera platform has the following core features:
> > 
> > ** Embrace Cloud Native
> > Complies with the Opentracing standard, integrating multiple star
> > open-source products such as OpenTelemetry,
> > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> > adapts to K8S,
> > providing one-click deployment on K8S through operator.
> > 
> > ** Precise: Availability Metrics
> > We have defined corresponding availability metrics for common RPC
> > (Dubbo, HTTP, etc.) requests.
> > These request-scope metrics are automatically extracted from tracing
> > by Hera, and during extraction,
> > we enhance the ability to recognize business error codes.
> > A single metric can accurately express the exceptions encapsulated by
> > RPC and business processing.
> > 
> > ** Quick: Metrics-Tracing-Logging Linkage
> > Based on traceId, it links the alarm -> metrics -> link -> log closed loop.
> > From the moment the alarm card touches the user, the user can quickly
> > view the link and log situation related to this alarm,
> > greatly improving the efficiency of problem locating.
> > 
> > ** Economical
> > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > OzHera achieves the recognition of abnormal calls (error span,
> > abnormal business error codes,
> > error logs, single span time exceeding 1 second, etc.) and ensures the
> > storage of data for the entire call link of abnormal traces.
> > For normal traces, we adopt a default random sampling strategy of one
> > in ten thousand.
> > 
> > ** Enterprise-level Observable Products
> > Complete account, permission, application management mechanisms,
> > allowing users to quickly implement within the enterprise and connect
> > to the enterprise’s own account, application deployment system, etc.
> > It can also quickly dock with enterprise office software to achieve
> > alarm touch. Core links are well decoupled for rapid scaling,
> > and for large volumes of tracing, we have implemented tail sampling strategies,
> > able to support high qps, real-time observable demands of high
> > timeliness systems.
> > 
> > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > [2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> > 
> > Best,
> > Yu Xiao
> > 
> > ASF Member
> > Apache ShenYu V.P.
> > Apache Incubator PMC
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[Chojan Shang <ps...@apache.org>]

I am glad to see the proposal and get to know a new project. Metrics and tracing are crucial parts of modern applications.

However, it seems that OzHera still has a long way to go in terms of building a community. Even Mone appears to lack sufficient publicly available information. I am concerned about whether there are truly community contributors who can participate in maintaining the project.

In addition, other Incubator PMC members have also mentioned some issues worth paying attention to, such as branding. I hope to hear a sincere response.

Perhaps a better approach would be to first separate OzHera, collaborate openly for a period of time, and then proceed with the relevant evaluation and discussion.

Best,
PsiACE

On 2023/09/05 03:11:28 Yu Xiao wrote:
> Dear incubator community,
> 
> I would like to propose OzHera[1] as a new apache incubator project, you
> can find the proposal[2] of OzHera for more detail.
> 
> OzHera is an application performance observation platform that centers
> around applications,
> integrating metric monitoring, link tracing, logs, alerts, and other
> capabilities.
> The Hera platform has the following core features:
> 
> ** Embrace Cloud Native
> Complies with the Opentracing standard, integrating multiple star
> open-source products such as OpenTelemetry,
> Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> adapts to K8S,
> providing one-click deployment on K8S through operator.
> 
> ** Precise: Availability Metrics
> We have defined corresponding availability metrics for common RPC
> (Dubbo, HTTP, etc.) requests.
> These request-scope metrics are automatically extracted from tracing
> by Hera, and during extraction,
> we enhance the ability to recognize business error codes.
> A single metric can accurately express the exceptions encapsulated by
> RPC and business processing.
> 
> ** Quick: Metrics-Tracing-Logging Linkage
> Based on traceId, it links the alarm -> metrics -> link -> log closed loop.
> From the moment the alarm card touches the user, the user can quickly
> view the link and log situation related to this alarm,
> greatly improving the efficiency of problem locating.
> 
> ** Economical
> Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> OzHera achieves the recognition of abnormal calls (error span,
> abnormal business error codes,
> error logs, single span time exceeding 1 second, etc.) and ensures the
> storage of data for the entire call link of abnormal traces.
> For normal traces, we adopt a default random sampling strategy of one
> in ten thousand.
> 
> ** Enterprise-level Observable Products
> Complete account, permission, application management mechanisms,
> allowing users to quickly implement within the enterprise and connect
> to the enterprise’s own account, application deployment system, etc.
> It can also quickly dock with enterprise office software to achieve
> alarm touch. Core links are well decoupled for rapid scaling,
> and for large volumes of tracing, we have implemented tail sampling strategies,
> able to support high qps, real-time observable demands of high
> timeliness systems.
> 
> [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> [2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> 
> Best,
> Yu Xiao
> 
> ASF Member
> Apache ShenYu V.P.
> Apache Incubator PMC
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[Sheng Wu <wu...@gmail.com>]

Hi

Please notice the term, IPMC represents Incubator Project Management
Committees, there is only one IPMC, no (s). You could say members of IPMC.

This is happening repeatedly. Please correct in the next time.


Sheng Wu 吴晟

Apache SkyWalking
Twitter, wusheng1108


Yu Xiao <xi...@apache.org>于2023年9月9日 周六21:12写道：

> Hi Justin,
>
> Thank you so much for your reply and advice.
>
> I will discuss with the current mentors about the suggestion and also
> try to find new mentors to increase the diversity.
>
> The project leaders have already started working on the issues raised
> by other IPMCs, such as "Initial committers proposal", "Ozhera
> separation from Mone", "IP and License clean" etc.
>
> Hope I could share a refined proposal in the near future!
>
> Best wishes!
>
> <ju...@classsoftware.com> 于2023年9月9日周六 11:56写道：
> >
> > Hi,
> >
> > For instance, I see your 4th higher committer doesn't seem to be on the
> initial committers list?
> >
> > Justin
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: [DISCUSS] Incubating Proposal for OzHera

[Yu Xiao <xi...@apache.org>]

Hi Justin,

Thank you so much for your reply and advice.

I will discuss with the current mentors about the suggestion and also
try to find new mentors to increase the diversity.

The project leaders have already started working on the issues raised
by other IPMCs, such as "Initial committers proposal", "Ozhera
separation from Mone", "IP and License clean" etc.

Hope I could share a refined proposal in the near future!

Best wishes!

<ju...@classsoftware.com> 于2023年9月9日周六 11:56写道：
>
> Hi,
>
> For instance, I see your 4th higher committer doesn't seem to be on the initial committers list?
>
> Justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[ju...@classsoftware.com]

Hi,

For instance, I see your 4th higher committer doesn't seem to be on the initial committers list?

Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[Justin Mclean <ju...@classsoftware.com>]

Hi,

As other IPMC members have mentioned, this project’s proposal has several issues, including IP, licensing and community issues and has probably been proposed too soon. 

I also want to add that 6 mentors are too many, and the project should consider including IPMC members outside of China.

I’m also not sure the "Creative Commons Legal Code” license is compatible with the Apache license and there are also other licenses list that are not listed in Category A ,B or X, e.g. "Mulan Permissive Software License”

Looking at the repo, it mentions several people as “owners”. What does this mean? ASF projects do not have owners. And as mentioned there seems to be a misunderstands of what the role of a mentor is in an ASF project.

The committer list mentioned in the repo is a lot larger than the initial committer list and yet some of the initial committers do not seem to be that active. How were the initial committers chosen and who do they work for? Can you also please provide a mapping of initial committer names to their GitHub accounts.

Kind Regards,
Justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

["张铎(Duo Zhang)" <pa...@gmail.com>]

Sorry for the late reply. Just came back from a business trip starting
from Monday. This year is tough, especially for small infra tech
companies in China, so most mentors are busy struggling to support the
company's business. That's partly the reason why this project has 6
mentors. We have limited time but we still want to help the project
and more mentors can back up each other.

I used to work at Xiaomi, from 2016 to 2021. I know these guys, they
have the passion to contribute to open source, although they are not
much familiar with open source. That's also the reason why I accept
their invitation to be the mentor of this project.

On the OzHera project, it is still in a very early open source stage,
so we agree that it is better to polish it for a while before joining
the incubator. Thanks to all the people in this thread for pointing
out the problems. The mentors will help the project to solve these
problems, or at least introduce a plan on how the problem will be
solved.
Including but not limited to
1.Split the mono repo and give OzHera a separated repo. So we can make
clear the scope of donation, and also make sure that OzHera can be
built and run separately.
2.Build the process for decision making and code contributing, follow
the open source and Apache way.
3.On the dependencies in Category X, it requires code changes, so it
is not easy to have a clear deadline. The mentors will help the
project to have a clear path on removing these dependencies. Mysql
connectors and ES are widely used and lots of Apache projects have
already solved the problem, so I'm optimistic this can also be solved
in OzHera.
4.About the potential IP conflicts with Alibaba, the two teams have
already reached a consensus offline and the issue has been closed. And
it is another part in the mono repo, not OzHera, so it will not
introduce any risks to ASF. The mentors will check OzHera carefully
and try to avoid other potential IP conflicts.
5.Internationality improvements. Introduce English version for the
documentation and also change the official developing language to
English. Since the main users are Chinese, the mentors will discuss
with the project team on how to balance.
6.On other things like the differences compared to Apache Skywalking,
the mentors will make sure to include the information in the next
proposal.

Thanks again. Hope we can be back soon.

tison <wa...@gmail.com> 于2023年9月8日周五 01:02写道：
>
> After a detailed review of the proposal, I'd suggest the champion check the
> content of the proposal before starting the discussion:
>
> > Documentation about Linkis can be found at
> https://github.com/XiaoMi/mone/blob/master/ozhera-all/README.md . Following
> links provide more information:
>
> Linkis?
>
> > The contributors of OzHera are actively involved in Apache community
> projects, and every member can access the project roadmap, issues, and code
> through various channels such as mailing lists and JIRA. By entering the
> Apache incubator, we believe OzHera can receive broader promotion and
> participation from companies and individuals.
>
> I don't find OzHera has associated "Mailing list and JIRA".
>
> > In this project, exceptional contributors are recognized and rewarded,
> fostering a collaborative and inclusive environment where decisions and
> project development are driven by capabilities and contributions.
>
> No evidence to show promoted contributors. The two proposed initial
> committers contributed trivial works just before a few days this proposal
> last modified.
>
> * Detoxify - https://github.com/XiaoMi/mone/commits?author=Detoxify
> * kongniancp - https://github.com/XiaoMi/mone/commits?author=kongniancp
>
> > elasticsearch Apache License, Version 2.0
>
> I agree that a single dependency entry bug is not easy to find. However, MySQL
> and ES are required as the storage of this project. If you check the
> essential architecture of this software, it should be noticed.
>
> > mysql-connector-java The GNU General Public License, Version 2
>
> You may ask the project to group dependencies by its license and then you
> can find dependencies licensed by GPL or other Category X licenses.
>
> Best,
> tison.
>
>
> Sheng Wu <wu...@gmail.com> 于2023年9月7日周四 21:07写道：
>
> > Sheng Wu <wu...@gmail.com> 于2023年9月6日周三 22:52写道：
> > >
> > > They are already beginning to remove the screenshots and comments that
> > > have proved the UI copy behaviors.
> > > They had known that and did that intentionally.
> > >
> > > Screenshots, https://twitter.com/wusheng1108/status/1699432297429114959.
> > > Now, if you see the issue again, it is
> > > gone.https://github.com/XiaoMi/mone/issues/689
> > >
> > > They have admitted their UIs are similar(most likely directly
> > > referring) to Aliyun Yunxiao commercial services. (Translation from
> > > their top3 maintainer's feedback)
> > >
> > > Anyway, I think the evidence is clear, there are bigger issues than
> > > `too-early-to-join`.
> > > AFAIK, the project and the maintainers are not suitable for ASF
> > > culture, even hard to say good enough in the OSS culture.
> > >
> > > More and more China local foundation members and PPMC members are
> > > showing up to share their concerns and consensus of saying NO to the
> > > project.
> > > They have all the right to do things on their own, but let's keep the
> > > foundation and incubator safe from this kind of chaos.
> >
> > One update, Xiaomi Inc. and Aliyun Inc. seem to have some confident
> > agreement on this issue.
> > The issue title has been updated as `have settled`(translated from
> > Chinese).
> > And original complaint had been removed too.
> >
> > I want to point out, this doesn't mean it is good for the foundation.
> > From the current statement, we can only guess there are conflicts, but
> > they have an agreement.
> > But they don't declare that the UI design is IP clearance.
> > This should be hold as a potential IP issue.
> >
> > >
> > > Sheng Wu 吴晟
> > > Twitter, wusheng1108
> > >
> > > tison <wa...@gmail.com> 于2023年9月6日周三 22:36写道：
> > > >
> > > > > attaching the screenshot
> > > >
> > > > I don't see an attachment in your email. If you paste the screenshot
> > > > inline, it can be filtered out by mailing list policy. You can attach a
> > > > file or upload it to an external image hosting service.
> > > >
> > > > Best,
> > > > tison.
> > > >
> > > >
> > > > Sheng Wu <wu...@gmail.com> 于2023年9月6日周三 21:23写道：
> > > >
> > > > > One more update.
> > > > > With this project being noticed by this project, the parent project
> > is
> > > > > facing the challenge of copying from Ali Yunxiao, which is one of the
> > > > > Aliyun commercial services.
> > > > > Ref source in CN, https://github.com/XiaoMi/mone/issues/689,
> > attaching
> > > > > the screenshot in case of the owner deleted this issue.
> > > > >
> > > > > The good thing is, that this is not the ASF and incubator issue, we
> > > > > don't have an obligation to prove this is true or false.
> > > > > But this is a validation of my feelings that this project was not
> > > > > audited carefully, although one of them declared they are.
> > > > >
> > > > >
> > > > > Sheng Wu 吴晟
> > > > > Twitter, wusheng1108
> > > > >
> > > > > Calvin Kirs <ki...@apache.org> 于2023年9月6日周三 20:15写道：
> > > > > >
> > > > > > Is this a (community) with only 38 issues?
> > > > > > There are tons of commits from the community. How does the decision
> > > > > > happen? ok, I saw this, relying on Gitter[1] with only 6 people
> > and 8
> > > > > > messages?
> > > > > >
> > > > > > pls forgive me, after reviewing your proposal
> > > > > > I really don’t know how to describe it.
> > > > > >
> > > > > > [1]https://app.gitter.im/#/room/#monegrow_community:gitter.im
> > > > > >
> > > > > > On Wed, Sep 6, 2023 at 6:14 PM Zhiyong Zhang <go...@apache.org>
> > > > > wrote:
> > > > > > >
> > > > > > > Without Mone, OzHera can be used independently. Currently, in
> > addition
> > > > > to Xiaomi, there are also some external manufacturers using or
> > researching
> > > > > it. Mone is a larger collection within Xiaomi, and we are
> > considering open
> > > > > sourcing all of it in the future (which includes cicd rpc,
> > registration
> > > > > center, container management, stress testing system, API platform,
> > gateway,
> > > > > tunnel governance, etc.)
> > > > > > >
> > > > > > > On 2023/09/05 17:45:24 Xuanwo wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > Thanks for the interesting proposal first!
> > > > > > > >
> > > > > > > > I would like to understand the connection between Xiaomi/mone
> > and
> > > > > OzHera. Will OzHera be transferred from Xiaomi/mono to
> > > > > apache/incubator-ozhera while keeping the rest of the code
> > unchanged? Can
> > > > > OzHera be used independently without Xiaomi/mono?
> > > > > > > >
> > > > > > > > On Tue, Sep 5, 2023, at 11:11, Yu Xiao wrote:
> > > > > > > > > Dear incubator community,
> > > > > > > > >
> > > > > > > > > I would like to propose OzHera[1] as a new apache incubator
> > > > > project, you
> > > > > > > > > can find the proposal[2] of OzHera for more detail.
> > > > > > > > >
> > > > > > > > > OzHera is an application performance observation platform
> > that
> > > > > centers
> > > > > > > > > around applications,
> > > > > > > > > integrating metric monitoring, link tracing, logs, alerts,
> > and
> > > > > other
> > > > > > > > > capabilities.
> > > > > > > > > The Hera platform has the following core features:
> > > > > > > > >
> > > > > > > > > ** Embrace Cloud Native
> > > > > > > > > Complies with the Opentracing standard, integrating multiple
> > star
> > > > > > > > > open-source products such as OpenTelemetry,
> > > > > > > > > Grafana, Prometheus, ES, CAdvisor, etc. At the same time,
> > Hera
> > > > > deeply
> > > > > > > > > adapts to K8S,
> > > > > > > > > providing one-click deployment on K8S through operator.
> > > > > > > > >
> > > > > > > > > ** Precise: Availability Metrics
> > > > > > > > > We have defined corresponding availability metrics for
> > common RPC
> > > > > > > > > (Dubbo, HTTP, etc.) requests.
> > > > > > > > > These request-scope metrics are automatically extracted from
> > > > > tracing
> > > > > > > > > by Hera, and during extraction,
> > > > > > > > > we enhance the ability to recognize business error codes.
> > > > > > > > > A single metric can accurately express the exceptions
> > encapsulated
> > > > > by
> > > > > > > > > RPC and business processing.
> > > > > > > > >
> > > > > > > > > ** Quick: Metrics-Tracing-Logging Linkage
> > > > > > > > > Based on traceId, it links the alarm -> metrics -> link ->
> > log
> > > > > closed loop.
> > > > > > > > > From the moment the alarm card touches the user, the user can
> > > > > quickly
> > > > > > > > > view the link and log situation related to this alarm,
> > > > > > > > > greatly improving the efficiency of problem locating.
> > > > > > > > >
> > > > > > > > > ** Economical
> > > > > > > > > Less than 0.1% storage cost, satisfying 99.9% of tracing
> > demands
> > > > > > > > > OzHera achieves the recognition of abnormal calls (error
> > span,
> > > > > > > > > abnormal business error codes,
> > > > > > > > > error logs, single span time exceeding 1 second, etc.) and
> > ensures
> > > > > the
> > > > > > > > > storage of data for the entire call link of abnormal traces.
> > > > > > > > > For normal traces, we adopt a default random sampling
> > strategy of
> > > > > one
> > > > > > > > > in ten thousand.
> > > > > > > > >
> > > > > > > > > ** Enterprise-level Observable Products
> > > > > > > > > Complete account, permission, application management
> > mechanisms,
> > > > > > > > > allowing users to quickly implement within the enterprise and
> > > > > connect
> > > > > > > > > to the enterprise’s own account, application deployment
> > system,
> > > > > etc.
> > > > > > > > > It can also quickly dock with enterprise office software to
> > achieve
> > > > > > > > > alarm touch. Core links are well decoupled for rapid scaling,
> > > > > > > > > and for large volumes of tracing, we have implemented tail
> > > > > sampling strategies,
> > > > > > > > > able to support high qps, real-time observable demands of
> > high
> > > > > > > > > timeliness systems.
> > > > > > > > >
> > > > > > > > > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > > > > > > > > [2]
> > > > > https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> > > > > > > > >
> > > > > > > > > Best,
> > > > > > > > > Yu Xiao
> > > > > > > > >
> > > > > > > > > ASF Member
> > > > > > > > > Apache ShenYu V.P.
> > > > > > > > > Apache Incubator PMC
> > > > > > > > >
> > > > > > > > >
> > > > > ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail:
> > general-unsubscribe@incubator.apache.org
> > > > > > > > > For additional commands, e-mail:
> > general-help@incubator.apache.org
> > > > > > > >
> > > > > > > > --
> > > > > > > > Xuanwo
> > > > > > > >
> > > > > > > >
> > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail:
> > general-unsubscribe@incubator.apache.org
> > > > > > > > For additional commands, e-mail:
> > general-help@incubator.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > > > For additional commands, e-mail:
> > general-help@incubator.apache.org
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best wishes！
> > > > > > CalvinKirs
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > For additional commands, e-mail: general-help@incubator.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[tison <wa...@gmail.com>]

After a detailed review of the proposal, I'd suggest the champion check the
content of the proposal before starting the discussion:

> Documentation about Linkis can be found at
https://github.com/XiaoMi/mone/blob/master/ozhera-all/README.md . Following
links provide more information:

Linkis?

> The contributors of OzHera are actively involved in Apache community
projects, and every member can access the project roadmap, issues, and code
through various channels such as mailing lists and JIRA. By entering the
Apache incubator, we believe OzHera can receive broader promotion and
participation from companies and individuals.

I don't find OzHera has associated "Mailing list and JIRA".

> In this project, exceptional contributors are recognized and rewarded,
fostering a collaborative and inclusive environment where decisions and
project development are driven by capabilities and contributions.

No evidence to show promoted contributors. The two proposed initial
committers contributed trivial works just before a few days this proposal
last modified.

* Detoxify - https://github.com/XiaoMi/mone/commits?author=Detoxify
* kongniancp - https://github.com/XiaoMi/mone/commits?author=kongniancp

> elasticsearch Apache License, Version 2.0

I agree that a single dependency entry bug is not easy to find. However, MySQL
and ES are required as the storage of this project. If you check the
essential architecture of this software, it should be noticed.

> mysql-connector-java The GNU General Public License, Version 2

You may ask the project to group dependencies by its license and then you
can find dependencies licensed by GPL or other Category X licenses.

Best,
tison.


Sheng Wu <wu...@gmail.com> 于2023年9月7日周四 21:07写道：

> Sheng Wu <wu...@gmail.com> 于2023年9月6日周三 22:52写道：
> >
> > They are already beginning to remove the screenshots and comments that
> > have proved the UI copy behaviors.
> > They had known that and did that intentionally.
> >
> > Screenshots, https://twitter.com/wusheng1108/status/1699432297429114959.
> > Now, if you see the issue again, it is
> > gone.https://github.com/XiaoMi/mone/issues/689
> >
> > They have admitted their UIs are similar(most likely directly
> > referring) to Aliyun Yunxiao commercial services. (Translation from
> > their top3 maintainer's feedback)
> >
> > Anyway, I think the evidence is clear, there are bigger issues than
> > `too-early-to-join`.
> > AFAIK, the project and the maintainers are not suitable for ASF
> > culture, even hard to say good enough in the OSS culture.
> >
> > More and more China local foundation members and PPMC members are
> > showing up to share their concerns and consensus of saying NO to the
> > project.
> > They have all the right to do things on their own, but let's keep the
> > foundation and incubator safe from this kind of chaos.
>
> One update, Xiaomi Inc. and Aliyun Inc. seem to have some confident
> agreement on this issue.
> The issue title has been updated as `have settled`(translated from
> Chinese).
> And original complaint had been removed too.
>
> I want to point out, this doesn't mean it is good for the foundation.
> From the current statement, we can only guess there are conflicts, but
> they have an agreement.
> But they don't declare that the UI design is IP clearance.
> This should be hold as a potential IP issue.
>
> >
> > Sheng Wu 吴晟
> > Twitter, wusheng1108
> >
> > tison <wa...@gmail.com> 于2023年9月6日周三 22:36写道：
> > >
> > > > attaching the screenshot
> > >
> > > I don't see an attachment in your email. If you paste the screenshot
> > > inline, it can be filtered out by mailing list policy. You can attach a
> > > file or upload it to an external image hosting service.
> > >
> > > Best,
> > > tison.
> > >
> > >
> > > Sheng Wu <wu...@gmail.com> 于2023年9月6日周三 21:23写道：
> > >
> > > > One more update.
> > > > With this project being noticed by this project, the parent project
> is
> > > > facing the challenge of copying from Ali Yunxiao, which is one of the
> > > > Aliyun commercial services.
> > > > Ref source in CN, https://github.com/XiaoMi/mone/issues/689,
> attaching
> > > > the screenshot in case of the owner deleted this issue.
> > > >
> > > > The good thing is, that this is not the ASF and incubator issue, we
> > > > don't have an obligation to prove this is true or false.
> > > > But this is a validation of my feelings that this project was not
> > > > audited carefully, although one of them declared they are.
> > > >
> > > >
> > > > Sheng Wu 吴晟
> > > > Twitter, wusheng1108
> > > >
> > > > Calvin Kirs <ki...@apache.org> 于2023年9月6日周三 20:15写道：
> > > > >
> > > > > Is this a (community) with only 38 issues?
> > > > > There are tons of commits from the community. How does the decision
> > > > > happen? ok, I saw this, relying on Gitter[1] with only 6 people
> and 8
> > > > > messages?
> > > > >
> > > > > pls forgive me, after reviewing your proposal
> > > > > I really don’t know how to describe it.
> > > > >
> > > > > [1]https://app.gitter.im/#/room/#monegrow_community:gitter.im
> > > > >
> > > > > On Wed, Sep 6, 2023 at 6:14 PM Zhiyong Zhang <go...@apache.org>
> > > > wrote:
> > > > > >
> > > > > > Without Mone, OzHera can be used independently. Currently, in
> addition
> > > > to Xiaomi, there are also some external manufacturers using or
> researching
> > > > it. Mone is a larger collection within Xiaomi, and we are
> considering open
> > > > sourcing all of it in the future (which includes cicd rpc,
> registration
> > > > center, container management, stress testing system, API platform,
> gateway,
> > > > tunnel governance, etc.)
> > > > > >
> > > > > > On 2023/09/05 17:45:24 Xuanwo wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > Thanks for the interesting proposal first!
> > > > > > >
> > > > > > > I would like to understand the connection between Xiaomi/mone
> and
> > > > OzHera. Will OzHera be transferred from Xiaomi/mono to
> > > > apache/incubator-ozhera while keeping the rest of the code
> unchanged? Can
> > > > OzHera be used independently without Xiaomi/mono?
> > > > > > >
> > > > > > > On Tue, Sep 5, 2023, at 11:11, Yu Xiao wrote:
> > > > > > > > Dear incubator community,
> > > > > > > >
> > > > > > > > I would like to propose OzHera[1] as a new apache incubator
> > > > project, you
> > > > > > > > can find the proposal[2] of OzHera for more detail.
> > > > > > > >
> > > > > > > > OzHera is an application performance observation platform
> that
> > > > centers
> > > > > > > > around applications,
> > > > > > > > integrating metric monitoring, link tracing, logs, alerts,
> and
> > > > other
> > > > > > > > capabilities.
> > > > > > > > The Hera platform has the following core features:
> > > > > > > >
> > > > > > > > ** Embrace Cloud Native
> > > > > > > > Complies with the Opentracing standard, integrating multiple
> star
> > > > > > > > open-source products such as OpenTelemetry,
> > > > > > > > Grafana, Prometheus, ES, CAdvisor, etc. At the same time,
> Hera
> > > > deeply
> > > > > > > > adapts to K8S,
> > > > > > > > providing one-click deployment on K8S through operator.
> > > > > > > >
> > > > > > > > ** Precise: Availability Metrics
> > > > > > > > We have defined corresponding availability metrics for
> common RPC
> > > > > > > > (Dubbo, HTTP, etc.) requests.
> > > > > > > > These request-scope metrics are automatically extracted from
> > > > tracing
> > > > > > > > by Hera, and during extraction,
> > > > > > > > we enhance the ability to recognize business error codes.
> > > > > > > > A single metric can accurately express the exceptions
> encapsulated
> > > > by
> > > > > > > > RPC and business processing.
> > > > > > > >
> > > > > > > > ** Quick: Metrics-Tracing-Logging Linkage
> > > > > > > > Based on traceId, it links the alarm -> metrics -> link ->
> log
> > > > closed loop.
> > > > > > > > From the moment the alarm card touches the user, the user can
> > > > quickly
> > > > > > > > view the link and log situation related to this alarm,
> > > > > > > > greatly improving the efficiency of problem locating.
> > > > > > > >
> > > > > > > > ** Economical
> > > > > > > > Less than 0.1% storage cost, satisfying 99.9% of tracing
> demands
> > > > > > > > OzHera achieves the recognition of abnormal calls (error
> span,
> > > > > > > > abnormal business error codes,
> > > > > > > > error logs, single span time exceeding 1 second, etc.) and
> ensures
> > > > the
> > > > > > > > storage of data for the entire call link of abnormal traces.
> > > > > > > > For normal traces, we adopt a default random sampling
> strategy of
> > > > one
> > > > > > > > in ten thousand.
> > > > > > > >
> > > > > > > > ** Enterprise-level Observable Products
> > > > > > > > Complete account, permission, application management
> mechanisms,
> > > > > > > > allowing users to quickly implement within the enterprise and
> > > > connect
> > > > > > > > to the enterprise’s own account, application deployment
> system,
> > > > etc.
> > > > > > > > It can also quickly dock with enterprise office software to
> achieve
> > > > > > > > alarm touch. Core links are well decoupled for rapid scaling,
> > > > > > > > and for large volumes of tracing, we have implemented tail
> > > > sampling strategies,
> > > > > > > > able to support high qps, real-time observable demands of
> high
> > > > > > > > timeliness systems.
> > > > > > > >
> > > > > > > > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > > > > > > > [2]
> > > > https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > Yu Xiao
> > > > > > > >
> > > > > > > > ASF Member
> > > > > > > > Apache ShenYu V.P.
> > > > > > > > Apache Incubator PMC
> > > > > > > >
> > > > > > > >
> > > > ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail:
> general-unsubscribe@incubator.apache.org
> > > > > > > > For additional commands, e-mail:
> general-help@incubator.apache.org
> > > > > > >
> > > > > > > --
> > > > > > > Xuanwo
> > > > > > >
> > > > > > >
> ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail:
> general-unsubscribe@incubator.apache.org
> > > > > > > For additional commands, e-mail:
> general-help@incubator.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > > For additional commands, e-mail:
> general-help@incubator.apache.org
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best wishes！
> > > > > CalvinKirs
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > > >
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: [DISCUSS] Incubating Proposal for OzHera

[Sheng Wu <wu...@gmail.com>]

Sheng Wu <wu...@gmail.com> 于2023年9月6日周三 22:52写道：
>
> They are already beginning to remove the screenshots and comments that
> have proved the UI copy behaviors.
> They had known that and did that intentionally.
>
> Screenshots, https://twitter.com/wusheng1108/status/1699432297429114959.
> Now, if you see the issue again, it is
> gone.https://github.com/XiaoMi/mone/issues/689
>
> They have admitted their UIs are similar(most likely directly
> referring) to Aliyun Yunxiao commercial services. (Translation from
> their top3 maintainer's feedback)
>
> Anyway, I think the evidence is clear, there are bigger issues than
> `too-early-to-join`.
> AFAIK, the project and the maintainers are not suitable for ASF
> culture, even hard to say good enough in the OSS culture.
>
> More and more China local foundation members and PPMC members are
> showing up to share their concerns and consensus of saying NO to the
> project.
> They have all the right to do things on their own, but let's keep the
> foundation and incubator safe from this kind of chaos.

One update, Xiaomi Inc. and Aliyun Inc. seem to have some confident
agreement on this issue.
The issue title has been updated as `have settled`(translated from Chinese).
And original complaint had been removed too.

I want to point out, this doesn't mean it is good for the foundation.
From the current statement, we can only guess there are conflicts, but
they have an agreement.
But they don't declare that the UI design is IP clearance.
This should be hold as a potential IP issue.

>
> Sheng Wu 吴晟
> Twitter, wusheng1108
>
> tison <wa...@gmail.com> 于2023年9月6日周三 22:36写道：
> >
> > > attaching the screenshot
> >
> > I don't see an attachment in your email. If you paste the screenshot
> > inline, it can be filtered out by mailing list policy. You can attach a
> > file or upload it to an external image hosting service.
> >
> > Best,
> > tison.
> >
> >
> > Sheng Wu <wu...@gmail.com> 于2023年9月6日周三 21:23写道：
> >
> > > One more update.
> > > With this project being noticed by this project, the parent project is
> > > facing the challenge of copying from Ali Yunxiao, which is one of the
> > > Aliyun commercial services.
> > > Ref source in CN, https://github.com/XiaoMi/mone/issues/689, attaching
> > > the screenshot in case of the owner deleted this issue.
> > >
> > > The good thing is, that this is not the ASF and incubator issue, we
> > > don't have an obligation to prove this is true or false.
> > > But this is a validation of my feelings that this project was not
> > > audited carefully, although one of them declared they are.
> > >
> > >
> > > Sheng Wu 吴晟
> > > Twitter, wusheng1108
> > >
> > > Calvin Kirs <ki...@apache.org> 于2023年9月6日周三 20:15写道：
> > > >
> > > > Is this a (community) with only 38 issues?
> > > > There are tons of commits from the community. How does the decision
> > > > happen? ok, I saw this, relying on Gitter[1] with only 6 people and 8
> > > > messages?
> > > >
> > > > pls forgive me, after reviewing your proposal
> > > > I really don’t know how to describe it.
> > > >
> > > > [1]https://app.gitter.im/#/room/#monegrow_community:gitter.im
> > > >
> > > > On Wed, Sep 6, 2023 at 6:14 PM Zhiyong Zhang <go...@apache.org>
> > > wrote:
> > > > >
> > > > > Without Mone, OzHera can be used independently. Currently, in addition
> > > to Xiaomi, there are also some external manufacturers using or researching
> > > it. Mone is a larger collection within Xiaomi, and we are considering open
> > > sourcing all of it in the future (which includes cicd rpc, registration
> > > center, container management, stress testing system, API platform, gateway,
> > > tunnel governance, etc.)
> > > > >
> > > > > On 2023/09/05 17:45:24 Xuanwo wrote:
> > > > > > Hi,
> > > > > >
> > > > > > Thanks for the interesting proposal first!
> > > > > >
> > > > > > I would like to understand the connection between Xiaomi/mone and
> > > OzHera. Will OzHera be transferred from Xiaomi/mono to
> > > apache/incubator-ozhera while keeping the rest of the code unchanged? Can
> > > OzHera be used independently without Xiaomi/mono?
> > > > > >
> > > > > > On Tue, Sep 5, 2023, at 11:11, Yu Xiao wrote:
> > > > > > > Dear incubator community,
> > > > > > >
> > > > > > > I would like to propose OzHera[1] as a new apache incubator
> > > project, you
> > > > > > > can find the proposal[2] of OzHera for more detail.
> > > > > > >
> > > > > > > OzHera is an application performance observation platform that
> > > centers
> > > > > > > around applications,
> > > > > > > integrating metric monitoring, link tracing, logs, alerts, and
> > > other
> > > > > > > capabilities.
> > > > > > > The Hera platform has the following core features:
> > > > > > >
> > > > > > > ** Embrace Cloud Native
> > > > > > > Complies with the Opentracing standard, integrating multiple star
> > > > > > > open-source products such as OpenTelemetry,
> > > > > > > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera
> > > deeply
> > > > > > > adapts to K8S,
> > > > > > > providing one-click deployment on K8S through operator.
> > > > > > >
> > > > > > > ** Precise: Availability Metrics
> > > > > > > We have defined corresponding availability metrics for common RPC
> > > > > > > (Dubbo, HTTP, etc.) requests.
> > > > > > > These request-scope metrics are automatically extracted from
> > > tracing
> > > > > > > by Hera, and during extraction,
> > > > > > > we enhance the ability to recognize business error codes.
> > > > > > > A single metric can accurately express the exceptions encapsulated
> > > by
> > > > > > > RPC and business processing.
> > > > > > >
> > > > > > > ** Quick: Metrics-Tracing-Logging Linkage
> > > > > > > Based on traceId, it links the alarm -> metrics -> link -> log
> > > closed loop.
> > > > > > > From the moment the alarm card touches the user, the user can
> > > quickly
> > > > > > > view the link and log situation related to this alarm,
> > > > > > > greatly improving the efficiency of problem locating.
> > > > > > >
> > > > > > > ** Economical
> > > > > > > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > > > > > > OzHera achieves the recognition of abnormal calls (error span,
> > > > > > > abnormal business error codes,
> > > > > > > error logs, single span time exceeding 1 second, etc.) and ensures
> > > the
> > > > > > > storage of data for the entire call link of abnormal traces.
> > > > > > > For normal traces, we adopt a default random sampling strategy of
> > > one
> > > > > > > in ten thousand.
> > > > > > >
> > > > > > > ** Enterprise-level Observable Products
> > > > > > > Complete account, permission, application management mechanisms,
> > > > > > > allowing users to quickly implement within the enterprise and
> > > connect
> > > > > > > to the enterprise’s own account, application deployment system,
> > > etc.
> > > > > > > It can also quickly dock with enterprise office software to achieve
> > > > > > > alarm touch. Core links are well decoupled for rapid scaling,
> > > > > > > and for large volumes of tracing, we have implemented tail
> > > sampling strategies,
> > > > > > > able to support high qps, real-time observable demands of high
> > > > > > > timeliness systems.
> > > > > > >
> > > > > > > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > > > > > > [2]
> > > https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> > > > > > >
> > > > > > > Best,
> > > > > > > Yu Xiao
> > > > > > >
> > > > > > > ASF Member
> > > > > > > Apache ShenYu V.P.
> > > > > > > Apache Incubator PMC
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > > > >
> > > > > > --
> > > > > > Xuanwo
> > > > > >
> > > > > > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > > >
> > > >
> > > >
> > > > --
> > > > Best wishes！
> > > > CalvinKirs
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[Sheng Wu <wu...@gmail.com>]

They are already beginning to remove the screenshots and comments that
have proved the UI copy behaviors.
They had known that and did that intentionally.

Screenshots, https://twitter.com/wusheng1108/status/1699432297429114959.
Now, if you see the issue again, it is
gone.https://github.com/XiaoMi/mone/issues/689

They have admitted their UIs are similar(most likely directly
referring) to Aliyun Yunxiao commercial services. (Translation from
their top3 maintainer's feedback)

Anyway, I think the evidence is clear, there are bigger issues than
`too-early-to-join`.
AFAIK, the project and the maintainers are not suitable for ASF
culture, even hard to say good enough in the OSS culture.

More and more China local foundation members and PPMC members are
showing up to share their concerns and consensus of saying NO to the
project.
They have all the right to do things on their own, but let's keep the
foundation and incubator safe from this kind of chaos.

Sheng Wu 吴晟
Twitter, wusheng1108

tison <wa...@gmail.com> 于2023年9月6日周三 22:36写道：
>
> > attaching the screenshot
>
> I don't see an attachment in your email. If you paste the screenshot
> inline, it can be filtered out by mailing list policy. You can attach a
> file or upload it to an external image hosting service.
>
> Best,
> tison.
>
>
> Sheng Wu <wu...@gmail.com> 于2023年9月6日周三 21:23写道：
>
> > One more update.
> > With this project being noticed by this project, the parent project is
> > facing the challenge of copying from Ali Yunxiao, which is one of the
> > Aliyun commercial services.
> > Ref source in CN, https://github.com/XiaoMi/mone/issues/689, attaching
> > the screenshot in case of the owner deleted this issue.
> >
> > The good thing is, that this is not the ASF and incubator issue, we
> > don't have an obligation to prove this is true or false.
> > But this is a validation of my feelings that this project was not
> > audited carefully, although one of them declared they are.
> >
> >
> > Sheng Wu 吴晟
> > Twitter, wusheng1108
> >
> > Calvin Kirs <ki...@apache.org> 于2023年9月6日周三 20:15写道：
> > >
> > > Is this a (community) with only 38 issues?
> > > There are tons of commits from the community. How does the decision
> > > happen? ok, I saw this, relying on Gitter[1] with only 6 people and 8
> > > messages?
> > >
> > > pls forgive me, after reviewing your proposal
> > > I really don’t know how to describe it.
> > >
> > > [1]https://app.gitter.im/#/room/#monegrow_community:gitter.im
> > >
> > > On Wed, Sep 6, 2023 at 6:14 PM Zhiyong Zhang <go...@apache.org>
> > wrote:
> > > >
> > > > Without Mone, OzHera can be used independently. Currently, in addition
> > to Xiaomi, there are also some external manufacturers using or researching
> > it. Mone is a larger collection within Xiaomi, and we are considering open
> > sourcing all of it in the future (which includes cicd rpc, registration
> > center, container management, stress testing system, API platform, gateway,
> > tunnel governance, etc.)
> > > >
> > > > On 2023/09/05 17:45:24 Xuanwo wrote:
> > > > > Hi,
> > > > >
> > > > > Thanks for the interesting proposal first!
> > > > >
> > > > > I would like to understand the connection between Xiaomi/mone and
> > OzHera. Will OzHera be transferred from Xiaomi/mono to
> > apache/incubator-ozhera while keeping the rest of the code unchanged? Can
> > OzHera be used independently without Xiaomi/mono?
> > > > >
> > > > > On Tue, Sep 5, 2023, at 11:11, Yu Xiao wrote:
> > > > > > Dear incubator community,
> > > > > >
> > > > > > I would like to propose OzHera[1] as a new apache incubator
> > project, you
> > > > > > can find the proposal[2] of OzHera for more detail.
> > > > > >
> > > > > > OzHera is an application performance observation platform that
> > centers
> > > > > > around applications,
> > > > > > integrating metric monitoring, link tracing, logs, alerts, and
> > other
> > > > > > capabilities.
> > > > > > The Hera platform has the following core features:
> > > > > >
> > > > > > ** Embrace Cloud Native
> > > > > > Complies with the Opentracing standard, integrating multiple star
> > > > > > open-source products such as OpenTelemetry,
> > > > > > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera
> > deeply
> > > > > > adapts to K8S,
> > > > > > providing one-click deployment on K8S through operator.
> > > > > >
> > > > > > ** Precise: Availability Metrics
> > > > > > We have defined corresponding availability metrics for common RPC
> > > > > > (Dubbo, HTTP, etc.) requests.
> > > > > > These request-scope metrics are automatically extracted from
> > tracing
> > > > > > by Hera, and during extraction,
> > > > > > we enhance the ability to recognize business error codes.
> > > > > > A single metric can accurately express the exceptions encapsulated
> > by
> > > > > > RPC and business processing.
> > > > > >
> > > > > > ** Quick: Metrics-Tracing-Logging Linkage
> > > > > > Based on traceId, it links the alarm -> metrics -> link -> log
> > closed loop.
> > > > > > From the moment the alarm card touches the user, the user can
> > quickly
> > > > > > view the link and log situation related to this alarm,
> > > > > > greatly improving the efficiency of problem locating.
> > > > > >
> > > > > > ** Economical
> > > > > > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > > > > > OzHera achieves the recognition of abnormal calls (error span,
> > > > > > abnormal business error codes,
> > > > > > error logs, single span time exceeding 1 second, etc.) and ensures
> > the
> > > > > > storage of data for the entire call link of abnormal traces.
> > > > > > For normal traces, we adopt a default random sampling strategy of
> > one
> > > > > > in ten thousand.
> > > > > >
> > > > > > ** Enterprise-level Observable Products
> > > > > > Complete account, permission, application management mechanisms,
> > > > > > allowing users to quickly implement within the enterprise and
> > connect
> > > > > > to the enterprise’s own account, application deployment system,
> > etc.
> > > > > > It can also quickly dock with enterprise office software to achieve
> > > > > > alarm touch. Core links are well decoupled for rapid scaling,
> > > > > > and for large volumes of tracing, we have implemented tail
> > sampling strategies,
> > > > > > able to support high qps, real-time observable demands of high
> > > > > > timeliness systems.
> > > > > >
> > > > > > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > > > > > [2]
> > https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> > > > > >
> > > > > > Best,
> > > > > > Yu Xiao
> > > > > >
> > > > > > ASF Member
> > > > > > Apache ShenYu V.P.
> > > > > > Apache Incubator PMC
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > > >
> > > > > --
> > > > > Xuanwo
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > >
> > >
> > >
> > > --
> > > Best wishes！
> > > CalvinKirs
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[tison <wa...@gmail.com>]

> attaching the screenshot

I don't see an attachment in your email. If you paste the screenshot
inline, it can be filtered out by mailing list policy. You can attach a
file or upload it to an external image hosting service.

Best,
tison.


Sheng Wu <wu...@gmail.com> 于2023年9月6日周三 21:23写道：

> One more update.
> With this project being noticed by this project, the parent project is
> facing the challenge of copying from Ali Yunxiao, which is one of the
> Aliyun commercial services.
> Ref source in CN, https://github.com/XiaoMi/mone/issues/689, attaching
> the screenshot in case of the owner deleted this issue.
>
> The good thing is, that this is not the ASF and incubator issue, we
> don't have an obligation to prove this is true or false.
> But this is a validation of my feelings that this project was not
> audited carefully, although one of them declared they are.
>
>
> Sheng Wu 吴晟
> Twitter, wusheng1108
>
> Calvin Kirs <ki...@apache.org> 于2023年9月6日周三 20:15写道：
> >
> > Is this a (community) with only 38 issues?
> > There are tons of commits from the community. How does the decision
> > happen? ok, I saw this, relying on Gitter[1] with only 6 people and 8
> > messages?
> >
> > pls forgive me, after reviewing your proposal
> > I really don’t know how to describe it.
> >
> > [1]https://app.gitter.im/#/room/#monegrow_community:gitter.im
> >
> > On Wed, Sep 6, 2023 at 6:14 PM Zhiyong Zhang <go...@apache.org>
> wrote:
> > >
> > > Without Mone, OzHera can be used independently. Currently, in addition
> to Xiaomi, there are also some external manufacturers using or researching
> it. Mone is a larger collection within Xiaomi, and we are considering open
> sourcing all of it in the future (which includes cicd rpc, registration
> center, container management, stress testing system, API platform, gateway,
> tunnel governance, etc.)
> > >
> > > On 2023/09/05 17:45:24 Xuanwo wrote:
> > > > Hi,
> > > >
> > > > Thanks for the interesting proposal first!
> > > >
> > > > I would like to understand the connection between Xiaomi/mone and
> OzHera. Will OzHera be transferred from Xiaomi/mono to
> apache/incubator-ozhera while keeping the rest of the code unchanged? Can
> OzHera be used independently without Xiaomi/mono?
> > > >
> > > > On Tue, Sep 5, 2023, at 11:11, Yu Xiao wrote:
> > > > > Dear incubator community,
> > > > >
> > > > > I would like to propose OzHera[1] as a new apache incubator
> project, you
> > > > > can find the proposal[2] of OzHera for more detail.
> > > > >
> > > > > OzHera is an application performance observation platform that
> centers
> > > > > around applications,
> > > > > integrating metric monitoring, link tracing, logs, alerts, and
> other
> > > > > capabilities.
> > > > > The Hera platform has the following core features:
> > > > >
> > > > > ** Embrace Cloud Native
> > > > > Complies with the Opentracing standard, integrating multiple star
> > > > > open-source products such as OpenTelemetry,
> > > > > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera
> deeply
> > > > > adapts to K8S,
> > > > > providing one-click deployment on K8S through operator.
> > > > >
> > > > > ** Precise: Availability Metrics
> > > > > We have defined corresponding availability metrics for common RPC
> > > > > (Dubbo, HTTP, etc.) requests.
> > > > > These request-scope metrics are automatically extracted from
> tracing
> > > > > by Hera, and during extraction,
> > > > > we enhance the ability to recognize business error codes.
> > > > > A single metric can accurately express the exceptions encapsulated
> by
> > > > > RPC and business processing.
> > > > >
> > > > > ** Quick: Metrics-Tracing-Logging Linkage
> > > > > Based on traceId, it links the alarm -> metrics -> link -> log
> closed loop.
> > > > > From the moment the alarm card touches the user, the user can
> quickly
> > > > > view the link and log situation related to this alarm,
> > > > > greatly improving the efficiency of problem locating.
> > > > >
> > > > > ** Economical
> > > > > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > > > > OzHera achieves the recognition of abnormal calls (error span,
> > > > > abnormal business error codes,
> > > > > error logs, single span time exceeding 1 second, etc.) and ensures
> the
> > > > > storage of data for the entire call link of abnormal traces.
> > > > > For normal traces, we adopt a default random sampling strategy of
> one
> > > > > in ten thousand.
> > > > >
> > > > > ** Enterprise-level Observable Products
> > > > > Complete account, permission, application management mechanisms,
> > > > > allowing users to quickly implement within the enterprise and
> connect
> > > > > to the enterprise’s own account, application deployment system,
> etc.
> > > > > It can also quickly dock with enterprise office software to achieve
> > > > > alarm touch. Core links are well decoupled for rapid scaling,
> > > > > and for large volumes of tracing, we have implemented tail
> sampling strategies,
> > > > > able to support high qps, real-time observable demands of high
> > > > > timeliness systems.
> > > > >
> > > > > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > > > > [2]
> https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> > > > >
> > > > > Best,
> > > > > Yu Xiao
> > > > >
> > > > > ASF Member
> > > > > Apache ShenYu V.P.
> > > > > Apache Incubator PMC
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > >
> > > > --
> > > > Xuanwo
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> >
> >
> > --
> > Best wishes！
> > CalvinKirs
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[Sheng Wu <wu...@gmail.com>]

One more update.
With this project being noticed by this project, the parent project is
facing the challenge of copying from Ali Yunxiao, which is one of the
Aliyun commercial services.
Ref source in CN, https://github.com/XiaoMi/mone/issues/689, attaching
the screenshot in case of the owner deleted this issue.

The good thing is, that this is not the ASF and incubator issue, we
don't have an obligation to prove this is true or false.
But this is a validation of my feelings that this project was not
audited carefully, although one of them declared they are.


Sheng Wu 吴晟
Twitter, wusheng1108

Calvin Kirs <ki...@apache.org> 于2023年9月6日周三 20:15写道：
>
> Is this a (community) with only 38 issues?
> There are tons of commits from the community. How does the decision
> happen? ok, I saw this, relying on Gitter[1] with only 6 people and 8
> messages?
>
> pls forgive me, after reviewing your proposal
> I really don’t know how to describe it.
>
> [1]https://app.gitter.im/#/room/#monegrow_community:gitter.im
>
> On Wed, Sep 6, 2023 at 6:14 PM Zhiyong Zhang <go...@apache.org> wrote:
> >
> > Without Mone, OzHera can be used independently. Currently, in addition to Xiaomi, there are also some external manufacturers using or researching it. Mone is a larger collection within Xiaomi, and we are considering open sourcing all of it in the future (which includes cicd rpc, registration center, container management, stress testing system, API platform, gateway, tunnel governance, etc.)
> >
> > On 2023/09/05 17:45:24 Xuanwo wrote:
> > > Hi,
> > >
> > > Thanks for the interesting proposal first!
> > >
> > > I would like to understand the connection between Xiaomi/mone and OzHera. Will OzHera be transferred from Xiaomi/mono to apache/incubator-ozhera while keeping the rest of the code unchanged? Can OzHera be used independently without Xiaomi/mono?
> > >
> > > On Tue, Sep 5, 2023, at 11:11, Yu Xiao wrote:
> > > > Dear incubator community,
> > > >
> > > > I would like to propose OzHera[1] as a new apache incubator project, you
> > > > can find the proposal[2] of OzHera for more detail.
> > > >
> > > > OzHera is an application performance observation platform that centers
> > > > around applications,
> > > > integrating metric monitoring, link tracing, logs, alerts, and other
> > > > capabilities.
> > > > The Hera platform has the following core features:
> > > >
> > > > ** Embrace Cloud Native
> > > > Complies with the Opentracing standard, integrating multiple star
> > > > open-source products such as OpenTelemetry,
> > > > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> > > > adapts to K8S,
> > > > providing one-click deployment on K8S through operator.
> > > >
> > > > ** Precise: Availability Metrics
> > > > We have defined corresponding availability metrics for common RPC
> > > > (Dubbo, HTTP, etc.) requests.
> > > > These request-scope metrics are automatically extracted from tracing
> > > > by Hera, and during extraction,
> > > > we enhance the ability to recognize business error codes.
> > > > A single metric can accurately express the exceptions encapsulated by
> > > > RPC and business processing.
> > > >
> > > > ** Quick: Metrics-Tracing-Logging Linkage
> > > > Based on traceId, it links the alarm -> metrics -> link -> log closed loop.
> > > > From the moment the alarm card touches the user, the user can quickly
> > > > view the link and log situation related to this alarm,
> > > > greatly improving the efficiency of problem locating.
> > > >
> > > > ** Economical
> > > > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > > > OzHera achieves the recognition of abnormal calls (error span,
> > > > abnormal business error codes,
> > > > error logs, single span time exceeding 1 second, etc.) and ensures the
> > > > storage of data for the entire call link of abnormal traces.
> > > > For normal traces, we adopt a default random sampling strategy of one
> > > > in ten thousand.
> > > >
> > > > ** Enterprise-level Observable Products
> > > > Complete account, permission, application management mechanisms,
> > > > allowing users to quickly implement within the enterprise and connect
> > > > to the enterprise’s own account, application deployment system, etc.
> > > > It can also quickly dock with enterprise office software to achieve
> > > > alarm touch. Core links are well decoupled for rapid scaling,
> > > > and for large volumes of tracing, we have implemented tail sampling strategies,
> > > > able to support high qps, real-time observable demands of high
> > > > timeliness systems.
> > > >
> > > > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > > > [2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> > > >
> > > > Best,
> > > > Yu Xiao
> > > >
> > > > ASF Member
> > > > Apache ShenYu V.P.
> > > > Apache Incubator PMC
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > > --
> > > Xuanwo
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> --
> Best wishes！
> CalvinKirs
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

Re: [DISCUSS] Incubating Proposal for OzHera

[Calvin Kirs <ki...@apache.org>]

Is this a (community) with only 38 issues?
There are tons of commits from the community. How does the decision
happen? ok, I saw this, relying on Gitter[1] with only 6 people and 8
messages?

pls forgive me, after reviewing your proposal
I really don’t know how to describe it.

[1]https://app.gitter.im/#/room/#monegrow_community:gitter.im

On Wed, Sep 6, 2023 at 6:14 PM Zhiyong Zhang <go...@apache.org> wrote:
>
> Without Mone, OzHera can be used independently. Currently, in addition to Xiaomi, there are also some external manufacturers using or researching it. Mone is a larger collection within Xiaomi, and we are considering open sourcing all of it in the future (which includes cicd rpc, registration center, container management, stress testing system, API platform, gateway, tunnel governance, etc.)
>
> On 2023/09/05 17:45:24 Xuanwo wrote:
> > Hi,
> >
> > Thanks for the interesting proposal first!
> >
> > I would like to understand the connection between Xiaomi/mone and OzHera. Will OzHera be transferred from Xiaomi/mono to apache/incubator-ozhera while keeping the rest of the code unchanged? Can OzHera be used independently without Xiaomi/mono?
> >
> > On Tue, Sep 5, 2023, at 11:11, Yu Xiao wrote:
> > > Dear incubator community,
> > >
> > > I would like to propose OzHera[1] as a new apache incubator project, you
> > > can find the proposal[2] of OzHera for more detail.
> > >
> > > OzHera is an application performance observation platform that centers
> > > around applications,
> > > integrating metric monitoring, link tracing, logs, alerts, and other
> > > capabilities.
> > > The Hera platform has the following core features:
> > >
> > > ** Embrace Cloud Native
> > > Complies with the Opentracing standard, integrating multiple star
> > > open-source products such as OpenTelemetry,
> > > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> > > adapts to K8S,
> > > providing one-click deployment on K8S through operator.
> > >
> > > ** Precise: Availability Metrics
> > > We have defined corresponding availability metrics for common RPC
> > > (Dubbo, HTTP, etc.) requests.
> > > These request-scope metrics are automatically extracted from tracing
> > > by Hera, and during extraction,
> > > we enhance the ability to recognize business error codes.
> > > A single metric can accurately express the exceptions encapsulated by
> > > RPC and business processing.
> > >
> > > ** Quick: Metrics-Tracing-Logging Linkage
> > > Based on traceId, it links the alarm -> metrics -> link -> log closed loop.
> > > From the moment the alarm card touches the user, the user can quickly
> > > view the link and log situation related to this alarm,
> > > greatly improving the efficiency of problem locating.
> > >
> > > ** Economical
> > > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > > OzHera achieves the recognition of abnormal calls (error span,
> > > abnormal business error codes,
> > > error logs, single span time exceeding 1 second, etc.) and ensures the
> > > storage of data for the entire call link of abnormal traces.
> > > For normal traces, we adopt a default random sampling strategy of one
> > > in ten thousand.
> > >
> > > ** Enterprise-level Observable Products
> > > Complete account, permission, application management mechanisms,
> > > allowing users to quickly implement within the enterprise and connect
> > > to the enterprise’s own account, application deployment system, etc.
> > > It can also quickly dock with enterprise office software to achieve
> > > alarm touch. Core links are well decoupled for rapid scaling,
> > > and for large volumes of tracing, we have implemented tail sampling strategies,
> > > able to support high qps, real-time observable demands of high
> > > timeliness systems.
> > >
> > > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > > [2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> > >
> > > Best,
> > > Yu Xiao
> > >
> > > ASF Member
> > > Apache ShenYu V.P.
> > > Apache Incubator PMC
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> >
> > --
> > Xuanwo
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>


-- 
Best wishes！
CalvinKirs

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re:Re: [DISCUSS] Incubating Proposal for OzHera

[KimmKing <ki...@apache.org>]

Agree with David, the community is more important than the codes.




--

Kimm King(kimmking@apache.org/kimmking@163.com)
github&twitter: kimmking





At 2023-09-07 16:52:20, "David Zollo" <da...@gmail.com> wrote:
>After reading the comments and concerns, I went to check out this
>project[1]. I think this project is still in a very early stage and
>requires significant improvement. It would be beneficial to have these
>mentors guide the improvements, and learn some  open-source knowledge
>like the apache way,  and you'd better to establish a user community
>before entering the incubator.
>
>
>1, https://github.com/XiaoMi/mone
>
>
>Best Regards
>
>---------------
>David
>Linkedin: https://www.linkedin.com/in/davidzollo
>---------------
>
>On Thu, Sep 7, 2023 at 10:01 AM Zhiyong Zhang <go...@apache.org> wrote:
>>
>> Thank you very much for your suggestion, we will try to implement it today.
>>
>>
>>
>>
>>
>>
>>
>> On 2023/09/06 15:12:35 Xuanwo wrote:
>> > > Without Mone, OzHera can be used independently. Currently, in addition
>> > > to Xiaomi, there are also some external manufacturers using or
>> > > researching it. Mone is a larger collection within Xiaomi, and we are
>> > > considering open sourcing all of it in the future (which includes cicd
>> > > rpc, registration center, container management, stress testing system,
>> > > API platform, gateway, tunnel governance, etc.)
>> >
>> > Thank you for your response. I agree with @PsiACE's suggestion to separate the project first and running it as a community before starting the incubation jounary.
>> >
>> > We can use `git` to split the project while preserving all related history.
>> >
>> > Here is the command:
>> >
>> > ```shell
>> > git clone https://github.com/XiaoMi/mone OzHera
>> > git filter-repo --path ozhera-all
>> > ```
>> >
>> > This change will make the contribution history clearer and help checking the initial committers list.
>> >
>> > On Wed, Sep 6, 2023, at 18:13, Zhiyong Zhang wrote:
>> > > Without Mone, OzHera can be used independently. Currently, in addition
>> > > to Xiaomi, there are also some external manufacturers using or
>> > > researching it. Mone is a larger collection within Xiaomi, and we are
>> > > considering open sourcing all of it in the future (which includes cicd
>> > > rpc, registration center, container management, stress testing system,
>> > > API platform, gateway, tunnel governance, etc.)
>> > >
>> > > On 2023/09/05 17:45:24 Xuanwo wrote:
>> > >> Hi,
>> > >>
>> > >> Thanks for the interesting proposal first!
>> > >>
>> > >> I would like to understand the connection between Xiaomi/mone and OzHera. Will OzHera be transferred from Xiaomi/mono to apache/incubator-ozhera while keeping the rest of the code unchanged? Can OzHera be used independently without Xiaomi/mono?
>> > >>
>> > >> On Tue, Sep 5, 2023, at 11:11, Yu Xiao wrote:
>> > >> > Dear incubator community,
>> > >> >
>> > >> > I would like to propose OzHera[1] as a new apache incubator project, you
>> > >> > can find the proposal[2] of OzHera for more detail.
>> > >> >
>> > >> > OzHera is an application performance observation platform that centers
>> > >> > around applications,
>> > >> > integrating metric monitoring, link tracing, logs, alerts, and other
>> > >> > capabilities.
>> > >> > The Hera platform has the following core features:
>> > >> >
>> > >> > ** Embrace Cloud Native
>> > >> > Complies with the Opentracing standard, integrating multiple star
>> > >> > open-source products such as OpenTelemetry,
>> > >> > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
>> > >> > adapts to K8S,
>> > >> > providing one-click deployment on K8S through operator.
>> > >> >
>> > >> > ** Precise: Availability Metrics
>> > >> > We have defined corresponding availability metrics for common RPC
>> > >> > (Dubbo, HTTP, etc.) requests.
>> > >> > These request-scope metrics are automatically extracted from tracing
>> > >> > by Hera, and during extraction,
>> > >> > we enhance the ability to recognize business error codes.
>> > >> > A single metric can accurately express the exceptions encapsulated by
>> > >> > RPC and business processing.
>> > >> >
>> > >> > ** Quick: Metrics-Tracing-Logging Linkage
>> > >> > Based on traceId, it links the alarm -> metrics -> link -> log closed loop.
>> > >> > From the moment the alarm card touches the user, the user can quickly
>> > >> > view the link and log situation related to this alarm,
>> > >> > greatly improving the efficiency of problem locating.
>> > >> >
>> > >> > ** Economical
>> > >> > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
>> > >> > OzHera achieves the recognition of abnormal calls (error span,
>> > >> > abnormal business error codes,
>> > >> > error logs, single span time exceeding 1 second, etc.) and ensures the
>> > >> > storage of data for the entire call link of abnormal traces.
>> > >> > For normal traces, we adopt a default random sampling strategy of one
>> > >> > in ten thousand.
>> > >> >
>> > >> > ** Enterprise-level Observable Products
>> > >> > Complete account, permission, application management mechanisms,
>> > >> > allowing users to quickly implement within the enterprise and connect
>> > >> > to the enterprise’s own account, application deployment system, etc.
>> > >> > It can also quickly dock with enterprise office software to achieve
>> > >> > alarm touch. Core links are well decoupled for rapid scaling,
>> > >> > and for large volumes of tracing, we have implemented tail sampling strategies,
>> > >> > able to support high qps, real-time observable demands of high
>> > >> > timeliness systems.
>> > >> >
>> > >> > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
>> > >> > [2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
>> > >> >
>> > >> > Best,
>> > >> > Yu Xiao
>> > >> >
>> > >> > ASF Member
>> > >> > Apache ShenYu V.P.
>> > >> > Apache Incubator PMC
>> > >> >
>> > >> > ---------------------------------------------------------------------
>> > >> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > >> > For additional commands, e-mail: general-help@incubator.apache.org
>> > >>
>> > >> --
>> > >> Xuanwo
>> > >>
>> > >> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > >> For additional commands, e-mail: general-help@incubator.apache.org
>> > >>
>> > >>
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > > For additional commands, e-mail: general-help@incubator.apache.org
>> >
>> > --
>> > Xuanwo
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[David Zollo <da...@gmail.com>]

After reading the comments and concerns, I went to check out this
project[1]. I think this project is still in a very early stage and
requires significant improvement. It would be beneficial to have these
mentors guide the improvements, and learn some  open-source knowledge
like the apache way,  and you'd better to establish a user community
before entering the incubator.


1, https://github.com/XiaoMi/mone


Best Regards

---------------
David
Linkedin: https://www.linkedin.com/in/davidzollo
---------------

On Thu, Sep 7, 2023 at 10:01 AM Zhiyong Zhang <go...@apache.org> wrote:
>
> Thank you very much for your suggestion, we will try to implement it today.
>
>
>
>
>
>
>
> On 2023/09/06 15:12:35 Xuanwo wrote:
> > > Without Mone, OzHera can be used independently. Currently, in addition
> > > to Xiaomi, there are also some external manufacturers using or
> > > researching it. Mone is a larger collection within Xiaomi, and we are
> > > considering open sourcing all of it in the future (which includes cicd
> > > rpc, registration center, container management, stress testing system,
> > > API platform, gateway, tunnel governance, etc.)
> >
> > Thank you for your response. I agree with @PsiACE's suggestion to separate the project first and running it as a community before starting the incubation jounary.
> >
> > We can use `git` to split the project while preserving all related history.
> >
> > Here is the command:
> >
> > ```shell
> > git clone https://github.com/XiaoMi/mone OzHera
> > git filter-repo --path ozhera-all
> > ```
> >
> > This change will make the contribution history clearer and help checking the initial committers list.
> >
> > On Wed, Sep 6, 2023, at 18:13, Zhiyong Zhang wrote:
> > > Without Mone, OzHera can be used independently. Currently, in addition
> > > to Xiaomi, there are also some external manufacturers using or
> > > researching it. Mone is a larger collection within Xiaomi, and we are
> > > considering open sourcing all of it in the future (which includes cicd
> > > rpc, registration center, container management, stress testing system,
> > > API platform, gateway, tunnel governance, etc.)
> > >
> > > On 2023/09/05 17:45:24 Xuanwo wrote:
> > >> Hi,
> > >>
> > >> Thanks for the interesting proposal first!
> > >>
> > >> I would like to understand the connection between Xiaomi/mone and OzHera. Will OzHera be transferred from Xiaomi/mono to apache/incubator-ozhera while keeping the rest of the code unchanged? Can OzHera be used independently without Xiaomi/mono?
> > >>
> > >> On Tue, Sep 5, 2023, at 11:11, Yu Xiao wrote:
> > >> > Dear incubator community,
> > >> >
> > >> > I would like to propose OzHera[1] as a new apache incubator project, you
> > >> > can find the proposal[2] of OzHera for more detail.
> > >> >
> > >> > OzHera is an application performance observation platform that centers
> > >> > around applications,
> > >> > integrating metric monitoring, link tracing, logs, alerts, and other
> > >> > capabilities.
> > >> > The Hera platform has the following core features:
> > >> >
> > >> > ** Embrace Cloud Native
> > >> > Complies with the Opentracing standard, integrating multiple star
> > >> > open-source products such as OpenTelemetry,
> > >> > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> > >> > adapts to K8S,
> > >> > providing one-click deployment on K8S through operator.
> > >> >
> > >> > ** Precise: Availability Metrics
> > >> > We have defined corresponding availability metrics for common RPC
> > >> > (Dubbo, HTTP, etc.) requests.
> > >> > These request-scope metrics are automatically extracted from tracing
> > >> > by Hera, and during extraction,
> > >> > we enhance the ability to recognize business error codes.
> > >> > A single metric can accurately express the exceptions encapsulated by
> > >> > RPC and business processing.
> > >> >
> > >> > ** Quick: Metrics-Tracing-Logging Linkage
> > >> > Based on traceId, it links the alarm -> metrics -> link -> log closed loop.
> > >> > From the moment the alarm card touches the user, the user can quickly
> > >> > view the link and log situation related to this alarm,
> > >> > greatly improving the efficiency of problem locating.
> > >> >
> > >> > ** Economical
> > >> > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > >> > OzHera achieves the recognition of abnormal calls (error span,
> > >> > abnormal business error codes,
> > >> > error logs, single span time exceeding 1 second, etc.) and ensures the
> > >> > storage of data for the entire call link of abnormal traces.
> > >> > For normal traces, we adopt a default random sampling strategy of one
> > >> > in ten thousand.
> > >> >
> > >> > ** Enterprise-level Observable Products
> > >> > Complete account, permission, application management mechanisms,
> > >> > allowing users to quickly implement within the enterprise and connect
> > >> > to the enterprise’s own account, application deployment system, etc.
> > >> > It can also quickly dock with enterprise office software to achieve
> > >> > alarm touch. Core links are well decoupled for rapid scaling,
> > >> > and for large volumes of tracing, we have implemented tail sampling strategies,
> > >> > able to support high qps, real-time observable demands of high
> > >> > timeliness systems.
> > >> >
> > >> > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > >> > [2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> > >> >
> > >> > Best,
> > >> > Yu Xiao
> > >> >
> > >> > ASF Member
> > >> > Apache ShenYu V.P.
> > >> > Apache Incubator PMC
> > >> >
> > >> > ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > >> > For additional commands, e-mail: general-help@incubator.apache.org
> > >>
> > >> --
> > >> Xuanwo
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > >> For additional commands, e-mail: general-help@incubator.apache.org
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> >
> > --
> > Xuanwo
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[Zhiyong Zhang <go...@apache.org>]

Thank you very much for your suggestion, we will try to implement it today.







On 2023/09/06 15:12:35 Xuanwo wrote:
> > Without Mone, OzHera can be used independently. Currently, in addition 
> > to Xiaomi, there are also some external manufacturers using or 
> > researching it. Mone is a larger collection within Xiaomi, and we are 
> > considering open sourcing all of it in the future (which includes cicd 
> > rpc, registration center, container management, stress testing system, 
> > API platform, gateway, tunnel governance, etc.)
> 
> Thank you for your response. I agree with @PsiACE's suggestion to separate the project first and running it as a community before starting the incubation jounary.
> 
> We can use `git` to split the project while preserving all related history.
> 
> Here is the command: 
> 
> ```shell
> git clone https://github.com/XiaoMi/mone OzHera
> git filter-repo --path ozhera-all
> ```
> 
> This change will make the contribution history clearer and help checking the initial committers list.
> 
> On Wed, Sep 6, 2023, at 18:13, Zhiyong Zhang wrote:
> > Without Mone, OzHera can be used independently. Currently, in addition 
> > to Xiaomi, there are also some external manufacturers using or 
> > researching it. Mone is a larger collection within Xiaomi, and we are 
> > considering open sourcing all of it in the future (which includes cicd 
> > rpc, registration center, container management, stress testing system, 
> > API platform, gateway, tunnel governance, etc.)
> >
> > On 2023/09/05 17:45:24 Xuanwo wrote:
> >> Hi,
> >> 
> >> Thanks for the interesting proposal first!
> >> 
> >> I would like to understand the connection between Xiaomi/mone and OzHera. Will OzHera be transferred from Xiaomi/mono to apache/incubator-ozhera while keeping the rest of the code unchanged? Can OzHera be used independently without Xiaomi/mono?
> >> 
> >> On Tue, Sep 5, 2023, at 11:11, Yu Xiao wrote:
> >> > Dear incubator community,
> >> >
> >> > I would like to propose OzHera[1] as a new apache incubator project, you
> >> > can find the proposal[2] of OzHera for more detail.
> >> >
> >> > OzHera is an application performance observation platform that centers
> >> > around applications,
> >> > integrating metric monitoring, link tracing, logs, alerts, and other
> >> > capabilities.
> >> > The Hera platform has the following core features:
> >> >
> >> > ** Embrace Cloud Native
> >> > Complies with the Opentracing standard, integrating multiple star
> >> > open-source products such as OpenTelemetry,
> >> > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> >> > adapts to K8S,
> >> > providing one-click deployment on K8S through operator.
> >> >
> >> > ** Precise: Availability Metrics
> >> > We have defined corresponding availability metrics for common RPC
> >> > (Dubbo, HTTP, etc.) requests.
> >> > These request-scope metrics are automatically extracted from tracing
> >> > by Hera, and during extraction,
> >> > we enhance the ability to recognize business error codes.
> >> > A single metric can accurately express the exceptions encapsulated by
> >> > RPC and business processing.
> >> >
> >> > ** Quick: Metrics-Tracing-Logging Linkage
> >> > Based on traceId, it links the alarm -> metrics -> link -> log closed loop.
> >> > From the moment the alarm card touches the user, the user can quickly
> >> > view the link and log situation related to this alarm,
> >> > greatly improving the efficiency of problem locating.
> >> >
> >> > ** Economical
> >> > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> >> > OzHera achieves the recognition of abnormal calls (error span,
> >> > abnormal business error codes,
> >> > error logs, single span time exceeding 1 second, etc.) and ensures the
> >> > storage of data for the entire call link of abnormal traces.
> >> > For normal traces, we adopt a default random sampling strategy of one
> >> > in ten thousand.
> >> >
> >> > ** Enterprise-level Observable Products
> >> > Complete account, permission, application management mechanisms,
> >> > allowing users to quickly implement within the enterprise and connect
> >> > to the enterprise’s own account, application deployment system, etc.
> >> > It can also quickly dock with enterprise office software to achieve
> >> > alarm touch. Core links are well decoupled for rapid scaling,
> >> > and for large volumes of tracing, we have implemented tail sampling strategies,
> >> > able to support high qps, real-time observable demands of high
> >> > timeliness systems.
> >> >
> >> > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> >> > [2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> >> >
> >> > Best,
> >> > Yu Xiao
> >> >
> >> > ASF Member
> >> > Apache ShenYu V.P.
> >> > Apache Incubator PMC
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> > For additional commands, e-mail: general-help@incubator.apache.org
> >> 
> >> -- 
> >> Xuanwo
> >> 
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >> 
> >> 
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> 
> -- 
> Xuanwo
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[Xuanwo <xu...@apache.org>]

Correct my previous command:

```shell
git clone https://github.com/XiaoMi/mone OzHera
git filter-branch --subdirectory-filter ozhera-all -- --all
```

By the way, this repo seems can't clone now:

```shell
:) git clone https://github.com/XiaoMi/mone.git
Cloning into 'mone'...
remote: Enumerating objects: 45781, done.
remote: Counting objects: 100% (2958/2958), done.
remote: Compressing objects: 100% (1446/1446), done.
remote: Total 45781 (delta 923), reused 2617 (delta 786), pack-reused 42823
Receiving objects: 100% (45781/45781), 45.94 MiB | 5.35 MiB/s, done.
Resolving deltas: 100% (15670/15670), done.
Downloading ozhera-all/opentelemetry-java/examples/gradle/wrapper/gradle-wrapper.jar (59 KB)
Error downloading object: ozhera-all/opentelemetry-java/examples/gradle/wrapper/gradle-wrapper.jar (e996d45): Smudge error: Error downloading ozhera-all/opentelemetry-java/examples/gradle/wrapper/gradle-wrapper.jar (e996d452d2645e70c01c11143ca2d3742734a28da2bf61f25c82bdc288c9e637): batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
```

On Wed, Sep 6, 2023, at 23:12, Xuanwo wrote:
>> Without Mone, OzHera can be used independently. Currently, in addition 
>> to Xiaomi, there are also some external manufacturers using or 
>> researching it. Mone is a larger collection within Xiaomi, and we are 
>> considering open sourcing all of it in the future (which includes cicd 
>> rpc, registration center, container management, stress testing system, 
>> API platform, gateway, tunnel governance, etc.)
>
> Thank you for your response. I agree with @PsiACE's suggestion to 
> separate the project first and running it as a community before 
> starting the incubation jounary.
>
> We can use `git` to split the project while preserving all related history.
>
> Here is the command: 
>
> ```shell
> git clone https://github.com/XiaoMi/mone OzHera
> git filter-repo --path ozhera-all
> ```
>
> This change will make the contribution history clearer and help 
> checking the initial committers list.
>
> On Wed, Sep 6, 2023, at 18:13, Zhiyong Zhang wrote:
>> Without Mone, OzHera can be used independently. Currently, in addition 
>> to Xiaomi, there are also some external manufacturers using or 
>> researching it. Mone is a larger collection within Xiaomi, and we are 
>> considering open sourcing all of it in the future (which includes cicd 
>> rpc, registration center, container management, stress testing system, 
>> API platform, gateway, tunnel governance, etc.)
>>
>> On 2023/09/05 17:45:24 Xuanwo wrote:
>>> Hi,
>>> 
>>> Thanks for the interesting proposal first!
>>> 
>>> I would like to understand the connection between Xiaomi/mone and OzHera. Will OzHera be transferred from Xiaomi/mono to apache/incubator-ozhera while keeping the rest of the code unchanged? Can OzHera be used independently without Xiaomi/mono?
>>> 
>>> On Tue, Sep 5, 2023, at 11:11, Yu Xiao wrote:
>>> > Dear incubator community,
>>> >
>>> > I would like to propose OzHera[1] as a new apache incubator project, you
>>> > can find the proposal[2] of OzHera for more detail.
>>> >
>>> > OzHera is an application performance observation platform that centers
>>> > around applications,
>>> > integrating metric monitoring, link tracing, logs, alerts, and other
>>> > capabilities.
>>> > The Hera platform has the following core features:
>>> >
>>> > ** Embrace Cloud Native
>>> > Complies with the Opentracing standard, integrating multiple star
>>> > open-source products such as OpenTelemetry,
>>> > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
>>> > adapts to K8S,
>>> > providing one-click deployment on K8S through operator.
>>> >
>>> > ** Precise: Availability Metrics
>>> > We have defined corresponding availability metrics for common RPC
>>> > (Dubbo, HTTP, etc.) requests.
>>> > These request-scope metrics are automatically extracted from tracing
>>> > by Hera, and during extraction,
>>> > we enhance the ability to recognize business error codes.
>>> > A single metric can accurately express the exceptions encapsulated by
>>> > RPC and business processing.
>>> >
>>> > ** Quick: Metrics-Tracing-Logging Linkage
>>> > Based on traceId, it links the alarm -> metrics -> link -> log closed loop.
>>> > From the moment the alarm card touches the user, the user can quickly
>>> > view the link and log situation related to this alarm,
>>> > greatly improving the efficiency of problem locating.
>>> >
>>> > ** Economical
>>> > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
>>> > OzHera achieves the recognition of abnormal calls (error span,
>>> > abnormal business error codes,
>>> > error logs, single span time exceeding 1 second, etc.) and ensures the
>>> > storage of data for the entire call link of abnormal traces.
>>> > For normal traces, we adopt a default random sampling strategy of one
>>> > in ten thousand.
>>> >
>>> > ** Enterprise-level Observable Products
>>> > Complete account, permission, application management mechanisms,
>>> > allowing users to quickly implement within the enterprise and connect
>>> > to the enterprise’s own account, application deployment system, etc.
>>> > It can also quickly dock with enterprise office software to achieve
>>> > alarm touch. Core links are well decoupled for rapid scaling,
>>> > and for large volumes of tracing, we have implemented tail sampling strategies,
>>> > able to support high qps, real-time observable demands of high
>>> > timeliness systems.
>>> >
>>> > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
>>> > [2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
>>> >
>>> > Best,
>>> > Yu Xiao
>>> >
>>> > ASF Member
>>> > Apache ShenYu V.P.
>>> > Apache Incubator PMC
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> > For additional commands, e-mail: general-help@incubator.apache.org
>>> 
>>> -- 
>>> Xuanwo
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>> 
>>> 
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>
> -- 
> Xuanwo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org

-- 
Xuanwo

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[Xuanwo <xu...@apache.org>]

> Without Mone, OzHera can be used independently. Currently, in addition 
> to Xiaomi, there are also some external manufacturers using or 
> researching it. Mone is a larger collection within Xiaomi, and we are 
> considering open sourcing all of it in the future (which includes cicd 
> rpc, registration center, container management, stress testing system, 
> API platform, gateway, tunnel governance, etc.)

Thank you for your response. I agree with @PsiACE's suggestion to separate the project first and running it as a community before starting the incubation jounary.

We can use `git` to split the project while preserving all related history.

Here is the command: 

```shell
git clone https://github.com/XiaoMi/mone OzHera
git filter-repo --path ozhera-all
```

This change will make the contribution history clearer and help checking the initial committers list.

On Wed, Sep 6, 2023, at 18:13, Zhiyong Zhang wrote:
> Without Mone, OzHera can be used independently. Currently, in addition 
> to Xiaomi, there are also some external manufacturers using or 
> researching it. Mone is a larger collection within Xiaomi, and we are 
> considering open sourcing all of it in the future (which includes cicd 
> rpc, registration center, container management, stress testing system, 
> API platform, gateway, tunnel governance, etc.)
>
> On 2023/09/05 17:45:24 Xuanwo wrote:
>> Hi,
>> 
>> Thanks for the interesting proposal first!
>> 
>> I would like to understand the connection between Xiaomi/mone and OzHera. Will OzHera be transferred from Xiaomi/mono to apache/incubator-ozhera while keeping the rest of the code unchanged? Can OzHera be used independently without Xiaomi/mono?
>> 
>> On Tue, Sep 5, 2023, at 11:11, Yu Xiao wrote:
>> > Dear incubator community,
>> >
>> > I would like to propose OzHera[1] as a new apache incubator project, you
>> > can find the proposal[2] of OzHera for more detail.
>> >
>> > OzHera is an application performance observation platform that centers
>> > around applications,
>> > integrating metric monitoring, link tracing, logs, alerts, and other
>> > capabilities.
>> > The Hera platform has the following core features:
>> >
>> > ** Embrace Cloud Native
>> > Complies with the Opentracing standard, integrating multiple star
>> > open-source products such as OpenTelemetry,
>> > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
>> > adapts to K8S,
>> > providing one-click deployment on K8S through operator.
>> >
>> > ** Precise: Availability Metrics
>> > We have defined corresponding availability metrics for common RPC
>> > (Dubbo, HTTP, etc.) requests.
>> > These request-scope metrics are automatically extracted from tracing
>> > by Hera, and during extraction,
>> > we enhance the ability to recognize business error codes.
>> > A single metric can accurately express the exceptions encapsulated by
>> > RPC and business processing.
>> >
>> > ** Quick: Metrics-Tracing-Logging Linkage
>> > Based on traceId, it links the alarm -> metrics -> link -> log closed loop.
>> > From the moment the alarm card touches the user, the user can quickly
>> > view the link and log situation related to this alarm,
>> > greatly improving the efficiency of problem locating.
>> >
>> > ** Economical
>> > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
>> > OzHera achieves the recognition of abnormal calls (error span,
>> > abnormal business error codes,
>> > error logs, single span time exceeding 1 second, etc.) and ensures the
>> > storage of data for the entire call link of abnormal traces.
>> > For normal traces, we adopt a default random sampling strategy of one
>> > in ten thousand.
>> >
>> > ** Enterprise-level Observable Products
>> > Complete account, permission, application management mechanisms,
>> > allowing users to quickly implement within the enterprise and connect
>> > to the enterprise’s own account, application deployment system, etc.
>> > It can also quickly dock with enterprise office software to achieve
>> > alarm touch. Core links are well decoupled for rapid scaling,
>> > and for large volumes of tracing, we have implemented tail sampling strategies,
>> > able to support high qps, real-time observable demands of high
>> > timeliness systems.
>> >
>> > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
>> > [2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
>> >
>> > Best,
>> > Yu Xiao
>> >
>> > ASF Member
>> > Apache ShenYu V.P.
>> > Apache Incubator PMC
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: general-help@incubator.apache.org
>> 
>> -- 
>> Xuanwo
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>> 
>> 
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org

-- 
Xuanwo

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[Zhiyong Zhang <go...@apache.org>]

Without Mone, OzHera can be used independently. Currently, in addition to Xiaomi, there are also some external manufacturers using or researching it. Mone is a larger collection within Xiaomi, and we are considering open sourcing all of it in the future (which includes cicd rpc, registration center, container management, stress testing system, API platform, gateway, tunnel governance, etc.)

On 2023/09/05 17:45:24 Xuanwo wrote:
> Hi,
> 
> Thanks for the interesting proposal first!
> 
> I would like to understand the connection between Xiaomi/mone and OzHera. Will OzHera be transferred from Xiaomi/mono to apache/incubator-ozhera while keeping the rest of the code unchanged? Can OzHera be used independently without Xiaomi/mono?
> 
> On Tue, Sep 5, 2023, at 11:11, Yu Xiao wrote:
> > Dear incubator community,
> >
> > I would like to propose OzHera[1] as a new apache incubator project, you
> > can find the proposal[2] of OzHera for more detail.
> >
> > OzHera is an application performance observation platform that centers
> > around applications,
> > integrating metric monitoring, link tracing, logs, alerts, and other
> > capabilities.
> > The Hera platform has the following core features:
> >
> > ** Embrace Cloud Native
> > Complies with the Opentracing standard, integrating multiple star
> > open-source products such as OpenTelemetry,
> > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> > adapts to K8S,
> > providing one-click deployment on K8S through operator.
> >
> > ** Precise: Availability Metrics
> > We have defined corresponding availability metrics for common RPC
> > (Dubbo, HTTP, etc.) requests.
> > These request-scope metrics are automatically extracted from tracing
> > by Hera, and during extraction,
> > we enhance the ability to recognize business error codes.
> > A single metric can accurately express the exceptions encapsulated by
> > RPC and business processing.
> >
> > ** Quick: Metrics-Tracing-Logging Linkage
> > Based on traceId, it links the alarm -> metrics -> link -> log closed loop.
> > From the moment the alarm card touches the user, the user can quickly
> > view the link and log situation related to this alarm,
> > greatly improving the efficiency of problem locating.
> >
> > ** Economical
> > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > OzHera achieves the recognition of abnormal calls (error span,
> > abnormal business error codes,
> > error logs, single span time exceeding 1 second, etc.) and ensures the
> > storage of data for the entire call link of abnormal traces.
> > For normal traces, we adopt a default random sampling strategy of one
> > in ten thousand.
> >
> > ** Enterprise-level Observable Products
> > Complete account, permission, application management mechanisms,
> > allowing users to quickly implement within the enterprise and connect
> > to the enterprise’s own account, application deployment system, etc.
> > It can also quickly dock with enterprise office software to achieve
> > alarm touch. Core links are well decoupled for rapid scaling,
> > and for large volumes of tracing, we have implemented tail sampling strategies,
> > able to support high qps, real-time observable demands of high
> > timeliness systems.
> >
> > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > [2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> >
> > Best,
> > Yu Xiao
> >
> > ASF Member
> > Apache ShenYu V.P.
> > Apache Incubator PMC
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> 
> -- 
> Xuanwo
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[Yu Xiao <xi...@apache.org>]

HI tison，

This may be the description of the problem where the mentor is
volunteering to help with the project .
The understanding of the task here is that the mentor suggests some
practices the Apache Way!


> So I wonder what the "clear division of labor among the mentors" is - which
mentor covers what division? And how you previously assigned tasks to the
initial committers and what the tasks are.

Best wishes!

tison <wa...@gmail.com> 于2023年9月6日周三 07:31写道：
>
> Hi,
>
> >> This sounds interesting. Could you elaborate on the "division of labor"
> and
> >> previous tasks "assigned" by mentors to initial committers?
>
> > It should be clarified that mentors are there to help projects better
> > practice the Apache Way,
> > including project releases, license checks, community builds, etc.
>
> This is aligned with my understanding and is clear. My question is the
> description of "division of labor" and "tasks assigned".
>
> Do you mean these descriptions are inaccurate, or how do you practice them?
>
> The original description is:
>
> > There is a relatively clear division of labor among the mentors, and the
> mentors will regularly assign us corresponding tasks.
>
> So I wonder what the "clear division of labor among the mentors" is - which
> mentor covers what division? And how you previously assigned tasks to the
> initial committers and what the tasks are.
>
> Best,
> tison.
>
>
> Xuanwo <xu...@apache.org> 于2023年9月6日周三 01:45写道：
>
> > Hi,
> >
> > Thanks for the interesting proposal first!
> >
> > I would like to understand the connection between Xiaomi/mone and OzHera.
> > Will OzHera be transferred from Xiaomi/mono to apache/incubator-ozhera
> > while keeping the rest of the code unchanged? Can OzHera be used
> > independently without Xiaomi/mono?
> >
> > On Tue, Sep 5, 2023, at 11:11, Yu Xiao wrote:
> > > Dear incubator community,
> > >
> > > I would like to propose OzHera[1] as a new apache incubator project, you
> > > can find the proposal[2] of OzHera for more detail.
> > >
> > > OzHera is an application performance observation platform that centers
> > > around applications,
> > > integrating metric monitoring, link tracing, logs, alerts, and other
> > > capabilities.
> > > The Hera platform has the following core features:
> > >
> > > ** Embrace Cloud Native
> > > Complies with the Opentracing standard, integrating multiple star
> > > open-source products such as OpenTelemetry,
> > > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> > > adapts to K8S,
> > > providing one-click deployment on K8S through operator.
> > >
> > > ** Precise: Availability Metrics
> > > We have defined corresponding availability metrics for common RPC
> > > (Dubbo, HTTP, etc.) requests.
> > > These request-scope metrics are automatically extracted from tracing
> > > by Hera, and during extraction,
> > > we enhance the ability to recognize business error codes.
> > > A single metric can accurately express the exceptions encapsulated by
> > > RPC and business processing.
> > >
> > > ** Quick: Metrics-Tracing-Logging Linkage
> > > Based on traceId, it links the alarm -> metrics -> link -> log closed
> > loop.
> > > From the moment the alarm card touches the user, the user can quickly
> > > view the link and log situation related to this alarm,
> > > greatly improving the efficiency of problem locating.
> > >
> > > ** Economical
> > > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > > OzHera achieves the recognition of abnormal calls (error span,
> > > abnormal business error codes,
> > > error logs, single span time exceeding 1 second, etc.) and ensures the
> > > storage of data for the entire call link of abnormal traces.
> > > For normal traces, we adopt a default random sampling strategy of one
> > > in ten thousand.
> > >
> > > ** Enterprise-level Observable Products
> > > Complete account, permission, application management mechanisms,
> > > allowing users to quickly implement within the enterprise and connect
> > > to the enterprise’s own account, application deployment system, etc.
> > > It can also quickly dock with enterprise office software to achieve
> > > alarm touch. Core links are well decoupled for rapid scaling,
> > > and for large volumes of tracing, we have implemented tail sampling
> > strategies,
> > > able to support high qps, real-time observable demands of high
> > > timeliness systems.
> > >
> > > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > > [2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> > >
> > > Best,
> > > Yu Xiao
> > >
> > > ASF Member
> > > Apache ShenYu V.P.
> > > Apache Incubator PMC
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> >
> > --
> > Xuanwo
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[tison <wa...@gmail.com>]

Hi,

>> This sounds interesting. Could you elaborate on the "division of labor"
and
>> previous tasks "assigned" by mentors to initial committers?

> It should be clarified that mentors are there to help projects better
> practice the Apache Way,
> including project releases, license checks, community builds, etc.

This is aligned with my understanding and is clear. My question is the
description of "division of labor" and "tasks assigned".

Do you mean these descriptions are inaccurate, or how do you practice them?

The original description is:

> There is a relatively clear division of labor among the mentors, and the
mentors will regularly assign us corresponding tasks.

So I wonder what the "clear division of labor among the mentors" is - which
mentor covers what division? And how you previously assigned tasks to the
initial committers and what the tasks are.

Best,
tison.


Xuanwo <xu...@apache.org> 于2023年9月6日周三 01:45写道：

> Hi,
>
> Thanks for the interesting proposal first!
>
> I would like to understand the connection between Xiaomi/mone and OzHera.
> Will OzHera be transferred from Xiaomi/mono to apache/incubator-ozhera
> while keeping the rest of the code unchanged? Can OzHera be used
> independently without Xiaomi/mono?
>
> On Tue, Sep 5, 2023, at 11:11, Yu Xiao wrote:
> > Dear incubator community,
> >
> > I would like to propose OzHera[1] as a new apache incubator project, you
> > can find the proposal[2] of OzHera for more detail.
> >
> > OzHera is an application performance observation platform that centers
> > around applications,
> > integrating metric monitoring, link tracing, logs, alerts, and other
> > capabilities.
> > The Hera platform has the following core features:
> >
> > ** Embrace Cloud Native
> > Complies with the Opentracing standard, integrating multiple star
> > open-source products such as OpenTelemetry,
> > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> > adapts to K8S,
> > providing one-click deployment on K8S through operator.
> >
> > ** Precise: Availability Metrics
> > We have defined corresponding availability metrics for common RPC
> > (Dubbo, HTTP, etc.) requests.
> > These request-scope metrics are automatically extracted from tracing
> > by Hera, and during extraction,
> > we enhance the ability to recognize business error codes.
> > A single metric can accurately express the exceptions encapsulated by
> > RPC and business processing.
> >
> > ** Quick: Metrics-Tracing-Logging Linkage
> > Based on traceId, it links the alarm -> metrics -> link -> log closed
> loop.
> > From the moment the alarm card touches the user, the user can quickly
> > view the link and log situation related to this alarm,
> > greatly improving the efficiency of problem locating.
> >
> > ** Economical
> > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > OzHera achieves the recognition of abnormal calls (error span,
> > abnormal business error codes,
> > error logs, single span time exceeding 1 second, etc.) and ensures the
> > storage of data for the entire call link of abnormal traces.
> > For normal traces, we adopt a default random sampling strategy of one
> > in ten thousand.
> >
> > ** Enterprise-level Observable Products
> > Complete account, permission, application management mechanisms,
> > allowing users to quickly implement within the enterprise and connect
> > to the enterprise’s own account, application deployment system, etc.
> > It can also quickly dock with enterprise office software to achieve
> > alarm touch. Core links are well decoupled for rapid scaling,
> > and for large volumes of tracing, we have implemented tail sampling
> strategies,
> > able to support high qps, real-time observable demands of high
> > timeliness systems.
> >
> > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > [2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> >
> > Best,
> > Yu Xiao
> >
> > ASF Member
> > Apache ShenYu V.P.
> > Apache Incubator PMC
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
>
> --
> Xuanwo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: [DISCUSS] Incubating Proposal for OzHera

[Xuanwo <xu...@apache.org>]

Hi,

Thanks for the interesting proposal first!

I would like to understand the connection between Xiaomi/mone and OzHera. Will OzHera be transferred from Xiaomi/mono to apache/incubator-ozhera while keeping the rest of the code unchanged? Can OzHera be used independently without Xiaomi/mono?

On Tue, Sep 5, 2023, at 11:11, Yu Xiao wrote:
> Dear incubator community,
>
> I would like to propose OzHera[1] as a new apache incubator project, you
> can find the proposal[2] of OzHera for more detail.
>
> OzHera is an application performance observation platform that centers
> around applications,
> integrating metric monitoring, link tracing, logs, alerts, and other
> capabilities.
> The Hera platform has the following core features:
>
> ** Embrace Cloud Native
> Complies with the Opentracing standard, integrating multiple star
> open-source products such as OpenTelemetry,
> Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> adapts to K8S,
> providing one-click deployment on K8S through operator.
>
> ** Precise: Availability Metrics
> We have defined corresponding availability metrics for common RPC
> (Dubbo, HTTP, etc.) requests.
> These request-scope metrics are automatically extracted from tracing
> by Hera, and during extraction,
> we enhance the ability to recognize business error codes.
> A single metric can accurately express the exceptions encapsulated by
> RPC and business processing.
>
> ** Quick: Metrics-Tracing-Logging Linkage
> Based on traceId, it links the alarm -> metrics -> link -> log closed loop.
> From the moment the alarm card touches the user, the user can quickly
> view the link and log situation related to this alarm,
> greatly improving the efficiency of problem locating.
>
> ** Economical
> Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> OzHera achieves the recognition of abnormal calls (error span,
> abnormal business error codes,
> error logs, single span time exceeding 1 second, etc.) and ensures the
> storage of data for the entire call link of abnormal traces.
> For normal traces, we adopt a default random sampling strategy of one
> in ten thousand.
>
> ** Enterprise-level Observable Products
> Complete account, permission, application management mechanisms,
> allowing users to quickly implement within the enterprise and connect
> to the enterprise’s own account, application deployment system, etc.
> It can also quickly dock with enterprise office software to achieve
> alarm touch. Core links are well decoupled for rapid scaling,
> and for large volumes of tracing, we have implemented tail sampling strategies,
> able to support high qps, real-time observable demands of high
> timeliness systems.
>
> [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> [2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
>
> Best,
> Yu Xiao
>
> ASF Member
> Apache ShenYu V.P.
> Apache Incubator PMC
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org

-- 
Xuanwo

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[kezhenxu94 <ke...@apache.org>]

This is a really interesting project that I have some experience on it and want to leave some comments.

## Put on my IPMC member hat

- About the community.

You said there are some external manufacturers using or researching it, I saw there are 3 in the GitHub readme, one of which is Xiaomi itself. And because the users are logged in the main page, I want to know which part of the repo do they use? Do they use the OzHera or do they use the other parts such as CI/CD in the repo? My further question is, if the OzHera is extracted from the repo, are the users still interested in using it or prefer to use the original repo since it has more components?

- About the contributors.

There are totally 12 contributors in the ozhera-all folder, which is also the target folder that you want to donate to incubator, half of them are employees of Xiaomi, the other half are unknown, maybe there are more from Xiaomi, is there really a community that is interested in the project if they are not hired to develop the project?


    17  oujinliang <ou...@gmail.com>                           Xiaomi, from the GitHub profile
    14  shanwb <sh...@xiaomi.com>                             Xiaomi, from the commit author's email
    12  EricDing <12...@users.noreply.github.com>
    10  shanwb <sh...@sina.cn>
     6  gaoxihui <ga...@xiaomi.com>                              Xiaomi, from the commit author's email
     7  wtt <11...@qq.com>
     3  张校炜 <zh...@xiaomi.com>                            Xiaomi, from the commit author's email
     2  caobaoyu <ca...@xiaomi.com>                              Xiaomi, from the commit author's email
     2  wodiwudi <40...@users.noreply.github.com>
     1  Hobo <43...@users.noreply.github.com>       Xiaomi, from the GitHub profile
     1  kongniancp <ch...@163.com>
     1  rikaaa0928 <w1...@gmail.com>

- About the initial committers.

As I said, there are 12 contributors in the target folder, but some of them are not in the 12 committers, can you elaborate why is the case? After all, I don't think a contributor who contributes to the other parts (say A) of the project, can be a initial committer of another part (say B), unless you can explain, what did they contribute to the project.

Overall, I feel like this project is in a very early stage where it haven't gain enough users or contributors to start a journey in ASF incubator.

## Put on my ex-Alibaba employee hat

The parent project of the proposed project, called Mone, is a copy of Alibaba Aone, especially the CI/CD subproject, the entire user interface is exactly the same as Alibaba's Flow product when I worked for Flow at Alibaba, although now the UI of Flow has changed a little bit, they look still resemble very much. I was shocked when I saw the screenshots and feel terrible for the plagiarism. I am in doubt whether the OzHera has similar issues and whether the project is properly audited by Xiaomi's legal team.

Just right when I'm composing this email, I saw the reply[1] from the team to my ex-colleague's doubt in copying their product, the team doesn't admit it's copy when the UI is exactly the same, now I don't think the team has a good understanding of branding or copyright, I'm pessimistic whether they can deal with the branding issues in ASF.

https://github.com/XiaoMi/mone/issues/689#issuecomment-1708439445

I'm really frustrated by the team and their attitude towards their violating copyright.

> On Sep 5, 2023, at 11:11, Yu Xiao <xi...@apache.org> wrote:
> 
> Dear incubator community,
> 
> I would like to propose OzHera[1] as a new apache incubator project, you
> can find the proposal[2] of OzHera for more detail.
> 
> OzHera is an application performance observation platform that centers
> around applications,
> integrating metric monitoring, link tracing, logs, alerts, and other
> capabilities.
> The Hera platform has the following core features:
> 
> ** Embrace Cloud Native
> Complies with the Opentracing standard, integrating multiple star
> open-source products such as OpenTelemetry,
> Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> adapts to K8S,
> providing one-click deployment on K8S through operator.
> 
> ** Precise: Availability Metrics
> We have defined corresponding availability metrics for common RPC
> (Dubbo, HTTP, etc.) requests.
> These request-scope metrics are automatically extracted from tracing
> by Hera, and during extraction,
> we enhance the ability to recognize business error codes.
> A single metric can accurately express the exceptions encapsulated by
> RPC and business processing.
> 
> ** Quick: Metrics-Tracing-Logging Linkage
> Based on traceId, it links the alarm -> metrics -> link -> log closed loop.
> From the moment the alarm card touches the user, the user can quickly
> view the link and log situation related to this alarm,
> greatly improving the efficiency of problem locating.
> 
> ** Economical
> Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> OzHera achieves the recognition of abnormal calls (error span,
> abnormal business error codes,
> error logs, single span time exceeding 1 second, etc.) and ensures the
> storage of data for the entire call link of abnormal traces.
> For normal traces, we adopt a default random sampling strategy of one
> in ten thousand.
> 
> ** Enterprise-level Observable Products
> Complete account, permission, application management mechanisms,
> allowing users to quickly implement within the enterprise and connect
> to the enterprise’s own account, application deployment system, etc.
> It can also quickly dock with enterprise office software to achieve
> alarm touch. Core links are well decoupled for rapid scaling,
> and for large volumes of tracing, we have implemented tail sampling strategies,
> able to support high qps, real-time observable demands of high
> timeliness systems.
> 
> [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> [2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> 
> Best,
> Yu Xiao
> 
> ASF Member
> Apache ShenYu V.P.
> Apache Incubator PMC
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[Sheng Wu <wu...@gmail.com>]

I want to offinally feedback, if this proposal goes to the vote process, I
will give my -1 binding considering

1. Project is too early, no init community to prove the project will work.
2. Don't have enough knowledge about open source relative legal affairs.
3. Mostly Chinese involved, it seems to aim on local users only.

I will only expect to re-evaluate the community status one and two years
later. They should not hurry on this.


Sheng Wu 吴晟
tison <wa...@gmail.com>于2023年9月6日 周三16:01写道：

> FWIW I rejected an incubator proposal before they submitted it formally in
> the past weeks with the suggestion to run an open-source community first as
> Sheng & Ming suggested above.
>
> This is never permanent. And often, a healthy project takes a few months to
> determine whether entering the incubator is a good idea. All the projects I
> mentored (Kvrocks, StreamPark, and OpenDAL) have been running a community
> for one to two years outside the incubator.
>
> Be aware that it's not a hard requirement, but the understanding of
> "entering the incubator" is the concern.
>
> > There is no magic in the Apache incubator. Don't expect the incubator
> will make your project international and successful
>
> I read this sentence as a reply to the following understanding:
>
> >> The user interface currently only has Chinese, and the
> internationalization of the page requires a longer time to iterate, but we
> will complete the transformation of this function in the early stage of
> incubation;
> >> We have checked in advance, and we hope to do the replacement and
> upgrade during the future incubation period.
> >>> Our project is open and is willing to cooperate with the Apache
> Incubator community, mentors, and other relevant parties to resolve
> potential license issues.
>
> The mission of Incubator is[1]:
>
> > It helps those incoming projects (called "podlings") adopt the Apache
> style of governance and operation and guides them to the ASF services
> available to our projects so they can become top-level ASF projects
> ("TLPs").
>
> ... and according to the answer of "Does our project fit the Apache
> Incubator?"[2]:
>
> > To give our "podlings" (incubating projects) the best chances of success,
> we usually ask them to enter the Incubator with at least the start of a
> community built around an existing codebase.
>
> So the Incubator doesn't help in "create" the community, but help in shape
> the community following the Apache style of governance and operation.
>
> Best,
> tison.
>
> [1] https://incubator.apache.org/
> [2]
>
> https://incubator.apache.org/cookbook/#does_our_project_fit_the_apache_incubator
>
>
> Ming Wen <we...@apache.org> 于2023年9月6日周三 14:55写道：
>
> > After reading these responses, I feel that this project is not ready to
> > enter the Apache Incubator, especially considering that you have received
> > support from 6 mentors and communicated with them.
> > There is no magic in the Apache incubator. Don't expect the incubator
> will
> > make your project international and successful. For example, I noticed
> the
> > issues were all in Chinese, and no one reviewed PRs before merged.
> >
> > Thanks,
> > Ming Wen, Apache APISIX PMC Chair
> > Twitter: _WenMing
> >
> >
> > Zhiyong Zhang <go...@apache.org> 于2023年9月5日周二 22:33写道：
> >
> > >
> > >
> > > On 2023/09/05 05:56:51 Sheng Wu wrote:
> > > > Several important things
> > >
> > > The entire project https://github.com/XiaoMi/mone has passed the
> > internal
> > > audit of Xiaomi, and the owners and leaders of the entire project are
> > > consistent with the initiators of the ozhera project. The main donation
> > to
> > > ASF this time is ozhera-all, and other modules follow the Apache
> > protocol,
> > > which will not cause protocol or ownership ambiguity.
> > > > 1. You are mentioning the donation is about
> > > > `https://github.com/XiaoMi/mone/tree/master/ozhera-all`
> <https://github.com/XiaoMi/mone/tree/master/ozhera-all>
> > <https://github.com/XiaoMi/mone/tree/master/ozhera-all>
> > > <https://github.com/XiaoMi/mone/tree/master/ozhera-all>, It is a part
> > > > of the repository, so will others stay out of the ASF? If so, have
> the
> > > > project been going through Xiaomi's internal audit about the sharing
> > > > codes between this part of the whole project? Who owns that?
> > >
> > > We hope to complete the internationalization transformation with the
> help
> > > of ASF; we are preparing the English documents, and a version will be
> > > completed by tomorrow;
> > > > 2. I can't see any English document for the project. Is the community
> > > > for a global foundation incubating journey?
> > >
> > > The user interface currently only has Chinese, and the
> > > internationalization of the page requires a longer time to iterate, but
> > we
> > > will complete the transformation of this function in the early stage of
> > > incubation;
> > > > 3. More importantly, all screenshots and UIs are only in Chinese as
> > well?
> > >
> > > a.We have received full support from Xiaomi's legal affairs and are
> able
> > > to submit the SGA;
> > > b.The project has gradually recruited partners outside of Xiaomi, and
> the
> > > initial committers from Xiaomi are also actively participating in the
> > > construction of other open source communities. These are a group of
> > > partners who are passionate about open source. I believe that this
> group
> > of
> > > partners can continue the project in the long term.
> > > > 4. Have Xiaomi Inc. agreed on this? Will they submit a SGA? Are the
> > > > initial committers still working on Xiaomi and going to continue work
> > > > this project? Will Xiaomi permit their CCLAs?
> > >
> > > We have checked in advance, and we hope to do the replacement and
> upgrade
> > > during the future incubation period.
> > > > 5. I can see several incompatible licenses of dependencies existing,
> > > > including GPLs. Do you have plans to remove or replace them? Have you
> > > > worked with your mentors to go through licenses of dependencies
> check?
> > >
> > > There is a relatively clear division of labor among the mentors, and
> the
> > > mentors will regularly assign us corresponding tasks. Through efficient
> > > project collaboration, we ensure the activity of the community;
> > > At the same time, we can gain more experience and guidance from
> multiple
> > > mentors, which will further promote the positive cycle development of
> the
> > > community.
> > > > 6. Why a 10 people PPMC initial team has a mentor team of 6 people?
> > > > Typically, I don't think this is a good practice. Instead, mentors
> are
> > > > most likely counting on others and will become inactive.
> > >
> > > I hope that ozhera can play its value in the observability of
> > cloud-native
> > > applications. Many components in ozhera (Opentelemetry, Grafana,
> > > Prometheus, MQ, etc.) come from the open source community. We hope to
> > feed
> > > back our experience in the field of application observation to the
> > > community through this platform. The UI design will actively embrace
> open
> > > source like the backend, but we hope to implement mature solutions from
> > the
> > > community for chart display, currently it is Grafana.
> > > > 7. How would you process the branding? Including you are sharing UI
> > > > design. I have concerns this would be another issues with the main
> > > > project.
> > >
> > > a. We have chosen MySQL and Elasticsearch as the project's storage
> > > solutions based on their excellent performance in their respective
> > fields.
> > > The versions we have chosen strictly comply with the GPL and Apache2.0
> > > agreements.
> > > b. While Elasticsearch has changed from Apache 2.0 to the Server Side
> > > Public License (SSPL), although SSPL is no longer an OSI-approved open
> > > source license, it still allows free use, modification, and
> distribution,
> > > but imposes some restrictions on commercial use.
> > > c. We are also working on storage design. In the future, we will
> abstract
> > > a complete storage layer interface to decouple the code logic from the
> > > specific storage implementation. This facilitates integrating more
> > > alternative storage solutions. Our project is open and is willing to
> > > cooperate with the Apache Incubator community, mentors, and other
> > relevant
> > > parties to resolve potential license issues.
> > > > 8. You are using MySQL and ElasticSearch as storage. The one is on
> GPL
> > > > and the other is not longer OSI-approved license anymore. What is
> your
> > > > plan on that?
> > >
> > > Firstly, SkyWalking is an excellent open source APM, with comprehensive
> > > capabilities in tracing, real-time topology, and multi-language
> > adaptation.
> > > The starting point for creating OzHera is to build an enterprise-level
> > > observability platform for the cloud-native era that truly solves the
> > > problem of discovering business issues within 1 minute and locating
> them
> > > within 5 minutes.
> > > Its core features include:
> > > a. Embracing Cloud-native
> > > It adheres to the Opentracing standard and integrates several renowned
> > > open-source products including Opentelemetry, Grafana, Prometheus, and
> > ES.
> > > Hera also deeply adapts to K8S and provides one-click deployment
> > capability
> > > based on K8S.
> > > b. Accuracy: Availability metrics
> > > Too many alerts essentially equate to ineffective alerts, making the
> > > accuracy of alerts particularly important. No one understands the
> > > correctness of requests better than their own business error codes. We
> > > incorporate the ability to recognize business error codes into the
> > business
> > > availability metrics, allowing business alerts to focus on just this
> one
> > > indicator. At the same time, we are also expanding SLA metrics to view
> > the
> > > availability of server services from the client's perspective.
> > > c. Excellent Linkage: Metrics-Tracing-Logging linkage
> > > Based on the traceId, we establish a closed-loop linkage of
> > > alarm->indicator->link->log, significantly improving user efficiency in
> > > pinpointing issues.
> > > d. Economical: <0.1% storage cost, satisfying 99.9% of tracing demands
> > > We judge the importance of traces (exceptional span, single span calls
> > > exceeding 1s, error log output, business exception error codes, etc.).
> > Any
> > > trace identified as important is fully retained, while the remaining
> > normal
> > > traces are sampled to ensure efficiency while considering economic
> costs.
> > > e. Enterprise-level Observable Product
> > > Complete tenant permissions and application management mechanisms make
> it
> > > easy for users to quickly deploy and integrate their own accounts,
> CI/CD
> > > systems, etc., within the enterprise. It can also quickly connect to
> > > enterprise office software to achieve alert delivery;
> > > Within Xiaomi, it handles over 100T of data daily in a smooth and
> > > efficient manner;
> > > The core link is well decoupled to facilitate rapid scaling at each
> > stage.
> > > For large volumes of tracing, we have implemented head and tail
> sampling
> > to
> > > ensure the platform's cost-effectiveness.
> > > > 9 What are the differences between you and SkyWalking? What is this
> > > > new project bringing new to the users? Notice, this is a not a
> > > > rejection for a similar project, but, if they are nearly same, you
> > > > will face competitions in the same foundation but already have larger
> > > > community.
> > > >
> > > > Sheng Wu 吴晟
> > > > Twitter, wusheng1108
> > > >
> > > > Yu Xiao <xi...@apache.org> 于2023年9月5日周二 11:12写道：
> > > > >
> > > > > Dear incubator community,
> > > > >
> > > > > I would like to propose OzHera[1] as a new apache incubator
> project,
> > > you
> > > > > can find the proposal[2] of OzHera for more detail.
> > > > >
> > > > > OzHera is an application performance observation platform that
> > centers
> > > > > around applications,
> > > > > integrating metric monitoring, link tracing, logs, alerts, and
> other
> > > > > capabilities.
> > > > > The Hera platform has the following core features:
> > > > >
> > > > > ** Embrace Cloud Native
> > > > > Complies with the Opentracing standard, integrating multiple star
> > > > > open-source products such as OpenTelemetry,
> > > > > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera
> deeply
> > > > > adapts to K8S,
> > > > > providing one-click deployment on K8S through operator.
> > > > >
> > > > > ** Precise: Availability Metrics
> > > > > We have defined corresponding availability metrics for common RPC
> > > > > (Dubbo, HTTP, etc.) requests.
> > > > > These request-scope metrics are automatically extracted from
> tracing
> > > > > by Hera, and during extraction,
> > > > > we enhance the ability to recognize business error codes.
> > > > > A single metric can accurately express the exceptions encapsulated
> by
> > > > > RPC and business processing.
> > > > >
> > > > > ** Quick: Metrics-Tracing-Logging Linkage
> > > > > Based on traceId, it links the alarm -> metrics -> link -> log
> closed
> > > loop.
> > > > > From the moment the alarm card touches the user, the user can
> quickly
> > > > > view the link and log situation related to this alarm,
> > > > > greatly improving the efficiency of problem locating.
> > > > >
> > > > > ** Economical
> > > > > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > > > > OzHera achieves the recognition of abnormal calls (error span,
> > > > > abnormal business error codes,
> > > > > error logs, single span time exceeding 1 second, etc.) and ensures
> > the
> > > > > storage of data for the entire call link of abnormal traces.
> > > > > For normal traces, we adopt a default random sampling strategy of
> one
> > > > > in ten thousand.
> > > > >
> > > > > ** Enterprise-level Observable Products
> > > > > Complete account, permission, application management mechanisms,
> > > > > allowing users to quickly implement within the enterprise and
> connect
> > > > > to the enterprise’s own account, application deployment system,
> etc.
> > > > > It can also quickly dock with enterprise office software to achieve
> > > > > alarm touch. Core links are well decoupled for rapid scaling,
> > > > > and for large volumes of tracing, we have implemented tail sampling
> > > strategies,
> > > > > able to support high qps, real-time observable demands of high
> > > > > timeliness systems.
> > > > >
> > > > > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > > > > [2]
> > > https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> > > > >
> > > > > Best,
> > > > > Yu Xiao
> > > > >
> > > > > ASF Member
> > > > > Apache ShenYu V.P.
> > > > > Apache Incubator PMC
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
>

Re: [DISCUSS] Incubating Proposal for OzHera

[Huajie Wang <be...@apache.org>]

Thanks for the interesting proposal first. After review the project, I feel
that this project is still in its early stages:

1. There is no website and documentation.
2. Many people in the issues asking how to compile and use it[1], and there
some replies but the links do not found[2].
3. Apart from Xiaomi, are there any other contributors and users in the
project?
4. We can only gather some information about this project from your
proposal, No information about the project can be found from other channel
5. It seems like the project has not established a community yet

How do you intend to solve these problems?


[1] https://github.com/XiaoMi/mone/issues/531
[2]
https://github.com/XiaoMi/mone/blob/master/hera-all/readme/deploy/hera-deploy-document.md



Best,
Huajie Wang



tison <wa...@gmail.com> 于2023年9月6日周三 16:02写道：

> FWIW I rejected an incubator proposal before they submitted it formally in
> the past weeks with the suggestion to run an open-source community first as
> Sheng & Ming suggested above.
>
> This is never permanent. And often, a healthy project takes a few months to
> determine whether entering the incubator is a good idea. All the projects I
> mentored (Kvrocks, StreamPark, and OpenDAL) have been running a community
> for one to two years outside the incubator.
>
> Be aware that it's not a hard requirement, but the understanding of
> "entering the incubator" is the concern.
>
> > There is no magic in the Apache incubator. Don't expect the incubator
> will make your project international and successful
>
> I read this sentence as a reply to the following understanding:
>
> >> The user interface currently only has Chinese, and the
> internationalization of the page requires a longer time to iterate, but we
> will complete the transformation of this function in the early stage of
> incubation;
> >> We have checked in advance, and we hope to do the replacement and
> upgrade during the future incubation period.
> >>> Our project is open and is willing to cooperate with the Apache
> Incubator community, mentors, and other relevant parties to resolve
> potential license issues.
>
> The mission of Incubator is[1]:
>
> > It helps those incoming projects (called "podlings") adopt the Apache
> style of governance and operation and guides them to the ASF services
> available to our projects so they can become top-level ASF projects
> ("TLPs").
>
> ... and according to the answer of "Does our project fit the Apache
> Incubator?"[2]:
>
> > To give our "podlings" (incubating projects) the best chances of success,
> we usually ask them to enter the Incubator with at least the start of a
> community built around an existing codebase.
>
> So the Incubator doesn't help in "create" the community, but help in shape
> the community following the Apache style of governance and operation.
>
> Best,
> tison.
>
> [1] https://incubator.apache.org/
> [2]
>
> https://incubator.apache.org/cookbook/#does_our_project_fit_the_apache_incubator
>
>
> Ming Wen <we...@apache.org> 于2023年9月6日周三 14:55写道：
>
> > After reading these responses, I feel that this project is not ready to
> > enter the Apache Incubator, especially considering that you have received
> > support from 6 mentors and communicated with them.
> > There is no magic in the Apache incubator. Don't expect the incubator
> will
> > make your project international and successful. For example, I noticed
> the
> > issues were all in Chinese, and no one reviewed PRs before merged.
> >
> > Thanks,
> > Ming Wen, Apache APISIX PMC Chair
> > Twitter: _WenMing
> >
> >
> > Zhiyong Zhang <go...@apache.org> 于2023年9月5日周二 22:33写道：
> >
> > >
> > >
> > > On 2023/09/05 05:56:51 Sheng Wu wrote:
> > > > Several important things
> > >
> > > The entire project https://github.com/XiaoMi/mone has passed the
> > internal
> > > audit of Xiaomi, and the owners and leaders of the entire project are
> > > consistent with the initiators of the ozhera project. The main donation
> > to
> > > ASF this time is ozhera-all, and other modules follow the Apache
> > protocol,
> > > which will not cause protocol or ownership ambiguity.
> > > > 1. You are mentioning the donation is about
> > > > `https://github.com/XiaoMi/mone/tree/master/ozhera-all`
> <https://github.com/XiaoMi/mone/tree/master/ozhera-all>
> > <https://github.com/XiaoMi/mone/tree/master/ozhera-all>
> > > <https://github.com/XiaoMi/mone/tree/master/ozhera-all>, It is a part
> > > > of the repository, so will others stay out of the ASF? If so, have
> the
> > > > project been going through Xiaomi's internal audit about the sharing
> > > > codes between this part of the whole project? Who owns that?
> > >
> > > We hope to complete the internationalization transformation with the
> help
> > > of ASF; we are preparing the English documents, and a version will be
> > > completed by tomorrow;
> > > > 2. I can't see any English document for the project. Is the community
> > > > for a global foundation incubating journey?
> > >
> > > The user interface currently only has Chinese, and the
> > > internationalization of the page requires a longer time to iterate, but
> > we
> > > will complete the transformation of this function in the early stage of
> > > incubation;
> > > > 3. More importantly, all screenshots and UIs are only in Chinese as
> > well?
> > >
> > > a.We have received full support from Xiaomi's legal affairs and are
> able
> > > to submit the SGA;
> > > b.The project has gradually recruited partners outside of Xiaomi, and
> the
> > > initial committers from Xiaomi are also actively participating in the
> > > construction of other open source communities. These are a group of
> > > partners who are passionate about open source. I believe that this
> group
> > of
> > > partners can continue the project in the long term.
> > > > 4. Have Xiaomi Inc. agreed on this? Will they submit a SGA? Are the
> > > > initial committers still working on Xiaomi and going to continue work
> > > > this project? Will Xiaomi permit their CCLAs?
> > >
> > > We have checked in advance, and we hope to do the replacement and
> upgrade
> > > during the future incubation period.
> > > > 5. I can see several incompatible licenses of dependencies existing,
> > > > including GPLs. Do you have plans to remove or replace them? Have you
> > > > worked with your mentors to go through licenses of dependencies
> check?
> > >
> > > There is a relatively clear division of labor among the mentors, and
> the
> > > mentors will regularly assign us corresponding tasks. Through efficient
> > > project collaboration, we ensure the activity of the community;
> > > At the same time, we can gain more experience and guidance from
> multiple
> > > mentors, which will further promote the positive cycle development of
> the
> > > community.
> > > > 6. Why a 10 people PPMC initial team has a mentor team of 6 people?
> > > > Typically, I don't think this is a good practice. Instead, mentors
> are
> > > > most likely counting on others and will become inactive.
> > >
> > > I hope that ozhera can play its value in the observability of
> > cloud-native
> > > applications. Many components in ozhera (Opentelemetry, Grafana,
> > > Prometheus, MQ, etc.) come from the open source community. We hope to
> > feed
> > > back our experience in the field of application observation to the
> > > community through this platform. The UI design will actively embrace
> open
> > > source like the backend, but we hope to implement mature solutions from
> > the
> > > community for chart display, currently it is Grafana.
> > > > 7. How would you process the branding? Including you are sharing UI
> > > > design. I have concerns this would be another issues with the main
> > > > project.
> > >
> > > a. We have chosen MySQL and Elasticsearch as the project's storage
> > > solutions based on their excellent performance in their respective
> > fields.
> > > The versions we have chosen strictly comply with the GPL and Apache2.0
> > > agreements.
> > > b. While Elasticsearch has changed from Apache 2.0 to the Server Side
> > > Public License (SSPL), although SSPL is no longer an OSI-approved open
> > > source license, it still allows free use, modification, and
> distribution,
> > > but imposes some restrictions on commercial use.
> > > c. We are also working on storage design. In the future, we will
> abstract
> > > a complete storage layer interface to decouple the code logic from the
> > > specific storage implementation. This facilitates integrating more
> > > alternative storage solutions. Our project is open and is willing to
> > > cooperate with the Apache Incubator community, mentors, and other
> > relevant
> > > parties to resolve potential license issues.
> > > > 8. You are using MySQL and ElasticSearch as storage. The one is on
> GPL
> > > > and the other is not longer OSI-approved license anymore. What is
> your
> > > > plan on that?
> > >
> > > Firstly, SkyWalking is an excellent open source APM, with comprehensive
> > > capabilities in tracing, real-time topology, and multi-language
> > adaptation.
> > > The starting point for creating OzHera is to build an enterprise-level
> > > observability platform for the cloud-native era that truly solves the
> > > problem of discovering business issues within 1 minute and locating
> them
> > > within 5 minutes.
> > > Its core features include:
> > > a. Embracing Cloud-native
> > > It adheres to the Opentracing standard and integrates several renowned
> > > open-source products including Opentelemetry, Grafana, Prometheus, and
> > ES.
> > > Hera also deeply adapts to K8S and provides one-click deployment
> > capability
> > > based on K8S.
> > > b. Accuracy: Availability metrics
> > > Too many alerts essentially equate to ineffective alerts, making the
> > > accuracy of alerts particularly important. No one understands the
> > > correctness of requests better than their own business error codes. We
> > > incorporate the ability to recognize business error codes into the
> > business
> > > availability metrics, allowing business alerts to focus on just this
> one
> > > indicator. At the same time, we are also expanding SLA metrics to view
> > the
> > > availability of server services from the client's perspective.
> > > c. Excellent Linkage: Metrics-Tracing-Logging linkage
> > > Based on the traceId, we establish a closed-loop linkage of
> > > alarm->indicator->link->log, significantly improving user efficiency in
> > > pinpointing issues.
> > > d. Economical: <0.1% storage cost, satisfying 99.9% of tracing demands
> > > We judge the importance of traces (exceptional span, single span calls
> > > exceeding 1s, error log output, business exception error codes, etc.).
> > Any
> > > trace identified as important is fully retained, while the remaining
> > normal
> > > traces are sampled to ensure efficiency while considering economic
> costs.
> > > e. Enterprise-level Observable Product
> > > Complete tenant permissions and application management mechanisms make
> it
> > > easy for users to quickly deploy and integrate their own accounts,
> CI/CD
> > > systems, etc., within the enterprise. It can also quickly connect to
> > > enterprise office software to achieve alert delivery;
> > > Within Xiaomi, it handles over 100T of data daily in a smooth and
> > > efficient manner;
> > > The core link is well decoupled to facilitate rapid scaling at each
> > stage.
> > > For large volumes of tracing, we have implemented head and tail
> sampling
> > to
> > > ensure the platform's cost-effectiveness.
> > > > 9 What are the differences between you and SkyWalking? What is this
> > > > new project bringing new to the users? Notice, this is a not a
> > > > rejection for a similar project, but, if they are nearly same, you
> > > > will face competitions in the same foundation but already have larger
> > > > community.
> > > >
> > > > Sheng Wu 吴晟
> > > > Twitter, wusheng1108
> > > >
> > > > Yu Xiao <xi...@apache.org> 于2023年9月5日周二 11:12写道：
> > > > >
> > > > > Dear incubator community,
> > > > >
> > > > > I would like to propose OzHera[1] as a new apache incubator
> project,
> > > you
> > > > > can find the proposal[2] of OzHera for more detail.
> > > > >
> > > > > OzHera is an application performance observation platform that
> > centers
> > > > > around applications,
> > > > > integrating metric monitoring, link tracing, logs, alerts, and
> other
> > > > > capabilities.
> > > > > The Hera platform has the following core features:
> > > > >
> > > > > ** Embrace Cloud Native
> > > > > Complies with the Opentracing standard, integrating multiple star
> > > > > open-source products such as OpenTelemetry,
> > > > > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera
> deeply
> > > > > adapts to K8S,
> > > > > providing one-click deployment on K8S through operator.
> > > > >
> > > > > ** Precise: Availability Metrics
> > > > > We have defined corresponding availability metrics for common RPC
> > > > > (Dubbo, HTTP, etc.) requests.
> > > > > These request-scope metrics are automatically extracted from
> tracing
> > > > > by Hera, and during extraction,
> > > > > we enhance the ability to recognize business error codes.
> > > > > A single metric can accurately express the exceptions encapsulated
> by
> > > > > RPC and business processing.
> > > > >
> > > > > ** Quick: Metrics-Tracing-Logging Linkage
> > > > > Based on traceId, it links the alarm -> metrics -> link -> log
> closed
> > > loop.
> > > > > From the moment the alarm card touches the user, the user can
> quickly
> > > > > view the link and log situation related to this alarm,
> > > > > greatly improving the efficiency of problem locating.
> > > > >
> > > > > ** Economical
> > > > > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > > > > OzHera achieves the recognition of abnormal calls (error span,
> > > > > abnormal business error codes,
> > > > > error logs, single span time exceeding 1 second, etc.) and ensures
> > the
> > > > > storage of data for the entire call link of abnormal traces.
> > > > > For normal traces, we adopt a default random sampling strategy of
> one
> > > > > in ten thousand.
> > > > >
> > > > > ** Enterprise-level Observable Products
> > > > > Complete account, permission, application management mechanisms,
> > > > > allowing users to quickly implement within the enterprise and
> connect
> > > > > to the enterprise’s own account, application deployment system,
> etc.
> > > > > It can also quickly dock with enterprise office software to achieve
> > > > > alarm touch. Core links are well decoupled for rapid scaling,
> > > > > and for large volumes of tracing, we have implemented tail sampling
> > > strategies,
> > > > > able to support high qps, real-time observable demands of high
> > > > > timeliness systems.
> > > > >
> > > > > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > > > > [2]
> > > https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> > > > >
> > > > > Best,
> > > > > Yu Xiao
> > > > >
> > > > > ASF Member
> > > > > Apache ShenYu V.P.
> > > > > Apache Incubator PMC
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
>

Re: [DISCUSS] Incubating Proposal for OzHera

[tison <wa...@gmail.com>]

FWIW I rejected an incubator proposal before they submitted it formally in
the past weeks with the suggestion to run an open-source community first as
Sheng & Ming suggested above.

This is never permanent. And often, a healthy project takes a few months to
determine whether entering the incubator is a good idea. All the projects I
mentored (Kvrocks, StreamPark, and OpenDAL) have been running a community
for one to two years outside the incubator.

Be aware that it's not a hard requirement, but the understanding of
"entering the incubator" is the concern.

> There is no magic in the Apache incubator. Don't expect the incubator
will make your project international and successful

I read this sentence as a reply to the following understanding:

>> The user interface currently only has Chinese, and the
internationalization of the page requires a longer time to iterate, but we
will complete the transformation of this function in the early stage of
incubation;
>> We have checked in advance, and we hope to do the replacement and
upgrade during the future incubation period.
>>> Our project is open and is willing to cooperate with the Apache
Incubator community, mentors, and other relevant parties to resolve
potential license issues.

The mission of Incubator is[1]:

> It helps those incoming projects (called "podlings") adopt the Apache
style of governance and operation and guides them to the ASF services
available to our projects so they can become top-level ASF projects
("TLPs").

... and according to the answer of "Does our project fit the Apache
Incubator?"[2]:

> To give our "podlings" (incubating projects) the best chances of success,
we usually ask them to enter the Incubator with at least the start of a
community built around an existing codebase.

So the Incubator doesn't help in "create" the community, but help in shape
the community following the Apache style of governance and operation.

Best,
tison.

[1] https://incubator.apache.org/
[2]
https://incubator.apache.org/cookbook/#does_our_project_fit_the_apache_incubator


Ming Wen <we...@apache.org> 于2023年9月6日周三 14:55写道：

> After reading these responses, I feel that this project is not ready to
> enter the Apache Incubator, especially considering that you have received
> support from 6 mentors and communicated with them.
> There is no magic in the Apache incubator. Don't expect the incubator will
> make your project international and successful. For example, I noticed the
> issues were all in Chinese, and no one reviewed PRs before merged.
>
> Thanks,
> Ming Wen, Apache APISIX PMC Chair
> Twitter: _WenMing
>
>
> Zhiyong Zhang <go...@apache.org> 于2023年9月5日周二 22:33写道：
>
> >
> >
> > On 2023/09/05 05:56:51 Sheng Wu wrote:
> > > Several important things
> >
> > The entire project https://github.com/XiaoMi/mone has passed the
> internal
> > audit of Xiaomi, and the owners and leaders of the entire project are
> > consistent with the initiators of the ozhera project. The main donation
> to
> > ASF this time is ozhera-all, and other modules follow the Apache
> protocol,
> > which will not cause protocol or ownership ambiguity.
> > > 1. You are mentioning the donation is about
> > > `https://github.com/XiaoMi/mone/tree/master/ozhera-all`
> <https://github.com/XiaoMi/mone/tree/master/ozhera-all>
> > <https://github.com/XiaoMi/mone/tree/master/ozhera-all>, It is a part
> > > of the repository, so will others stay out of the ASF? If so, have the
> > > project been going through Xiaomi's internal audit about the sharing
> > > codes between this part of the whole project? Who owns that?
> >
> > We hope to complete the internationalization transformation with the help
> > of ASF; we are preparing the English documents, and a version will be
> > completed by tomorrow;
> > > 2. I can't see any English document for the project. Is the community
> > > for a global foundation incubating journey?
> >
> > The user interface currently only has Chinese, and the
> > internationalization of the page requires a longer time to iterate, but
> we
> > will complete the transformation of this function in the early stage of
> > incubation;
> > > 3. More importantly, all screenshots and UIs are only in Chinese as
> well?
> >
> > a.We have received full support from Xiaomi's legal affairs and are able
> > to submit the SGA;
> > b.The project has gradually recruited partners outside of Xiaomi, and the
> > initial committers from Xiaomi are also actively participating in the
> > construction of other open source communities. These are a group of
> > partners who are passionate about open source. I believe that this group
> of
> > partners can continue the project in the long term.
> > > 4. Have Xiaomi Inc. agreed on this? Will they submit a SGA? Are the
> > > initial committers still working on Xiaomi and going to continue work
> > > this project? Will Xiaomi permit their CCLAs?
> >
> > We have checked in advance, and we hope to do the replacement and upgrade
> > during the future incubation period.
> > > 5. I can see several incompatible licenses of dependencies existing,
> > > including GPLs. Do you have plans to remove or replace them? Have you
> > > worked with your mentors to go through licenses of dependencies check?
> >
> > There is a relatively clear division of labor among the mentors, and the
> > mentors will regularly assign us corresponding tasks. Through efficient
> > project collaboration, we ensure the activity of the community;
> > At the same time, we can gain more experience and guidance from multiple
> > mentors, which will further promote the positive cycle development of the
> > community.
> > > 6. Why a 10 people PPMC initial team has a mentor team of 6 people?
> > > Typically, I don't think this is a good practice. Instead, mentors are
> > > most likely counting on others and will become inactive.
> >
> > I hope that ozhera can play its value in the observability of
> cloud-native
> > applications. Many components in ozhera (Opentelemetry, Grafana,
> > Prometheus, MQ, etc.) come from the open source community. We hope to
> feed
> > back our experience in the field of application observation to the
> > community through this platform. The UI design will actively embrace open
> > source like the backend, but we hope to implement mature solutions from
> the
> > community for chart display, currently it is Grafana.
> > > 7. How would you process the branding? Including you are sharing UI
> > > design. I have concerns this would be another issues with the main
> > > project.
> >
> > a. We have chosen MySQL and Elasticsearch as the project's storage
> > solutions based on their excellent performance in their respective
> fields.
> > The versions we have chosen strictly comply with the GPL and Apache2.0
> > agreements.
> > b. While Elasticsearch has changed from Apache 2.0 to the Server Side
> > Public License (SSPL), although SSPL is no longer an OSI-approved open
> > source license, it still allows free use, modification, and distribution,
> > but imposes some restrictions on commercial use.
> > c. We are also working on storage design. In the future, we will abstract
> > a complete storage layer interface to decouple the code logic from the
> > specific storage implementation. This facilitates integrating more
> > alternative storage solutions. Our project is open and is willing to
> > cooperate with the Apache Incubator community, mentors, and other
> relevant
> > parties to resolve potential license issues.
> > > 8. You are using MySQL and ElasticSearch as storage. The one is on GPL
> > > and the other is not longer OSI-approved license anymore. What is your
> > > plan on that?
> >
> > Firstly, SkyWalking is an excellent open source APM, with comprehensive
> > capabilities in tracing, real-time topology, and multi-language
> adaptation.
> > The starting point for creating OzHera is to build an enterprise-level
> > observability platform for the cloud-native era that truly solves the
> > problem of discovering business issues within 1 minute and locating them
> > within 5 minutes.
> > Its core features include:
> > a. Embracing Cloud-native
> > It adheres to the Opentracing standard and integrates several renowned
> > open-source products including Opentelemetry, Grafana, Prometheus, and
> ES.
> > Hera also deeply adapts to K8S and provides one-click deployment
> capability
> > based on K8S.
> > b. Accuracy: Availability metrics
> > Too many alerts essentially equate to ineffective alerts, making the
> > accuracy of alerts particularly important. No one understands the
> > correctness of requests better than their own business error codes. We
> > incorporate the ability to recognize business error codes into the
> business
> > availability metrics, allowing business alerts to focus on just this one
> > indicator. At the same time, we are also expanding SLA metrics to view
> the
> > availability of server services from the client's perspective.
> > c. Excellent Linkage: Metrics-Tracing-Logging linkage
> > Based on the traceId, we establish a closed-loop linkage of
> > alarm->indicator->link->log, significantly improving user efficiency in
> > pinpointing issues.
> > d. Economical: <0.1% storage cost, satisfying 99.9% of tracing demands
> > We judge the importance of traces (exceptional span, single span calls
> > exceeding 1s, error log output, business exception error codes, etc.).
> Any
> > trace identified as important is fully retained, while the remaining
> normal
> > traces are sampled to ensure efficiency while considering economic costs.
> > e. Enterprise-level Observable Product
> > Complete tenant permissions and application management mechanisms make it
> > easy for users to quickly deploy and integrate their own accounts, CI/CD
> > systems, etc., within the enterprise. It can also quickly connect to
> > enterprise office software to achieve alert delivery;
> > Within Xiaomi, it handles over 100T of data daily in a smooth and
> > efficient manner;
> > The core link is well decoupled to facilitate rapid scaling at each
> stage.
> > For large volumes of tracing, we have implemented head and tail sampling
> to
> > ensure the platform's cost-effectiveness.
> > > 9 What are the differences between you and SkyWalking? What is this
> > > new project bringing new to the users? Notice, this is a not a
> > > rejection for a similar project, but, if they are nearly same, you
> > > will face competitions in the same foundation but already have larger
> > > community.
> > >
> > > Sheng Wu 吴晟
> > > Twitter, wusheng1108
> > >
> > > Yu Xiao <xi...@apache.org> 于2023年9月5日周二 11:12写道：
> > > >
> > > > Dear incubator community,
> > > >
> > > > I would like to propose OzHera[1] as a new apache incubator project,
> > you
> > > > can find the proposal[2] of OzHera for more detail.
> > > >
> > > > OzHera is an application performance observation platform that
> centers
> > > > around applications,
> > > > integrating metric monitoring, link tracing, logs, alerts, and other
> > > > capabilities.
> > > > The Hera platform has the following core features:
> > > >
> > > > ** Embrace Cloud Native
> > > > Complies with the Opentracing standard, integrating multiple star
> > > > open-source products such as OpenTelemetry,
> > > > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> > > > adapts to K8S,
> > > > providing one-click deployment on K8S through operator.
> > > >
> > > > ** Precise: Availability Metrics
> > > > We have defined corresponding availability metrics for common RPC
> > > > (Dubbo, HTTP, etc.) requests.
> > > > These request-scope metrics are automatically extracted from tracing
> > > > by Hera, and during extraction,
> > > > we enhance the ability to recognize business error codes.
> > > > A single metric can accurately express the exceptions encapsulated by
> > > > RPC and business processing.
> > > >
> > > > ** Quick: Metrics-Tracing-Logging Linkage
> > > > Based on traceId, it links the alarm -> metrics -> link -> log closed
> > loop.
> > > > From the moment the alarm card touches the user, the user can quickly
> > > > view the link and log situation related to this alarm,
> > > > greatly improving the efficiency of problem locating.
> > > >
> > > > ** Economical
> > > > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > > > OzHera achieves the recognition of abnormal calls (error span,
> > > > abnormal business error codes,
> > > > error logs, single span time exceeding 1 second, etc.) and ensures
> the
> > > > storage of data for the entire call link of abnormal traces.
> > > > For normal traces, we adopt a default random sampling strategy of one
> > > > in ten thousand.
> > > >
> > > > ** Enterprise-level Observable Products
> > > > Complete account, permission, application management mechanisms,
> > > > allowing users to quickly implement within the enterprise and connect
> > > > to the enterprise’s own account, application deployment system, etc.
> > > > It can also quickly dock with enterprise office software to achieve
> > > > alarm touch. Core links are well decoupled for rapid scaling,
> > > > and for large volumes of tracing, we have implemented tail sampling
> > strategies,
> > > > able to support high qps, real-time observable demands of high
> > > > timeliness systems.
> > > >
> > > > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > > > [2]
> > https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> > > >
> > > > Best,
> > > > Yu Xiao
> > > >
> > > > ASF Member
> > > > Apache ShenYu V.P.
> > > > Apache Incubator PMC
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>

Re: [DISCUSS] Incubating Proposal for OzHera

[Ming Wen <we...@apache.org>]

After reading these responses, I feel that this project is not ready to
enter the Apache Incubator, especially considering that you have received
support from 6 mentors and communicated with them.
There is no magic in the Apache incubator. Don't expect the incubator will
make your project international and successful. For example, I noticed the
issues were all in Chinese, and no one reviewed PRs before merged.

Thanks,
Ming Wen, Apache APISIX PMC Chair
Twitter: _WenMing


Zhiyong Zhang <go...@apache.org> 于2023年9月5日周二 22:33写道：

>
>
> On 2023/09/05 05:56:51 Sheng Wu wrote:
> > Several important things
>
> The entire project https://github.com/XiaoMi/mone has passed the internal
> audit of Xiaomi, and the owners and leaders of the entire project are
> consistent with the initiators of the ozhera project. The main donation to
> ASF this time is ozhera-all, and other modules follow the Apache protocol,
> which will not cause protocol or ownership ambiguity.
> > 1. You are mentioning the donation is about
> > `https://github.com/XiaoMi/mone/tree/master/ozhera-all`
> <https://github.com/XiaoMi/mone/tree/master/ozhera-all>, It is a part
> > of the repository, so will others stay out of the ASF? If so, have the
> > project been going through Xiaomi's internal audit about the sharing
> > codes between this part of the whole project? Who owns that?
>
> We hope to complete the internationalization transformation with the help
> of ASF; we are preparing the English documents, and a version will be
> completed by tomorrow;
> > 2. I can't see any English document for the project. Is the community
> > for a global foundation incubating journey?
>
> The user interface currently only has Chinese, and the
> internationalization of the page requires a longer time to iterate, but we
> will complete the transformation of this function in the early stage of
> incubation;
> > 3. More importantly, all screenshots and UIs are only in Chinese as well?
>
> a.We have received full support from Xiaomi's legal affairs and are able
> to submit the SGA;
> b.The project has gradually recruited partners outside of Xiaomi, and the
> initial committers from Xiaomi are also actively participating in the
> construction of other open source communities. These are a group of
> partners who are passionate about open source. I believe that this group of
> partners can continue the project in the long term.
> > 4. Have Xiaomi Inc. agreed on this? Will they submit a SGA? Are the
> > initial committers still working on Xiaomi and going to continue work
> > this project? Will Xiaomi permit their CCLAs?
>
> We have checked in advance, and we hope to do the replacement and upgrade
> during the future incubation period.
> > 5. I can see several incompatible licenses of dependencies existing,
> > including GPLs. Do you have plans to remove or replace them? Have you
> > worked with your mentors to go through licenses of dependencies check?
>
> There is a relatively clear division of labor among the mentors, and the
> mentors will regularly assign us corresponding tasks. Through efficient
> project collaboration, we ensure the activity of the community;
> At the same time, we can gain more experience and guidance from multiple
> mentors, which will further promote the positive cycle development of the
> community.
> > 6. Why a 10 people PPMC initial team has a mentor team of 6 people?
> > Typically, I don't think this is a good practice. Instead, mentors are
> > most likely counting on others and will become inactive.
>
> I hope that ozhera can play its value in the observability of cloud-native
> applications. Many components in ozhera (Opentelemetry, Grafana,
> Prometheus, MQ, etc.) come from the open source community. We hope to feed
> back our experience in the field of application observation to the
> community through this platform. The UI design will actively embrace open
> source like the backend, but we hope to implement mature solutions from the
> community for chart display, currently it is Grafana.
> > 7. How would you process the branding? Including you are sharing UI
> > design. I have concerns this would be another issues with the main
> > project.
>
> a. We have chosen MySQL and Elasticsearch as the project's storage
> solutions based on their excellent performance in their respective fields.
> The versions we have chosen strictly comply with the GPL and Apache2.0
> agreements.
> b. While Elasticsearch has changed from Apache 2.0 to the Server Side
> Public License (SSPL), although SSPL is no longer an OSI-approved open
> source license, it still allows free use, modification, and distribution,
> but imposes some restrictions on commercial use.
> c. We are also working on storage design. In the future, we will abstract
> a complete storage layer interface to decouple the code logic from the
> specific storage implementation. This facilitates integrating more
> alternative storage solutions. Our project is open and is willing to
> cooperate with the Apache Incubator community, mentors, and other relevant
> parties to resolve potential license issues.
> > 8. You are using MySQL and ElasticSearch as storage. The one is on GPL
> > and the other is not longer OSI-approved license anymore. What is your
> > plan on that?
>
> Firstly, SkyWalking is an excellent open source APM, with comprehensive
> capabilities in tracing, real-time topology, and multi-language adaptation.
> The starting point for creating OzHera is to build an enterprise-level
> observability platform for the cloud-native era that truly solves the
> problem of discovering business issues within 1 minute and locating them
> within 5 minutes.
> Its core features include:
> a. Embracing Cloud-native
> It adheres to the Opentracing standard and integrates several renowned
> open-source products including Opentelemetry, Grafana, Prometheus, and ES.
> Hera also deeply adapts to K8S and provides one-click deployment capability
> based on K8S.
> b. Accuracy: Availability metrics
> Too many alerts essentially equate to ineffective alerts, making the
> accuracy of alerts particularly important. No one understands the
> correctness of requests better than their own business error codes. We
> incorporate the ability to recognize business error codes into the business
> availability metrics, allowing business alerts to focus on just this one
> indicator. At the same time, we are also expanding SLA metrics to view the
> availability of server services from the client's perspective.
> c. Excellent Linkage: Metrics-Tracing-Logging linkage
> Based on the traceId, we establish a closed-loop linkage of
> alarm->indicator->link->log, significantly improving user efficiency in
> pinpointing issues.
> d. Economical: <0.1% storage cost, satisfying 99.9% of tracing demands
> We judge the importance of traces (exceptional span, single span calls
> exceeding 1s, error log output, business exception error codes, etc.). Any
> trace identified as important is fully retained, while the remaining normal
> traces are sampled to ensure efficiency while considering economic costs.
> e. Enterprise-level Observable Product
> Complete tenant permissions and application management mechanisms make it
> easy for users to quickly deploy and integrate their own accounts, CI/CD
> systems, etc., within the enterprise. It can also quickly connect to
> enterprise office software to achieve alert delivery;
> Within Xiaomi, it handles over 100T of data daily in a smooth and
> efficient manner;
> The core link is well decoupled to facilitate rapid scaling at each stage.
> For large volumes of tracing, we have implemented head and tail sampling to
> ensure the platform's cost-effectiveness.
> > 9 What are the differences between you and SkyWalking? What is this
> > new project bringing new to the users? Notice, this is a not a
> > rejection for a similar project, but, if they are nearly same, you
> > will face competitions in the same foundation but already have larger
> > community.
> >
> > Sheng Wu 吴晟
> > Twitter, wusheng1108
> >
> > Yu Xiao <xi...@apache.org> 于2023年9月5日周二 11:12写道：
> > >
> > > Dear incubator community,
> > >
> > > I would like to propose OzHera[1] as a new apache incubator project,
> you
> > > can find the proposal[2] of OzHera for more detail.
> > >
> > > OzHera is an application performance observation platform that centers
> > > around applications,
> > > integrating metric monitoring, link tracing, logs, alerts, and other
> > > capabilities.
> > > The Hera platform has the following core features:
> > >
> > > ** Embrace Cloud Native
> > > Complies with the Opentracing standard, integrating multiple star
> > > open-source products such as OpenTelemetry,
> > > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> > > adapts to K8S,
> > > providing one-click deployment on K8S through operator.
> > >
> > > ** Precise: Availability Metrics
> > > We have defined corresponding availability metrics for common RPC
> > > (Dubbo, HTTP, etc.) requests.
> > > These request-scope metrics are automatically extracted from tracing
> > > by Hera, and during extraction,
> > > we enhance the ability to recognize business error codes.
> > > A single metric can accurately express the exceptions encapsulated by
> > > RPC and business processing.
> > >
> > > ** Quick: Metrics-Tracing-Logging Linkage
> > > Based on traceId, it links the alarm -> metrics -> link -> log closed
> loop.
> > > From the moment the alarm card touches the user, the user can quickly
> > > view the link and log situation related to this alarm,
> > > greatly improving the efficiency of problem locating.
> > >
> > > ** Economical
> > > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > > OzHera achieves the recognition of abnormal calls (error span,
> > > abnormal business error codes,
> > > error logs, single span time exceeding 1 second, etc.) and ensures the
> > > storage of data for the entire call link of abnormal traces.
> > > For normal traces, we adopt a default random sampling strategy of one
> > > in ten thousand.
> > >
> > > ** Enterprise-level Observable Products
> > > Complete account, permission, application management mechanisms,
> > > allowing users to quickly implement within the enterprise and connect
> > > to the enterprise’s own account, application deployment system, etc.
> > > It can also quickly dock with enterprise office software to achieve
> > > alarm touch. Core links are well decoupled for rapid scaling,
> > > and for large volumes of tracing, we have implemented tail sampling
> strategies,
> > > able to support high qps, real-time observable demands of high
> > > timeliness systems.
> > >
> > > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > > [2]
> https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> > >
> > > Best,
> > > Yu Xiao
> > >
> > > ASF Member
> > > Apache ShenYu V.P.
> > > Apache Incubator PMC
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: [DISCUSS] Incubating Proposal for OzHera

[Sheng Wu <wu...@gmail.com>]

Inline, my concerns are more with the project status feedback.
The project status seems as same as I felt when reviewing the project today.
And both from the project tech perspective and also from the
experience level of initial committers is also too early to jump into
the foundation incubator, before a basic license understanding and
requirements and expectations of foundation projects.
I highly recommend the project takes a longer time to learn the
knowledge and at least build a (small but existing) community that out
of Xiaomi to prove the project's real recommended use scenarios.

More details inline.

Zhiyong Zhang <go...@apache.org> 于2023年9月5日周二 22:33写道：
>
>
>
> On 2023/09/05 05:56:51 Sheng Wu wrote:
> > Several important things
>
> The entire project https://github.com/XiaoMi/mone has passed the internal audit of Xiaomi, and the owners and leaders of the entire project are consistent with the initiators of the ozhera project. The main donation to ASF this time is ozhera-all, and other modules follow the Apache protocol, which will not cause protocol or ownership ambiguity.

This doesn't make sense. Apache 2.0 is just a license and it should be
based on IP clearance and ownership declaration. These will become two
projects, and each of them has different owners, Why suddenly this
will not be an issue?

> > 1. You are mentioning the donation is about
> > `https://github.com/XiaoMi/mone/tree/master/ozhera-all`, It is a part
> > of the repository, so will others stay out of the ASF? If so, have the
> > project been going through Xiaomi's internal audit about the sharing
> > codes between this part of the whole project? Who owns that?
>
> We hope to complete the internationalization transformation with the help of ASF; we are preparing the English documents, and a version will be completed by tomorrow;

I am asking whether your community already exists and is ready for the
incubator. If you are building an English document today(you have
confirmed this), and have no clear documentation, I assume this
project is too early.

> > 2. I can't see any English document for the project. Is the community
> > for a global foundation incubating journey?
>
> The user interface currently only has Chinese, and the internationalization of the page requires a longer time to iterate, but we will complete the transformation of this function in the early stage of incubation;

This seems as same as the project is too early to join the foundation.
Why so hurry to join rather than being patient to setup the initial
community and write good documents
What does an incubating project mean for you?

> > 3. More importantly, all screenshots and UIs are only in Chinese as well?
>
> a.We have received full support from Xiaomi's legal affairs and are able to submit the SGA;
> b.The project has gradually recruited partners outside of Xiaomi, and the initial committers from Xiaomi are also actively participating in the construction of other open source communities. These are a group of partners who are passionate about open source. I believe that this group of partners can continue the project in the long term.

What do you mean `recruited`? Does Xiaomi just hire people to do this?

> > 4. Have Xiaomi Inc. agreed on this? Will they submit a SGA? Are the
> > initial committers still working on Xiaomi and going to continue work
> > this project? Will Xiaomi permit their CCLAs?
>
> We have checked in advance, and we hope to do the replacement and upgrade during the future incubation period.
> > 5. I can see several incompatible licenses of dependencies existing,
> > including GPLs. Do you have plans to remove or replace them? Have you
> > worked with your mentors to go through licenses of dependencies check?
>
> There is a relatively clear division of labor among the mentors, and the mentors will regularly assign us corresponding tasks. Through efficient project collaboration, we ensure the activity of the community;
> At the same time, we can gain more experience and guidance from multiple mentors, which will further promote the positive cycle development of the community.
> > 6. Why a 10 people PPMC initial team has a mentor team of 6 people?
> > Typically, I don't think this is a good practice. Instead, mentors are
> > most likely counting on others and will become inactive.
>
> I hope that ozhera can play its value in the observability of cloud-native applications. Many components in ozhera (Opentelemetry, Grafana, Prometheus, MQ, etc.) come from the open source community. We hope to feed back our experience in the field of application observation to the community through this platform. The UI design will actively embrace open source like the backend, but we hope to implement mature solutions from the community for chart display, currently it is Grafana.
> > 7. How would you process the branding? Including you are sharing UI
> > design. I have concerns this would be another issues with the main
> > project.
>
> a. We have chosen MySQL and Elasticsearch as the project's storage solutions based on their excellent performance in their respective fields. The versions we have chosen strictly comply with the GPL and Apache2.0 agreements.
> b. While Elasticsearch has changed from Apache 2.0 to the Server Side Public License (SSPL), although SSPL is no longer an OSI-approved open source license, it still allows free use, modification, and distribution, but imposes some restrictions on commercial use.

I think these (a)(b) have approved that
1. The initial team is not working with your mentors closely.
2. The initial team is not experienced enough with Open Source.
I am 100% sure, that everyone who had been through the incubating
process, would NOT have this answer.
This is far away from understanding license compatibility in the foundation.
Again, it makes me feel the initial team is also too early to join the
incubator.

> c. We are also working on storage design. In the future, we will abstract a complete storage layer interface to decouple the code logic from the specific storage implementation. This facilitates integrating more alternative storage solutions. Our project is open and is willing to cooperate with the Apache Incubator community, mentors, and other relevant parties to resolve potential license issues.

If there is not a single one available solution, why didn't you think
deeply about whether your project is suitable for the foundation?
ASF's requirements are not hard requirements for every project, but if
you join the foundation, it is.
It is abnormal for a project to join the ASF incubator, and it can't
be used safely with a key part(storage) of the project is Apache 2.0
incompatible.
If you even don't know the meaning and there is no clear solution for
this, it is pointless to suffer all paperwork, meanwhile, your project
is NOT ready from a technology perspective too.

> > 8. You are using MySQL and ElasticSearch as storage. The one is on GPL
> > and the other is not longer OSI-approved license anymore. What is your
> > plan on that?
>
> Firstly, SkyWalking is an excellent open source APM, with comprehensive capabilities in tracing, real-time topology, and multi-language adaptation.
> The starting point for creating OzHera is to build an enterprise-level observability platform for the cloud-native era that truly solves the problem of discovering business issues within 1 minute and locating them within 5 minutes.
> Its core features include:
> a. Embracing Cloud-native
> It adheres to the Opentracing standard and integrates several renowned open-source products including Opentelemetry, Grafana, Prometheus, and ES. Hera also deeply adapts to K8S and provides one-click deployment capability based on K8S.
> b. Accuracy: Availability metrics
> Too many alerts essentially equate to ineffective alerts, making the accuracy of alerts particularly important. No one understands the correctness of requests better than their own business error codes. We incorporate the ability to recognize business error codes into the business availability metrics, allowing business alerts to focus on just this one indicator. At the same time, we are also expanding SLA metrics to view the availability of server services from the client's perspective.
> c. Excellent Linkage: Metrics-Tracing-Logging linkage
> Based on the traceId, we establish a closed-loop linkage of alarm->indicator->link->log, significantly improving user efficiency in pinpointing issues.
> d. Economical: <0.1% storage cost, satisfying 99.9% of tracing demands
> We judge the importance of traces (exceptional span, single span calls exceeding 1s, error log output, business exception error codes, etc.). Any trace identified as important is fully retained, while the remaining normal traces are sampled to ensure efficiency while considering economic costs.
> e. Enterprise-level Observable Product
> Complete tenant permissions and application management mechanisms make it easy for users to quickly deploy and integrate their own accounts, CI/CD systems, etc., within the enterprise. It can also quickly connect to enterprise office software to achieve alert delivery;
> Within Xiaomi, it handles over 100T of data daily in a smooth and efficient manner;
> The core link is well decoupled to facilitate rapid scaling at each stage. For large volumes of tracing, we have implemented head and tail sampling to ensure the platform's cost-effectiveness.
> > 9 What are the differences between you and SkyWalking? What is this
> > new project bringing new to the users? Notice, this is a not a
> > rejection for a similar project, but, if they are nearly same, you
> > will face competitions in the same foundation but already have larger
> > community.

All of these statements seem you are actually not taking serious
consideration. For most things you mentioned, SkyWalking is able to do
it and has better performance behavior, larger scale, and even large
ecosystem adoption.
SkyWalking could easily support PB level and 100+ billion telemetry
data could be collected and analyzed from one SkyWalking cluster years
ago.
Do you have ever evaluated the differences seriously? Or just think
you could do this better.
To compare a project, it is also strange to compare in this way.
Usually, similar projects co-exist when they have different use
scenarios to support rather than a single feature or scale. A mature
project is good at that.

> >
> > Sheng Wu 吴晟
> > Twitter, wusheng1108
> >
> > Yu Xiao <xi...@apache.org> 于2023年9月5日周二 11:12写道：
> > >
> > > Dear incubator community,
> > >
> > > I would like to propose OzHera[1] as a new apache incubator project, you
> > > can find the proposal[2] of OzHera for more detail.
> > >
> > > OzHera is an application performance observation platform that centers
> > > around applications,
> > > integrating metric monitoring, link tracing, logs, alerts, and other
> > > capabilities.
> > > The Hera platform has the following core features:
> > >
> > > ** Embrace Cloud Native
> > > Complies with the Opentracing standard, integrating multiple star
> > > open-source products such as OpenTelemetry,
> > > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> > > adapts to K8S,
> > > providing one-click deployment on K8S through operator.
> > >
> > > ** Precise: Availability Metrics
> > > We have defined corresponding availability metrics for common RPC
> > > (Dubbo, HTTP, etc.) requests.
> > > These request-scope metrics are automatically extracted from tracing
> > > by Hera, and during extraction,
> > > we enhance the ability to recognize business error codes.
> > > A single metric can accurately express the exceptions encapsulated by
> > > RPC and business processing.
> > >
> > > ** Quick: Metrics-Tracing-Logging Linkage
> > > Based on traceId, it links the alarm -> metrics -> link -> log closed loop.
> > > From the moment the alarm card touches the user, the user can quickly
> > > view the link and log situation related to this alarm,
> > > greatly improving the efficiency of problem locating.
> > >
> > > ** Economical
> > > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > > OzHera achieves the recognition of abnormal calls (error span,
> > > abnormal business error codes,
> > > error logs, single span time exceeding 1 second, etc.) and ensures the
> > > storage of data for the entire call link of abnormal traces.
> > > For normal traces, we adopt a default random sampling strategy of one
> > > in ten thousand.
> > >
> > > ** Enterprise-level Observable Products
> > > Complete account, permission, application management mechanisms,
> > > allowing users to quickly implement within the enterprise and connect
> > > to the enterprise’s own account, application deployment system, etc.
> > > It can also quickly dock with enterprise office software to achieve
> > > alarm touch. Core links are well decoupled for rapid scaling,
> > > and for large volumes of tracing, we have implemented tail sampling strategies,
> > > able to support high qps, real-time observable demands of high
> > > timeliness systems.
> > >
> > > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > > [2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> > >
> > > Best,
> > > Yu Xiao
> > >
> > > ASF Member
> > > Apache ShenYu V.P.
> > > Apache Incubator PMC
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[Yu Xiao <xi...@apache.org>]

Hi tison,

It should be clarified that mentors are there to help projects better
practice the Apache Way,
including project releases, license  checked, community builds, etc.

> This sounds interesting. Could you elaborate on the "division of labor" and
previous tasks "assigned" by mentors to initial committers?


That's for sure. The project parties are actively designing pluggable
storage solutions（Compatible with Apache 2.0 Licence）,which will not
create blocking.
> The ASF states its project won't contain GPL-licensed components, at least
not as a necessary dependency. You can check [1][2] for details.
>What would you like to express here? The ASF releases open-source software
following OSD[2][3]. SSPL or ELv2 is simply unacceptable.

Best wishes!

Sheng Wu <wu...@gmail.com> 于2023年9月5日周二 23:51写道：
>
> tison <wa...@gmail.com> 于2023年9月5日周二 22:53写道：
> >
> > Hi,
> >
> > Glad to see a new incubator proposal. Comments inline.
> >
> > > There is a relatively clear division of labor among the mentors, and the
> > mentors will regularly assign us corresponding tasks.
> >
> > This sounds interesting. Could you elaborate on the "division of labor" and
> > previous tasks "assigned" by mentors to initial committers?
>
> A good question, and a bigger concern. Who can assign the mentors to work?
> Are they paid in some ways by Xiaomi? So, they will work for the
> company and the project?
>
>
> >
> > > I hope that ozhera can play its value in the observability of
> > cloud-native applications.
> > >> How would you process the branding
> >
> > The concern here is that ozhera, as a submodule of Mone, can suffer from
> > its packages and UIs convey the Mone branding still held by Xiaomi. If an
> > ASF project is tightly coupled with a vendor-specific project, it may be a
> > concern.
> >
> > > The versions we have chosen strictly comply with the GPL and Apache2.0
> > agreements.
> >
> > The ASF states its project won't contain GPL-licensed components, at least
> > not as a necessary dependency. You can check [1][2] for details.
> >
> > > b. While Elasticsearch has changed from Apache 2.0 to the Server Side
> > Public License (SSPL), although SSPL is no longer an OSI-approved open
> > source license, it still allows free use, modification, and distribution,
> > but imposes some restrictions on commercial use.
> >
> > What would you like to express here? The ASF releases open-source software
> > following OSD[2][3]. SSPL or ELv2 is simply unacceptable.
> >
> > Best,
> > tison.
> >
> > [1] https://www.apache.org/licenses/GPL-compatibility.html
> > [2] https://www.apache.org/legal/resolved.html#category-x
> > [3] https://news.apache.org/foundation/entry/the-apache-way-to-sustainable
> >
> >
> >
> > Zhiyong Zhang <go...@apache.org> 于2023年9月5日周二 22:33写道：
> >
> > >
> > >
> > > On 2023/09/05 05:56:51 Sheng Wu wrote:
> > > > Several important things
> > >
> > > The entire project https://github.com/XiaoMi/mone has passed the internal
> > > audit of Xiaomi, and the owners and leaders of the entire project are
> > > consistent with the initiators of the ozhera project. The main donation to
> > > ASF this time is ozhera-all, and other modules follow the Apache protocol,
> > > which will not cause protocol or ownership ambiguity.
> > > > 1. You are mentioning the donation is about
> > > > `https://github.com/XiaoMi/mone/tree/master/ozhera-all`
> > > <https://github.com/XiaoMi/mone/tree/master/ozhera-all>, It is a part
> > > > of the repository, so will others stay out of the ASF? If so, have the
> > > > project been going through Xiaomi's internal audit about the sharing
> > > > codes between this part of the whole project? Who owns that?
> > >
> > > We hope to complete the internationalization transformation with the help
> > > of ASF; we are preparing the English documents, and a version will be
> > > completed by tomorrow;
> > > > 2. I can't see any English document for the project. Is the community
> > > > for a global foundation incubating journey?
> > >
> > > The user interface currently only has Chinese, and the
> > > internationalization of the page requires a longer time to iterate, but we
> > > will complete the transformation of this function in the early stage of
> > > incubation;
> > > > 3. More importantly, all screenshots and UIs are only in Chinese as well?
> > >
> > > a.We have received full support from Xiaomi's legal affairs and are able
> > > to submit the SGA;
> > > b.The project has gradually recruited partners outside of Xiaomi, and the
> > > initial committers from Xiaomi are also actively participating in the
> > > construction of other open source communities. These are a group of
> > > partners who are passionate about open source. I believe that this group of
> > > partners can continue the project in the long term.
> > > > 4. Have Xiaomi Inc. agreed on this? Will they submit a SGA? Are the
> > > > initial committers still working on Xiaomi and going to continue work
> > > > this project? Will Xiaomi permit their CCLAs?
> > >
> > > We have checked in advance, and we hope to do the replacement and upgrade
> > > during the future incubation period.
> > > > 5. I can see several incompatible licenses of dependencies existing,
> > > > including GPLs. Do you have plans to remove or replace them? Have you
> > > > worked with your mentors to go through licenses of dependencies check?
> > >
> > > There is a relatively clear division of labor among the mentors, and the
> > > mentors will regularly assign us corresponding tasks. Through efficient
> > > project collaboration, we ensure the activity of the community;
> > > At the same time, we can gain more experience and guidance from multiple
> > > mentors, which will further promote the positive cycle development of the
> > > community.
> > > > 6. Why a 10 people PPMC initial team has a mentor team of 6 people?
> > > > Typically, I don't think this is a good practice. Instead, mentors are
> > > > most likely counting on others and will become inactive.
> > >
> > > I hope that ozhera can play its value in the observability of cloud-native
> > > applications. Many components in ozhera (Opentelemetry, Grafana,
> > > Prometheus, MQ, etc.) come from the open source community. We hope to feed
> > > back our experience in the field of application observation to the
> > > community through this platform. The UI design will actively embrace open
> > > source like the backend, but we hope to implement mature solutions from the
> > > community for chart display, currently it is Grafana.
> > > > 7. How would you process the branding? Including you are sharing UI
> > > > design. I have concerns this would be another issues with the main
> > > > project.
> > >
> > > a. We have chosen MySQL and Elasticsearch as the project's storage
> > > solutions based on their excellent performance in their respective fields.
> > > The versions we have chosen strictly comply with the GPL and Apache2.0
> > > agreements.
> > > b. While Elasticsearch has changed from Apache 2.0 to the Server Side
> > > Public License (SSPL), although SSPL is no longer an OSI-approved open
> > > source license, it still allows free use, modification, and distribution,
> > > but imposes some restrictions on commercial use.
> > > c. We are also working on storage design. In the future, we will abstract
> > > a complete storage layer interface to decouple the code logic from the
> > > specific storage implementation. This facilitates integrating more
> > > alternative storage solutions. Our project is open and is willing to
> > > cooperate with the Apache Incubator community, mentors, and other relevant
> > > parties to resolve potential license issues.
> > > > 8. You are using MySQL and ElasticSearch as storage. The one is on GPL
> > > > and the other is not longer OSI-approved license anymore. What is your
> > > > plan on that?
> > >
> > > Firstly, SkyWalking is an excellent open source APM, with comprehensive
> > > capabilities in tracing, real-time topology, and multi-language adaptation.
> > > The starting point for creating OzHera is to build an enterprise-level
> > > observability platform for the cloud-native era that truly solves the
> > > problem of discovering business issues within 1 minute and locating them
> > > within 5 minutes.
> > > Its core features include:
> > > a. Embracing Cloud-native
> > > It adheres to the Opentracing standard and integrates several renowned
> > > open-source products including Opentelemetry, Grafana, Prometheus, and ES.
> > > Hera also deeply adapts to K8S and provides one-click deployment capability
> > > based on K8S.
> > > b. Accuracy: Availability metrics
> > > Too many alerts essentially equate to ineffective alerts, making the
> > > accuracy of alerts particularly important. No one understands the
> > > correctness of requests better than their own business error codes. We
> > > incorporate the ability to recognize business error codes into the business
> > > availability metrics, allowing business alerts to focus on just this one
> > > indicator. At the same time, we are also expanding SLA metrics to view the
> > > availability of server services from the client's perspective.
> > > c. Excellent Linkage: Metrics-Tracing-Logging linkage
> > > Based on the traceId, we establish a closed-loop linkage of
> > > alarm->indicator->link->log, significantly improving user efficiency in
> > > pinpointing issues.
> > > d. Economical: <0.1% storage cost, satisfying 99.9% of tracing demands
> > > We judge the importance of traces (exceptional span, single span calls
> > > exceeding 1s, error log output, business exception error codes, etc.). Any
> > > trace identified as important is fully retained, while the remaining normal
> > > traces are sampled to ensure efficiency while considering economic costs.
> > > e. Enterprise-level Observable Product
> > > Complete tenant permissions and application management mechanisms make it
> > > easy for users to quickly deploy and integrate their own accounts, CI/CD
> > > systems, etc., within the enterprise. It can also quickly connect to
> > > enterprise office software to achieve alert delivery;
> > > Within Xiaomi, it handles over 100T of data daily in a smooth and
> > > efficient manner;
> > > The core link is well decoupled to facilitate rapid scaling at each stage.
> > > For large volumes of tracing, we have implemented head and tail sampling to
> > > ensure the platform's cost-effectiveness.
> > > > 9 What are the differences between you and SkyWalking? What is this
> > > > new project bringing new to the users? Notice, this is a not a
> > > > rejection for a similar project, but, if they are nearly same, you
> > > > will face competitions in the same foundation but already have larger
> > > > community.
> > > >
> > > > Sheng Wu 吴晟
> > > > Twitter, wusheng1108
> > > >
> > > > Yu Xiao <xi...@apache.org> 于2023年9月5日周二 11:12写道：
> > > > >
> > > > > Dear incubator community,
> > > > >
> > > > > I would like to propose OzHera[1] as a new apache incubator project,
> > > you
> > > > > can find the proposal[2] of OzHera for more detail.
> > > > >
> > > > > OzHera is an application performance observation platform that centers
> > > > > around applications,
> > > > > integrating metric monitoring, link tracing, logs, alerts, and other
> > > > > capabilities.
> > > > > The Hera platform has the following core features:
> > > > >
> > > > > ** Embrace Cloud Native
> > > > > Complies with the Opentracing standard, integrating multiple star
> > > > > open-source products such as OpenTelemetry,
> > > > > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> > > > > adapts to K8S,
> > > > > providing one-click deployment on K8S through operator.
> > > > >
> > > > > ** Precise: Availability Metrics
> > > > > We have defined corresponding availability metrics for common RPC
> > > > > (Dubbo, HTTP, etc.) requests.
> > > > > These request-scope metrics are automatically extracted from tracing
> > > > > by Hera, and during extraction,
> > > > > we enhance the ability to recognize business error codes.
> > > > > A single metric can accurately express the exceptions encapsulated by
> > > > > RPC and business processing.
> > > > >
> > > > > ** Quick: Metrics-Tracing-Logging Linkage
> > > > > Based on traceId, it links the alarm -> metrics -> link -> log closed
> > > loop.
> > > > > From the moment the alarm card touches the user, the user can quickly
> > > > > view the link and log situation related to this alarm,
> > > > > greatly improving the efficiency of problem locating.
> > > > >
> > > > > ** Economical
> > > > > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > > > > OzHera achieves the recognition of abnormal calls (error span,
> > > > > abnormal business error codes,
> > > > > error logs, single span time exceeding 1 second, etc.) and ensures the
> > > > > storage of data for the entire call link of abnormal traces.
> > > > > For normal traces, we adopt a default random sampling strategy of one
> > > > > in ten thousand.
> > > > >
> > > > > ** Enterprise-level Observable Products
> > > > > Complete account, permission, application management mechanisms,
> > > > > allowing users to quickly implement within the enterprise and connect
> > > > > to the enterprise’s own account, application deployment system, etc.
> > > > > It can also quickly dock with enterprise office software to achieve
> > > > > alarm touch. Core links are well decoupled for rapid scaling,
> > > > > and for large volumes of tracing, we have implemented tail sampling
> > > strategies,
> > > > > able to support high qps, real-time observable demands of high
> > > > > timeliness systems.
> > > > >
> > > > > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > > > > [2]
> > > https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> > > > >
> > > > > Best,
> > > > > Yu Xiao
> > > > >
> > > > > ASF Member
> > > > > Apache ShenYu V.P.
> > > > > Apache Incubator PMC
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[Sheng Wu <wu...@gmail.com>]

tison <wa...@gmail.com> 于2023年9月5日周二 22:53写道：
>
> Hi,
>
> Glad to see a new incubator proposal. Comments inline.
>
> > There is a relatively clear division of labor among the mentors, and the
> mentors will regularly assign us corresponding tasks.
>
> This sounds interesting. Could you elaborate on the "division of labor" and
> previous tasks "assigned" by mentors to initial committers?

A good question, and a bigger concern. Who can assign the mentors to work?
Are they paid in some ways by Xiaomi? So, they will work for the
company and the project?


>
> > I hope that ozhera can play its value in the observability of
> cloud-native applications.
> >> How would you process the branding
>
> The concern here is that ozhera, as a submodule of Mone, can suffer from
> its packages and UIs convey the Mone branding still held by Xiaomi. If an
> ASF project is tightly coupled with a vendor-specific project, it may be a
> concern.
>
> > The versions we have chosen strictly comply with the GPL and Apache2.0
> agreements.
>
> The ASF states its project won't contain GPL-licensed components, at least
> not as a necessary dependency. You can check [1][2] for details.
>
> > b. While Elasticsearch has changed from Apache 2.0 to the Server Side
> Public License (SSPL), although SSPL is no longer an OSI-approved open
> source license, it still allows free use, modification, and distribution,
> but imposes some restrictions on commercial use.
>
> What would you like to express here? The ASF releases open-source software
> following OSD[2][3]. SSPL or ELv2 is simply unacceptable.
>
> Best,
> tison.
>
> [1] https://www.apache.org/licenses/GPL-compatibility.html
> [2] https://www.apache.org/legal/resolved.html#category-x
> [3] https://news.apache.org/foundation/entry/the-apache-way-to-sustainable
>
>
>
> Zhiyong Zhang <go...@apache.org> 于2023年9月5日周二 22:33写道：
>
> >
> >
> > On 2023/09/05 05:56:51 Sheng Wu wrote:
> > > Several important things
> >
> > The entire project https://github.com/XiaoMi/mone has passed the internal
> > audit of Xiaomi, and the owners and leaders of the entire project are
> > consistent with the initiators of the ozhera project. The main donation to
> > ASF this time is ozhera-all, and other modules follow the Apache protocol,
> > which will not cause protocol or ownership ambiguity.
> > > 1. You are mentioning the donation is about
> > > `https://github.com/XiaoMi/mone/tree/master/ozhera-all`
> > <https://github.com/XiaoMi/mone/tree/master/ozhera-all>, It is a part
> > > of the repository, so will others stay out of the ASF? If so, have the
> > > project been going through Xiaomi's internal audit about the sharing
> > > codes between this part of the whole project? Who owns that?
> >
> > We hope to complete the internationalization transformation with the help
> > of ASF; we are preparing the English documents, and a version will be
> > completed by tomorrow;
> > > 2. I can't see any English document for the project. Is the community
> > > for a global foundation incubating journey?
> >
> > The user interface currently only has Chinese, and the
> > internationalization of the page requires a longer time to iterate, but we
> > will complete the transformation of this function in the early stage of
> > incubation;
> > > 3. More importantly, all screenshots and UIs are only in Chinese as well?
> >
> > a.We have received full support from Xiaomi's legal affairs and are able
> > to submit the SGA;
> > b.The project has gradually recruited partners outside of Xiaomi, and the
> > initial committers from Xiaomi are also actively participating in the
> > construction of other open source communities. These are a group of
> > partners who are passionate about open source. I believe that this group of
> > partners can continue the project in the long term.
> > > 4. Have Xiaomi Inc. agreed on this? Will they submit a SGA? Are the
> > > initial committers still working on Xiaomi and going to continue work
> > > this project? Will Xiaomi permit their CCLAs?
> >
> > We have checked in advance, and we hope to do the replacement and upgrade
> > during the future incubation period.
> > > 5. I can see several incompatible licenses of dependencies existing,
> > > including GPLs. Do you have plans to remove or replace them? Have you
> > > worked with your mentors to go through licenses of dependencies check?
> >
> > There is a relatively clear division of labor among the mentors, and the
> > mentors will regularly assign us corresponding tasks. Through efficient
> > project collaboration, we ensure the activity of the community;
> > At the same time, we can gain more experience and guidance from multiple
> > mentors, which will further promote the positive cycle development of the
> > community.
> > > 6. Why a 10 people PPMC initial team has a mentor team of 6 people?
> > > Typically, I don't think this is a good practice. Instead, mentors are
> > > most likely counting on others and will become inactive.
> >
> > I hope that ozhera can play its value in the observability of cloud-native
> > applications. Many components in ozhera (Opentelemetry, Grafana,
> > Prometheus, MQ, etc.) come from the open source community. We hope to feed
> > back our experience in the field of application observation to the
> > community through this platform. The UI design will actively embrace open
> > source like the backend, but we hope to implement mature solutions from the
> > community for chart display, currently it is Grafana.
> > > 7. How would you process the branding? Including you are sharing UI
> > > design. I have concerns this would be another issues with the main
> > > project.
> >
> > a. We have chosen MySQL and Elasticsearch as the project's storage
> > solutions based on their excellent performance in their respective fields.
> > The versions we have chosen strictly comply with the GPL and Apache2.0
> > agreements.
> > b. While Elasticsearch has changed from Apache 2.0 to the Server Side
> > Public License (SSPL), although SSPL is no longer an OSI-approved open
> > source license, it still allows free use, modification, and distribution,
> > but imposes some restrictions on commercial use.
> > c. We are also working on storage design. In the future, we will abstract
> > a complete storage layer interface to decouple the code logic from the
> > specific storage implementation. This facilitates integrating more
> > alternative storage solutions. Our project is open and is willing to
> > cooperate with the Apache Incubator community, mentors, and other relevant
> > parties to resolve potential license issues.
> > > 8. You are using MySQL and ElasticSearch as storage. The one is on GPL
> > > and the other is not longer OSI-approved license anymore. What is your
> > > plan on that?
> >
> > Firstly, SkyWalking is an excellent open source APM, with comprehensive
> > capabilities in tracing, real-time topology, and multi-language adaptation.
> > The starting point for creating OzHera is to build an enterprise-level
> > observability platform for the cloud-native era that truly solves the
> > problem of discovering business issues within 1 minute and locating them
> > within 5 minutes.
> > Its core features include:
> > a. Embracing Cloud-native
> > It adheres to the Opentracing standard and integrates several renowned
> > open-source products including Opentelemetry, Grafana, Prometheus, and ES.
> > Hera also deeply adapts to K8S and provides one-click deployment capability
> > based on K8S.
> > b. Accuracy: Availability metrics
> > Too many alerts essentially equate to ineffective alerts, making the
> > accuracy of alerts particularly important. No one understands the
> > correctness of requests better than their own business error codes. We
> > incorporate the ability to recognize business error codes into the business
> > availability metrics, allowing business alerts to focus on just this one
> > indicator. At the same time, we are also expanding SLA metrics to view the
> > availability of server services from the client's perspective.
> > c. Excellent Linkage: Metrics-Tracing-Logging linkage
> > Based on the traceId, we establish a closed-loop linkage of
> > alarm->indicator->link->log, significantly improving user efficiency in
> > pinpointing issues.
> > d. Economical: <0.1% storage cost, satisfying 99.9% of tracing demands
> > We judge the importance of traces (exceptional span, single span calls
> > exceeding 1s, error log output, business exception error codes, etc.). Any
> > trace identified as important is fully retained, while the remaining normal
> > traces are sampled to ensure efficiency while considering economic costs.
> > e. Enterprise-level Observable Product
> > Complete tenant permissions and application management mechanisms make it
> > easy for users to quickly deploy and integrate their own accounts, CI/CD
> > systems, etc., within the enterprise. It can also quickly connect to
> > enterprise office software to achieve alert delivery;
> > Within Xiaomi, it handles over 100T of data daily in a smooth and
> > efficient manner;
> > The core link is well decoupled to facilitate rapid scaling at each stage.
> > For large volumes of tracing, we have implemented head and tail sampling to
> > ensure the platform's cost-effectiveness.
> > > 9 What are the differences between you and SkyWalking? What is this
> > > new project bringing new to the users? Notice, this is a not a
> > > rejection for a similar project, but, if they are nearly same, you
> > > will face competitions in the same foundation but already have larger
> > > community.
> > >
> > > Sheng Wu 吴晟
> > > Twitter, wusheng1108
> > >
> > > Yu Xiao <xi...@apache.org> 于2023年9月5日周二 11:12写道：
> > > >
> > > > Dear incubator community,
> > > >
> > > > I would like to propose OzHera[1] as a new apache incubator project,
> > you
> > > > can find the proposal[2] of OzHera for more detail.
> > > >
> > > > OzHera is an application performance observation platform that centers
> > > > around applications,
> > > > integrating metric monitoring, link tracing, logs, alerts, and other
> > > > capabilities.
> > > > The Hera platform has the following core features:
> > > >
> > > > ** Embrace Cloud Native
> > > > Complies with the Opentracing standard, integrating multiple star
> > > > open-source products such as OpenTelemetry,
> > > > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> > > > adapts to K8S,
> > > > providing one-click deployment on K8S through operator.
> > > >
> > > > ** Precise: Availability Metrics
> > > > We have defined corresponding availability metrics for common RPC
> > > > (Dubbo, HTTP, etc.) requests.
> > > > These request-scope metrics are automatically extracted from tracing
> > > > by Hera, and during extraction,
> > > > we enhance the ability to recognize business error codes.
> > > > A single metric can accurately express the exceptions encapsulated by
> > > > RPC and business processing.
> > > >
> > > > ** Quick: Metrics-Tracing-Logging Linkage
> > > > Based on traceId, it links the alarm -> metrics -> link -> log closed
> > loop.
> > > > From the moment the alarm card touches the user, the user can quickly
> > > > view the link and log situation related to this alarm,
> > > > greatly improving the efficiency of problem locating.
> > > >
> > > > ** Economical
> > > > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > > > OzHera achieves the recognition of abnormal calls (error span,
> > > > abnormal business error codes,
> > > > error logs, single span time exceeding 1 second, etc.) and ensures the
> > > > storage of data for the entire call link of abnormal traces.
> > > > For normal traces, we adopt a default random sampling strategy of one
> > > > in ten thousand.
> > > >
> > > > ** Enterprise-level Observable Products
> > > > Complete account, permission, application management mechanisms,
> > > > allowing users to quickly implement within the enterprise and connect
> > > > to the enterprise’s own account, application deployment system, etc.
> > > > It can also quickly dock with enterprise office software to achieve
> > > > alarm touch. Core links are well decoupled for rapid scaling,
> > > > and for large volumes of tracing, we have implemented tail sampling
> > strategies,
> > > > able to support high qps, real-time observable demands of high
> > > > timeliness systems.
> > > >
> > > > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > > > [2]
> > https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> > > >
> > > > Best,
> > > > Yu Xiao
> > > >
> > > > ASF Member
> > > > Apache ShenYu V.P.
> > > > Apache Incubator PMC
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > > For additional commands, e-mail: general-help@incubator.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[tison <wa...@gmail.com>]

Hi,

Glad to see a new incubator proposal. Comments inline.

> There is a relatively clear division of labor among the mentors, and the
mentors will regularly assign us corresponding tasks.

This sounds interesting. Could you elaborate on the "division of labor" and
previous tasks "assigned" by mentors to initial committers?

> I hope that ozhera can play its value in the observability of
cloud-native applications.
>> How would you process the branding

The concern here is that ozhera, as a submodule of Mone, can suffer from
its packages and UIs convey the Mone branding still held by Xiaomi. If an
ASF project is tightly coupled with a vendor-specific project, it may be a
concern.

> The versions we have chosen strictly comply with the GPL and Apache2.0
agreements.

The ASF states its project won't contain GPL-licensed components, at least
not as a necessary dependency. You can check [1][2] for details.

> b. While Elasticsearch has changed from Apache 2.0 to the Server Side
Public License (SSPL), although SSPL is no longer an OSI-approved open
source license, it still allows free use, modification, and distribution,
but imposes some restrictions on commercial use.

What would you like to express here? The ASF releases open-source software
following OSD[2][3]. SSPL or ELv2 is simply unacceptable.

Best,
tison.

[1] https://www.apache.org/licenses/GPL-compatibility.html
[2] https://www.apache.org/legal/resolved.html#category-x
[3] https://news.apache.org/foundation/entry/the-apache-way-to-sustainable



Zhiyong Zhang <go...@apache.org> 于2023年9月5日周二 22:33写道：

>
>
> On 2023/09/05 05:56:51 Sheng Wu wrote:
> > Several important things
>
> The entire project https://github.com/XiaoMi/mone has passed the internal
> audit of Xiaomi, and the owners and leaders of the entire project are
> consistent with the initiators of the ozhera project. The main donation to
> ASF this time is ozhera-all, and other modules follow the Apache protocol,
> which will not cause protocol or ownership ambiguity.
> > 1. You are mentioning the donation is about
> > `https://github.com/XiaoMi/mone/tree/master/ozhera-all`
> <https://github.com/XiaoMi/mone/tree/master/ozhera-all>, It is a part
> > of the repository, so will others stay out of the ASF? If so, have the
> > project been going through Xiaomi's internal audit about the sharing
> > codes between this part of the whole project? Who owns that?
>
> We hope to complete the internationalization transformation with the help
> of ASF; we are preparing the English documents, and a version will be
> completed by tomorrow;
> > 2. I can't see any English document for the project. Is the community
> > for a global foundation incubating journey?
>
> The user interface currently only has Chinese, and the
> internationalization of the page requires a longer time to iterate, but we
> will complete the transformation of this function in the early stage of
> incubation;
> > 3. More importantly, all screenshots and UIs are only in Chinese as well?
>
> a.We have received full support from Xiaomi's legal affairs and are able
> to submit the SGA;
> b.The project has gradually recruited partners outside of Xiaomi, and the
> initial committers from Xiaomi are also actively participating in the
> construction of other open source communities. These are a group of
> partners who are passionate about open source. I believe that this group of
> partners can continue the project in the long term.
> > 4. Have Xiaomi Inc. agreed on this? Will they submit a SGA? Are the
> > initial committers still working on Xiaomi and going to continue work
> > this project? Will Xiaomi permit their CCLAs?
>
> We have checked in advance, and we hope to do the replacement and upgrade
> during the future incubation period.
> > 5. I can see several incompatible licenses of dependencies existing,
> > including GPLs. Do you have plans to remove or replace them? Have you
> > worked with your mentors to go through licenses of dependencies check?
>
> There is a relatively clear division of labor among the mentors, and the
> mentors will regularly assign us corresponding tasks. Through efficient
> project collaboration, we ensure the activity of the community;
> At the same time, we can gain more experience and guidance from multiple
> mentors, which will further promote the positive cycle development of the
> community.
> > 6. Why a 10 people PPMC initial team has a mentor team of 6 people?
> > Typically, I don't think this is a good practice. Instead, mentors are
> > most likely counting on others and will become inactive.
>
> I hope that ozhera can play its value in the observability of cloud-native
> applications. Many components in ozhera (Opentelemetry, Grafana,
> Prometheus, MQ, etc.) come from the open source community. We hope to feed
> back our experience in the field of application observation to the
> community through this platform. The UI design will actively embrace open
> source like the backend, but we hope to implement mature solutions from the
> community for chart display, currently it is Grafana.
> > 7. How would you process the branding? Including you are sharing UI
> > design. I have concerns this would be another issues with the main
> > project.
>
> a. We have chosen MySQL and Elasticsearch as the project's storage
> solutions based on their excellent performance in their respective fields.
> The versions we have chosen strictly comply with the GPL and Apache2.0
> agreements.
> b. While Elasticsearch has changed from Apache 2.0 to the Server Side
> Public License (SSPL), although SSPL is no longer an OSI-approved open
> source license, it still allows free use, modification, and distribution,
> but imposes some restrictions on commercial use.
> c. We are also working on storage design. In the future, we will abstract
> a complete storage layer interface to decouple the code logic from the
> specific storage implementation. This facilitates integrating more
> alternative storage solutions. Our project is open and is willing to
> cooperate with the Apache Incubator community, mentors, and other relevant
> parties to resolve potential license issues.
> > 8. You are using MySQL and ElasticSearch as storage. The one is on GPL
> > and the other is not longer OSI-approved license anymore. What is your
> > plan on that?
>
> Firstly, SkyWalking is an excellent open source APM, with comprehensive
> capabilities in tracing, real-time topology, and multi-language adaptation.
> The starting point for creating OzHera is to build an enterprise-level
> observability platform for the cloud-native era that truly solves the
> problem of discovering business issues within 1 minute and locating them
> within 5 minutes.
> Its core features include:
> a. Embracing Cloud-native
> It adheres to the Opentracing standard and integrates several renowned
> open-source products including Opentelemetry, Grafana, Prometheus, and ES.
> Hera also deeply adapts to K8S and provides one-click deployment capability
> based on K8S.
> b. Accuracy: Availability metrics
> Too many alerts essentially equate to ineffective alerts, making the
> accuracy of alerts particularly important. No one understands the
> correctness of requests better than their own business error codes. We
> incorporate the ability to recognize business error codes into the business
> availability metrics, allowing business alerts to focus on just this one
> indicator. At the same time, we are also expanding SLA metrics to view the
> availability of server services from the client's perspective.
> c. Excellent Linkage: Metrics-Tracing-Logging linkage
> Based on the traceId, we establish a closed-loop linkage of
> alarm->indicator->link->log, significantly improving user efficiency in
> pinpointing issues.
> d. Economical: <0.1% storage cost, satisfying 99.9% of tracing demands
> We judge the importance of traces (exceptional span, single span calls
> exceeding 1s, error log output, business exception error codes, etc.). Any
> trace identified as important is fully retained, while the remaining normal
> traces are sampled to ensure efficiency while considering economic costs.
> e. Enterprise-level Observable Product
> Complete tenant permissions and application management mechanisms make it
> easy for users to quickly deploy and integrate their own accounts, CI/CD
> systems, etc., within the enterprise. It can also quickly connect to
> enterprise office software to achieve alert delivery;
> Within Xiaomi, it handles over 100T of data daily in a smooth and
> efficient manner;
> The core link is well decoupled to facilitate rapid scaling at each stage.
> For large volumes of tracing, we have implemented head and tail sampling to
> ensure the platform's cost-effectiveness.
> > 9 What are the differences between you and SkyWalking? What is this
> > new project bringing new to the users? Notice, this is a not a
> > rejection for a similar project, but, if they are nearly same, you
> > will face competitions in the same foundation but already have larger
> > community.
> >
> > Sheng Wu 吴晟
> > Twitter, wusheng1108
> >
> > Yu Xiao <xi...@apache.org> 于2023年9月5日周二 11:12写道：
> > >
> > > Dear incubator community,
> > >
> > > I would like to propose OzHera[1] as a new apache incubator project,
> you
> > > can find the proposal[2] of OzHera for more detail.
> > >
> > > OzHera is an application performance observation platform that centers
> > > around applications,
> > > integrating metric monitoring, link tracing, logs, alerts, and other
> > > capabilities.
> > > The Hera platform has the following core features:
> > >
> > > ** Embrace Cloud Native
> > > Complies with the Opentracing standard, integrating multiple star
> > > open-source products such as OpenTelemetry,
> > > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> > > adapts to K8S,
> > > providing one-click deployment on K8S through operator.
> > >
> > > ** Precise: Availability Metrics
> > > We have defined corresponding availability metrics for common RPC
> > > (Dubbo, HTTP, etc.) requests.
> > > These request-scope metrics are automatically extracted from tracing
> > > by Hera, and during extraction,
> > > we enhance the ability to recognize business error codes.
> > > A single metric can accurately express the exceptions encapsulated by
> > > RPC and business processing.
> > >
> > > ** Quick: Metrics-Tracing-Logging Linkage
> > > Based on traceId, it links the alarm -> metrics -> link -> log closed
> loop.
> > > From the moment the alarm card touches the user, the user can quickly
> > > view the link and log situation related to this alarm,
> > > greatly improving the efficiency of problem locating.
> > >
> > > ** Economical
> > > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > > OzHera achieves the recognition of abnormal calls (error span,
> > > abnormal business error codes,
> > > error logs, single span time exceeding 1 second, etc.) and ensures the
> > > storage of data for the entire call link of abnormal traces.
> > > For normal traces, we adopt a default random sampling strategy of one
> > > in ten thousand.
> > >
> > > ** Enterprise-level Observable Products
> > > Complete account, permission, application management mechanisms,
> > > allowing users to quickly implement within the enterprise and connect
> > > to the enterprise’s own account, application deployment system, etc.
> > > It can also quickly dock with enterprise office software to achieve
> > > alarm touch. Core links are well decoupled for rapid scaling,
> > > and for large volumes of tracing, we have implemented tail sampling
> strategies,
> > > able to support high qps, real-time observable demands of high
> > > timeliness systems.
> > >
> > > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > > [2]
> https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> > >
> > > Best,
> > > Yu Xiao
> > >
> > > ASF Member
> > > Apache ShenYu V.P.
> > > Apache Incubator PMC
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: [DISCUSS] Incubating Proposal for OzHera

[Zhiyong Zhang <go...@apache.org>]

On 2023/09/05 05:56:51 Sheng Wu wrote:
> Several important things

The entire project https://github.com/XiaoMi/mone has passed the internal audit of Xiaomi, and the owners and leaders of the entire project are consistent with the initiators of the ozhera project. The main donation to ASF this time is ozhera-all, and other modules follow the Apache protocol, which will not cause protocol or ownership ambiguity.
> 1. You are mentioning the donation is about
> `https://github.com/XiaoMi/mone/tree/master/ozhera-all`, It is a part
> of the repository, so will others stay out of the ASF? If so, have the
> project been going through Xiaomi's internal audit about the sharing
> codes between this part of the whole project? Who owns that?

We hope to complete the internationalization transformation with the help of ASF; we are preparing the English documents, and a version will be completed by tomorrow;
> 2. I can't see any English document for the project. Is the community
> for a global foundation incubating journey?

The user interface currently only has Chinese, and the internationalization of the page requires a longer time to iterate, but we will complete the transformation of this function in the early stage of incubation;
> 3. More importantly, all screenshots and UIs are only in Chinese as well?

a.We have received full support from Xiaomi's legal affairs and are able to submit the SGA;
b.The project has gradually recruited partners outside of Xiaomi, and the initial committers from Xiaomi are also actively participating in the construction of other open source communities. These are a group of partners who are passionate about open source. I believe that this group of partners can continue the project in the long term.
> 4. Have Xiaomi Inc. agreed on this? Will they submit a SGA? Are the
> initial committers still working on Xiaomi and going to continue work
> this project? Will Xiaomi permit their CCLAs?

We have checked in advance, and we hope to do the replacement and upgrade during the future incubation period.
> 5. I can see several incompatible licenses of dependencies existing,
> including GPLs. Do you have plans to remove or replace them? Have you
> worked with your mentors to go through licenses of dependencies check?

There is a relatively clear division of labor among the mentors, and the mentors will regularly assign us corresponding tasks. Through efficient project collaboration, we ensure the activity of the community;
At the same time, we can gain more experience and guidance from multiple mentors, which will further promote the positive cycle development of the community.
> 6. Why a 10 people PPMC initial team has a mentor team of 6 people?
> Typically, I don't think this is a good practice. Instead, mentors are
> most likely counting on others and will become inactive.

I hope that ozhera can play its value in the observability of cloud-native applications. Many components in ozhera (Opentelemetry, Grafana, Prometheus, MQ, etc.) come from the open source community. We hope to feed back our experience in the field of application observation to the community through this platform. The UI design will actively embrace open source like the backend, but we hope to implement mature solutions from the community for chart display, currently it is Grafana.
> 7. How would you process the branding? Including you are sharing UI
> design. I have concerns this would be another issues with the main
> project.

a. We have chosen MySQL and Elasticsearch as the project's storage solutions based on their excellent performance in their respective fields. The versions we have chosen strictly comply with the GPL and Apache2.0 agreements.
b. While Elasticsearch has changed from Apache 2.0 to the Server Side Public License (SSPL), although SSPL is no longer an OSI-approved open source license, it still allows free use, modification, and distribution, but imposes some restrictions on commercial use.
c. We are also working on storage design. In the future, we will abstract a complete storage layer interface to decouple the code logic from the specific storage implementation. This facilitates integrating more alternative storage solutions. Our project is open and is willing to cooperate with the Apache Incubator community, mentors, and other relevant parties to resolve potential license issues.
> 8. You are using MySQL and ElasticSearch as storage. The one is on GPL
> and the other is not longer OSI-approved license anymore. What is your
> plan on that?

Firstly, SkyWalking is an excellent open source APM, with comprehensive capabilities in tracing, real-time topology, and multi-language adaptation.
The starting point for creating OzHera is to build an enterprise-level observability platform for the cloud-native era that truly solves the problem of discovering business issues within 1 minute and locating them within 5 minutes.
Its core features include:
a. Embracing Cloud-native
It adheres to the Opentracing standard and integrates several renowned open-source products including Opentelemetry, Grafana, Prometheus, and ES. Hera also deeply adapts to K8S and provides one-click deployment capability based on K8S.
b. Accuracy: Availability metrics 
Too many alerts essentially equate to ineffective alerts, making the accuracy of alerts particularly important. No one understands the correctness of requests better than their own business error codes. We incorporate the ability to recognize business error codes into the business availability metrics, allowing business alerts to focus on just this one indicator. At the same time, we are also expanding SLA metrics to view the availability of server services from the client's perspective.
c. Excellent Linkage: Metrics-Tracing-Logging linkage 
Based on the traceId, we establish a closed-loop linkage of alarm->indicator->link->log, significantly improving user efficiency in pinpointing issues.
d. Economical: <0.1% storage cost, satisfying 99.9% of tracing demands 
We judge the importance of traces (exceptional span, single span calls exceeding 1s, error log output, business exception error codes, etc.). Any trace identified as important is fully retained, while the remaining normal traces are sampled to ensure efficiency while considering economic costs.
e. Enterprise-level Observable Product 
Complete tenant permissions and application management mechanisms make it easy for users to quickly deploy and integrate their own accounts, CI/CD systems, etc., within the enterprise. It can also quickly connect to enterprise office software to achieve alert delivery;
Within Xiaomi, it handles over 100T of data daily in a smooth and efficient manner;
The core link is well decoupled to facilitate rapid scaling at each stage. For large volumes of tracing, we have implemented head and tail sampling to ensure the platform's cost-effectiveness.
> 9 What are the differences between you and SkyWalking? What is this
> new project bringing new to the users? Notice, this is a not a
> rejection for a similar project, but, if they are nearly same, you
> will face competitions in the same foundation but already have larger
> community.
> 
> Sheng Wu 吴晟
> Twitter, wusheng1108
> 
> Yu Xiao <xi...@apache.org> 于2023年9月5日周二 11:12写道：
> >
> > Dear incubator community,
> >
> > I would like to propose OzHera[1] as a new apache incubator project, you
> > can find the proposal[2] of OzHera for more detail.
> >
> > OzHera is an application performance observation platform that centers
> > around applications,
> > integrating metric monitoring, link tracing, logs, alerts, and other
> > capabilities.
> > The Hera platform has the following core features:
> >
> > ** Embrace Cloud Native
> > Complies with the Opentracing standard, integrating multiple star
> > open-source products such as OpenTelemetry,
> > Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> > adapts to K8S,
> > providing one-click deployment on K8S through operator.
> >
> > ** Precise: Availability Metrics
> > We have defined corresponding availability metrics for common RPC
> > (Dubbo, HTTP, etc.) requests.
> > These request-scope metrics are automatically extracted from tracing
> > by Hera, and during extraction,
> > we enhance the ability to recognize business error codes.
> > A single metric can accurately express the exceptions encapsulated by
> > RPC and business processing.
> >
> > ** Quick: Metrics-Tracing-Logging Linkage
> > Based on traceId, it links the alarm -> metrics -> link -> log closed loop.
> > From the moment the alarm card touches the user, the user can quickly
> > view the link and log situation related to this alarm,
> > greatly improving the efficiency of problem locating.
> >
> > ** Economical
> > Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> > OzHera achieves the recognition of abnormal calls (error span,
> > abnormal business error codes,
> > error logs, single span time exceeding 1 second, etc.) and ensures the
> > storage of data for the entire call link of abnormal traces.
> > For normal traces, we adopt a default random sampling strategy of one
> > in ten thousand.
> >
> > ** Enterprise-level Observable Products
> > Complete account, permission, application management mechanisms,
> > allowing users to quickly implement within the enterprise and connect
> > to the enterprise’s own account, application deployment system, etc.
> > It can also quickly dock with enterprise office software to achieve
> > alarm touch. Core links are well decoupled for rapid scaling,
> > and for large volumes of tracing, we have implemented tail sampling strategies,
> > able to support high qps, real-time observable demands of high
> > timeliness systems.
> >
> > [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> > [2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
> >
> > Best,
> > Yu Xiao
> >
> > ASF Member
> > Apache ShenYu V.P.
> > Apache Incubator PMC
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: [DISCUSS] Incubating Proposal for OzHera

[Sheng Wu <wu...@gmail.com>]

Several important things

1. You are mentioning the donation is about
`https://github.com/XiaoMi/mone/tree/master/ozhera-all`, It is a part
of the repository, so will others stay out of the ASF? If so, have the
project been going through Xiaomi's internal audit about the sharing
codes between this part of the whole project? Who owns that?
2. I can't see any English document for the project. Is the community
for a global foundation incubating journey?
3. More importantly, all screenshots and UIs are only in Chinese as well?
4. Have Xiaomi Inc. agreed on this? Will they submit a SGA? Are the
initial committers still working on Xiaomi and going to continue work
this project? Will Xiaomi permit their CCLAs?
5. I can see several incompatible licenses of dependencies existing,
including GPLs. Do you have plans to remove or replace them? Have you
worked with your mentors to go through licenses of dependencies check?
6. Why a 10 people PPMC initial team has a mentor team of 6 people?
Typically, I don't think this is a good practice. Instead, mentors are
most likely counting on others and will become inactive.
7. How would you process the branding? Including you are sharing UI
design. I have concerns this would be another issues with the main
project.
8. You are using MySQL and ElasticSearch as storage. The one is on GPL
and the other is not longer OSI-approved license anymore. What is your
plan on that?
9 What are the differences between you and SkyWalking? What is this
new project bringing new to the users? Notice, this is a not a
rejection for a similar project, but, if they are nearly same, you
will face competitions in the same foundation but already have larger
community.

Sheng Wu 吴晟
Twitter, wusheng1108

Yu Xiao <xi...@apache.org> 于2023年9月5日周二 11:12写道：
>
> Dear incubator community,
>
> I would like to propose OzHera[1] as a new apache incubator project, you
> can find the proposal[2] of OzHera for more detail.
>
> OzHera is an application performance observation platform that centers
> around applications,
> integrating metric monitoring, link tracing, logs, alerts, and other
> capabilities.
> The Hera platform has the following core features:
>
> ** Embrace Cloud Native
> Complies with the Opentracing standard, integrating multiple star
> open-source products such as OpenTelemetry,
> Grafana, Prometheus, ES, CAdvisor, etc. At the same time, Hera deeply
> adapts to K8S,
> providing one-click deployment on K8S through operator.
>
> ** Precise: Availability Metrics
> We have defined corresponding availability metrics for common RPC
> (Dubbo, HTTP, etc.) requests.
> These request-scope metrics are automatically extracted from tracing
> by Hera, and during extraction,
> we enhance the ability to recognize business error codes.
> A single metric can accurately express the exceptions encapsulated by
> RPC and business processing.
>
> ** Quick: Metrics-Tracing-Logging Linkage
> Based on traceId, it links the alarm -> metrics -> link -> log closed loop.
> From the moment the alarm card touches the user, the user can quickly
> view the link and log situation related to this alarm,
> greatly improving the efficiency of problem locating.
>
> ** Economical
> Less than 0.1% storage cost, satisfying 99.9% of tracing demands
> OzHera achieves the recognition of abnormal calls (error span,
> abnormal business error codes,
> error logs, single span time exceeding 1 second, etc.) and ensures the
> storage of data for the entire call link of abnormal traces.
> For normal traces, we adopt a default random sampling strategy of one
> in ten thousand.
>
> ** Enterprise-level Observable Products
> Complete account, permission, application management mechanisms,
> allowing users to quickly implement within the enterprise and connect
> to the enterprise’s own account, application deployment system, etc.
> It can also quickly dock with enterprise office software to achieve
> alarm touch. Core links are well decoupled for rapid scaling,
> and for large volumes of tracing, we have implemented tail sampling strategies,
> able to support high qps, real-time observable demands of high
> timeliness systems.
>
> [1] https://github.com/XiaoMi/mone/tree/master/ozhera-all
> [2] https://cwiki.apache.org/confluence/display/INCUBATOR/OzHeraProposal
>
> Best,
> Yu Xiao
>
> ASF Member
> Apache ShenYu V.P.
> Apache Incubator PMC
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org