Hi, > I think TOTAL_REQ_SUCCESS is also important in some cases.
Yes, we can keep the TOTAL_REQ_FAIL also as a contrast. > By the way, there is a branch "feature/improve-monitoring-metrics" which is > written by Julian and use Micrometer to collect some performance info. Any introduction or doc about this? Julian Feinauer <j.feina...@pragmaticminds.de> 于2020年8月26日周三 下午4:49写道： > 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 > > > > -- Best, Xiangwei Wei
