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 >
