<< | [up] | >> |
dim_STAT User's Guide. by Dimitri |
FAQ |
Sizing of dim_STAT Instance... |
This problem is simple: there are no sizing rules. :)) Disk space: it depends only on the size of the information collected. On the Preferences page you can see the space used by the current database and the size of your biggest file. You cannot reduce the file sizes by data recycle, however it's possible now with a Convert Engine operation (as the table will be fully recreated) - keep in mind anyway that InnoDB is using much more disk space than MyISAM. CPU: for a collect your CPU is hardly used at all. However, once you start a query via the Web interface you will access a big amount of data! Your query may us all of CPU. Normally query execution time is relatively short, but depends directly on amount of data demanded. Separated databases are fine when you need different administrative tasks regarding the data collected. For example, it may be annoying when somebody is loading a large amount of data at the same time you're trying to analyze something. This will create additional locks and slow down the performance for others. MySQL (in the version used by dim_STAT) uses "table locking", so there can be only a single writer at the same time, and write operations are exclusive (no reads at the same time). If you use your own database you have less reasons to blame others. A desktop running dim_STAT server could be very heavily used, or not used at all. It all depends only on what you're doing with it.
I've started my collects but it seems that nothing gets collected? |
First of all be sure that:If everything seems to be correct in that sense, check the output of your '/etc/STATsrv/log/access.log' file.
- you've installed the STAT-service package on this host and started it.
- be sure your server is seen with "Green LED" by dim_STAT Server
Syntax of text matching pattern |
Quite often in the dim_STAT interface you may see an input text field that filters values or attributes matching a specified pattern. By default they are filled with '*' (means all), but what kind of syntax does it accept?Pattern by example:
- * - any character or none
- ? - any single character
- [amp] - single character and one from 'a', 'p', or 'm'
- [a-z] - any single character between 'a' and 'z' (both included)
- [^a-z] - any single character NOT between 'a' and 'z' (both included)
- !Pattern - apply NOT condition on the whole pattern
- Pattern || Pattern - apply OR condition between two patterns (or more)
- Pattern && Pattern - apply AND condition between two patterns (or more), has higher priority vs OR
Examples matching LOG messages:
- *Test??* - match all messages having TestNN in title
- *Test??* && *End* - match all TestNN messages containing End
- *Test??* && *End* || *Begin* - match all TestNN messages containing End or Begin
- !*Test??* && *End* || *Begin* - match any messages except TestNN and containing End or Begin
When will you upgrade to the newer MySQL version? |
But why?... :-)) Should we change a good old working horse just because it's old?? It worked fine for over 10 years now, and does exactly what it needs to do. And MyISAM is not working better in MySQL4 or MySQL5. MyISAM is really great for its binary compatibility between all platforms - it's simplifying so many things! :-) In some cases it make sense to move some critical tables from MyISAM to InnoDB engine and get advantage of a data protection against crashes... As well should be interesting to ship dim_STAT in parallel with a version of PostgreSQL!! But that's another story... UPDATE : since version 9.0 - dim_STAT is based on MySQL 5.5 (GA) and include both MyISAM and InnoDB engines, and you're free at any time to convert your database to the best situated engine for your activity! :-)
With multiple hosts to monitor, is it possible to graph them together?.. |
It's exactly what do you have with a Multi-Host Analyze feature. As well when you have hundreds of hosts you may even group stats by N first/last letters in the hostname, etc.. Data are here, and you just play with them.. :-)
How easy is it to integrate any new stats to monitor, including DTrace stuff? |
Usually it's quite straight forward to add new stat commands into dim_STAT. But at any time feel free to ask for help from the dim_STAT Users Group - as well there are already several debug hints were discussed: Regarding DTrace, once you have a working script with regular and well formatted output - usually it takes 5 minute to integrate it as a new dim_STAT Add-On. Solaris STAT-service already contains some DTrace scripts (for example, see: IOpatt Add-On)...
Could I get the raw data via dim_STAT-CLI instead of the graphs?... |
Yes, of course! See "-Data" option within dim_STAT-CLI.
I have a Windows machine to monitor remote UNIX boxes.... Any help?.. |
Sorry, there is no dim_STAT distribution for Windoze :)) But(!) if you absolutely want to work under Win, you may install VirtualBox for free (from VirtualBox ) on it, and then within VirtualBox install Linux or Solaris (there are several mini distros available across Internet (Pocket Solaris: Milax )), and monitor your servers from Windoze, but via VirtualBox... (as well for $200 you may buy a new PC and setup it in native with Solaris/x86 or Linux :-))
<< | [up] | >> |