Hi,
indeed there is potential for some more modularity (and I think I already added
a submodule in that branch).
Currently Xiangdong is improving the collected metrics and I would be happy to
get this into the master / develop ASAP : )
Julian
Am 26.08.20, 08:10 schrieb "Xiangdong Huang" <saint...@gmail.com>:
Hi,
I think TOTAL_REQ_SUCCESS is also important in some cases.
By the way, there is a branch "feature/improve-monitoring-metrics" which is
written by Julian
and use Micrometer to collect some performance info.
I think we can maintain that branch in the next step.
(By the way, I believe that making the project more modularity is
beneficial.
We can extract the implementation as interfaces to let users decide using
which way to get the info)
Best,
-----------------------------------
Xiangdong Huang
School of Software, Tsinghua University
黄向东
清华大学 软件学院
Xiangwei Wei <wxw19981...@gmail.com> 于2020年8月26日周三 下午1:52写道：
> Hi,
>
> Currently, the status monitor module of iotdb is abandoned and not
> maintained now. It's time for us to restart this module.
>
> Before, it was designed including two child modules: 1. the writing data
> status monitor and 2. the file size monitor.
>
> 1. The writing data monitor module is responsible for collecting writing
> data statistics including
> - TOTAL_POINTS (Calculate the total writing points number.)
> - TOTAL_REQ_SUCCESS (Calculate the successful requests number.)
> - TOTAL_REQ_FAIL (Calculate the failed requests number.)
> - TOTAL_POINTS_FAIL (Calculate the failed writing points number.)
> - TOTAL_POINTS_SUCCESS
> etc.
>
> and presenting them to users by statistics time series like
> .root.stats.write.global.TOTAL_POINTS. It's not supported completely now.
>
> Actually, many parts of origin design are redundant and not meaningful for
> users. Therefore, *I want to just keep TOTAL_POINTS here and remove
> others*.
> And i did not come up with some good ideas about *what needs to be added
to
> this monitor* while writing data. Welcome to any ideas here!
>
>
>
> 2. The file size monitor is concerned about how much space the data file
> takes. It's supported partly and very limited now.
>
> In my opinion, it's easily for users to see how much space the data file
> takes by a visible interface or just a Linux code. And it's more flexible
> for users to decide what to calculate by themselves. Therefore, there is
no
> sufficient reason for us to redesign and reimplement this child module. *I
> want to just remove it from iotdb.*
>
> The impletation way of status monitor module was designed as setting a
> monitor thread and returning the status info every
> *back_loop_period_in_second* (default 5s), removing outdated data
> every *stat_monitor_retain_interval_in_second
> (default 600s). *It cost a lot and is meaningless if no write was made
> then.
>
> Therefore, we want to collect the data while writing data and keep it in
> memory temperarily, *every time flush() is invoked or user want to select
> the monitor data, we update the data info to the disk and return users the
> lastest data.*
>
> That what need to be monitored which is useful for users except
> TOTAL_POINTS still need to be discussed. Welcome to any ideas.
>
>
>
>
>
> --
> Best,
> Xiangwei Wei
>
