Monitoring other relevant metrics of ArangoDB

    Solution

    For this recipe you need to install the following tools:

    You may want to monitor that ArangoDB doesn’t run out of disk space. The can aggregate these values for you.

    First we need to find out which disks are used by your ArangoDB. By default you need to find /var/lib/arango in the mount points. Since nowadays many virtual file systems are also mounted on a typical *nix system we want to sort the output of mount:

    So here we can see the mount points are , /local/home, /mnt/ so can be found on the root partition (/) /dev/sda3 here. A production setup may be different so the OS doesn’t interfere with the services.

    Another interesting metric is the amount of data read/written to disk - its an estimate how busy your ArangoDB or the whole system currently is. The Disk plugin aggregates these values.

    According to the mount points above our configuration /etc/collectd/collectd.conf.d/disk_io.conf looks like this:

    While the ArangoDB self monitoring already offers some overview of the running threads etc. you can get a deeper view using the .

    If you’re running a single Arango instance, a simple match by process name is sufficient, /etc/collectd/collectd.conf.d/arango_process.conf looks like this:

    As mentioned above, the list of available plugins is huge; Here are some more one could be interested in:

    • use the CPU Plugin to monitor the overall CPU utilization
    • use the to monitor main memory availability
    • Ethernet Statistics with whats going on at your Network cards to get a more broad overview of network traffic
    • you may like an apache request log and pick specific requests by regular expressions
    • Parse tabular files in the /proc file system
    • you can use to reduce the amount of data created by plugins (i.e. if you have many CPU cores, you may want the combined result). It can also decide where to route data and to which writer plugin
    • while you may have seen that metrics are stored at a fixed rate or frequency, your metrics (i.e. the durations of web requests) may come in a random & higher frequency. Thus you want to burn them down to a fixed frequency, and know Min/Max/Average/Median. So you want to Aggregate values using the statsd pattern.

    Finally while kcollectd is nice to get a quick success at inspecting your collected metrics during working your way into collectd, its not as sufficient for operating a production site. Since collectds default storage RRD is already widespread in system monitoring, there are to choose for the visualization. Some of them replace the RRD storage by simply adding a writer plugin, most prominent the Graphite graphing framework with the which allows you to combine random metrics in single graphs

    If you already run you can use the Nagios tool to submit values.

    We hope you now have a good overview of whats possible, but as usual its a good idea to browse the .